ability_ranged_primary_vsmarine

[VulcanTourist]

I'm looking at the autocannon weapon characteristics, and there are two distinct "ability" definitions, one a default ranged definition and a second one identified as "_vsmarine". I've been trying for hours now to understand what that second definition is trying to achieve that is different from the first, and I've failed. Has anyone been down this road already and fared better?

In all the previous games where I've dabbled in modding - pretty much every game I've touched in the last 15 years - acquiring an understanding of the structure and internal grammar was easy. This game is threatening to break that pattern. Is the XML that's involved the problem, where always before it was LUA or something similarly concise, or is it just really that much more complex? Maybe it's the FPS-like aspect when all the other games I've modded were either RTS or turn-based?

If there's a must-have XML editor that makes everything crystal clear, then I wanna get it. If it's education, I'd like to get that too (up to a point).

[cerberos008]

I'm sure you've already figured this out, but from what I can tell, the only difference I can spot between default ranged definition and the _vsmarine is an alternate entry under the hit_sim branch. The default definition has an extra area_effect entry that targets everything, while the _vsmarine has a controller_rumble entry instead. Of course the only way to find out which definition's which ingame is to try and get your controller rumble. But it seems neither of us has a rumble-capable controller on hand, so we might have to leave this up in the air.

If I had to guess, I'd say the _vsmarine definition is only active when fighting chaos marines during the SP campaign. Everything else probably falls under the default definition. Either way, whatever edits you're planning on making to the autocannon, best to just duplicate your changes in both definitions.

[VulcanTourist]

I assumed that "vsmarine" referred specifically to Chaos marines. I've kinda put that investigation on hold for now. What confused me about it was that I couldn't identify how it chooses between the two; where's the test that branches to one or the other? I couldn't find anything that, to my still inexpert eye, looked like it would do that. Even if it's all just parsed linear there still has to be some test to decide if it parses the node or drops past it.

BTW, I'm making a habit of stripping out those rumble nodes whenever I come across them now, since without a device that can react to it it's just wasted cycles! I doubt I would like the effect even if I had such a controller. My next crusade may be to figure out what's causing the camera/world shaking from rockets and the like and remove it all, or at least tone it down severely. It's completely unrealistic and over-the-top. What's the point of having a nifty sniper rifle when you can't even aim it because of constant magnitude 10 earthquakes caused by little gun-fired rockets? It's stoopid. There's also the blinding effects from explosives and lasers, but at least an argument can be made in favor of that. Still, they might need to be reduced.

It almost feels like the developers were so tickled by their new physics engine that they couldn't resist using the game as a guinea pig to see how far they could push things. I can just picture the devs running back and forth from one cubby to another and cackling every time one of them came up with another outrageous physics demo.

[cerberos008]

I know right. The shaking even gets nauseating when you're trying to focus at a specific point on the screen, especially for me when I'm trying to view my armors ingame under different environments. You'd be on the right track to look for the "camera_effects" entries if you want to remove all those shaking and blurring effects.

[VulcanTourist]

Yes, I'd noticed those camera_effect nodes last night (or was it the night before? *dizzy*) and figured they might be the culprits. I don't grok the purpose of the ease_out, ease_in, and blur_power sub-nodes, but it all looks suspicious. I can yank 'em experimentally from a couple weapons and if that makes a difference then budget time to remove 'em more widely. That should keep me busy for a while.

----------

You know what sort of a modding tool we really need? A sort of "patch" tool, that could wrap up a series of edits to one person's particular attribute file as a package that could then be applied to another person's copy of the same... even if that file already had other changes made to it. Second to that would be a tool - a "procedural editor"? - that could make procedural changes to the same syntax found in a large group of files, like looking for all instances of damage_general and then changing the numeric values by some expression, for instance simply multiplying by 1.5.

Once upon a time when modding Total Annihilation we had a tool like the latter that enabled on-the-fly "mutators" applied to the games files (it was also a mod-switcher). You could experiment with sweeping changes to the entire game without having to hand-edit every single file. It would take seconds instead of days!