Spring RTS Engine

Have you tried making the impulse factor a decimal value?

If the original impulse is 10, multiplying it by an impulsefactor of .0001 should reduce the shockwave considerably. Just a thought, although this should help with units getting hurled around from the huge shockwave. Ground damage will still occur.

Problem is, the hole in the ground does not depend on the impulsefactor.
But I'll try if I can make paralyzedamage not cause ground damage.

Zaphod wrote:Problem is, the hole in the ground does not depend on the impulsefactor.

Is there any reason why it shouldn't be changed , it makes a great deal of sense for it to work that way.

Wouldn't a simple fix be to give it a default damage of 0, and then simply give it the real damage against units? That should work in theory at least.

from MAESTRO'S ENCYCLOPAEDIA OF
TA WEAPONRY

paralyzer
Weapon will stun the enemy for a length of time described in the damage field, damage=60 mean one second paralyze. However paralyzer weapon wont cause any damage to enemy unit, only stun them
examples:
paralyzer=1;
damage=600;
Means the weapon will paralyze the enemy unit for 10 second


BUT in spring damage does real damage instead of give a time or being paralysed..

Er... actually paralyzing works fine in spring. The only problem is that area-of-effect paralyzing carries with it a massive smoking crater.

The smoking crater thing is easy to fix. Here's how you'd convert the arm EMP missile from OTA to spring.

Set the default damage of the weapon to 1. Then copy out the list of special damage that's underneith it (its something like 2 pages long of every core unit) and make that all into an armor type in armor.txt. Call it AllCoreUnits or something. Go back to the EMP_weapon file and underneith where you set the damage to 1 type in the line AllCoreUnits=100000;

And volla you have a working EMP missile that makes no crater, stuns core units, and leaves your units untouched.

I would like to say I'm guessing that using a lot of armor types can slow down simulation speed a lot. I have a feeling I've discovered this a bit too late
I never profiled it, so maybe it's a good idea if someone tests the framerate in heavy combat with different number of armor types.
If you care about polycounts as mod maker, you should also care about the number of armor types. I see 500 (:!:) armortypes in the AA armor.txt, and I don't think it was intended to have an armortype for every different unit type.

Zaphod wrote:I would like to say I'm guessing that using a lot of armor types can slow down simulation speed a lot. I have a feeling I've discovered this a bit too late
I never profiled it, so maybe it's a good idea if someone tests the framerate in heavy combat with different number of armor types.
If you care about polycounts as mod maker, you should also care about the number of armor types. I see 500 (:!:) armortypes in the AA armor.txt, and I don't think it was intended to have an armortype for every different unit type.

That's very unfortunate. AA has trimmed down the number of armor classes, but ones that are left are there for good reasons - frequently it's used for cases like a bomber unit that uses a large explosive and needs to be unable to hurt itself.

I just used someone's Python script... forget his name now. But it took every unit, made it into an armorclass of its own. I'm betting Kuro and WD are probably taking the same route, although I can certainly see the advantage of categorizing units - even WITHOUT slowdown.

However, if there's an actual performance loss, I guess that means I'll be spending the rest of the weekend making proper categories... ... some of which will need to have about 500 units in them....

You could do a new Python script. It would just have to be rather intelligent.

Here's my ideal algorithm. Go through the OTA weapon list (or the Spring one generated by the old Py script). For each entry in the list, store a list of all units that it does the same same damage to (besides default) - so sub torps that do reduced damage to torp launchers and extra damage to boats would have 2 such lists. Handle said list as a tuple of strings so it can be used as a key in the set - and store said tuples in the set. Then you have a big set object containing lists of units - each list of units corresponds to a set of units that one or more weapons does a constant amount of adjusted damage to.

Then, go through and create names for each tuple. This is a user-oriented action.

Next, go back through and change the memberships so that if a unit is present in a given tuple, it will be grouped under armor type given in the tuple name. You now have your armor groups setup.

Finally, go through the special damage amounts and check if groups of units that recieve the same adjusted damage from weapon X match any of the tuples (they should). Finally, change said damages to a single damage amount defined by the earlier "name".

Nasty algorithm, but doable. I'd script it myself if I (a) had the time, and (b) new jack about TA scripts.