Spring RTS Engine

Alright, this Inconsistent move data crap really annoys me. I finally went through all the SWTA units and reduced the number of movement classes from 22 to 6 (which significantly decreases loadtime on new maps, saves some hard drive space used for path data, and presumably helps lower CPU costs for pathing), but there's one class that's giving me a problem: The hovercraft class.

I'm not exactly sure what the problem is here. At first, I tried making a unified ground + hover class for the same sizes, but the hovers didn't hover and were just amphibious. Fair enough, I thought, it won't harm things to have 6 classes instead of 5. I copied TANKHOVER2 (which is what the bulk of the hovercraft in SWTA used) from the backup movedata.tdf file I had, renamed it to Hover2x2 (to match the changes I made in the fbis), and tried... no go, same problem. This is what perplexes me... why does the class that worked fine before fail now with only its name changed and nothing more? What the hell is the reason this doesn't work like it should?

Here's the class in question: Like I said, that worked fine before, but now it doesn't... are the movement classes' names hard coded into spring or something?

Well, I don't know what the hell is going on still, but I did get this fixed by renaming it to the OTA name rather than my own. So, what the hell, movement class names are hard coded? That's the only explanation I can see for this asshattery...

Gnome wrote:Well, I don't know what the hell is going on still, but I did get this fixed by renaming it to the OTA name rather than my own. So, what the hell, movement class names are hard coded? That's the only explanation I can see for this asshattery...

or maybe it doesn't like something about your movement class name?

I have Infantry1x1, Tank2x2 and 3x3, Walker 2x2 and 3x3 and those all work just dandily.

So do you have decreased load times still?

Are perhaps your units missing the canhover=1; tag?

I have 36 of those damn classes, and i'm utterly confused which ones I could take out and which not, problem is, in WD there will be ships.

Gnome, I am fairly sure that TANKHOVER2 is indeed, hardcoded, as that was the only way I could make my hovers/Amphibs work, too.

They all have canhover=1, GZ, otherwise they wouldn't have hovered in OTA

And yes, 6 from 22 rather than 5 from 22 is still a significant load time drop. It takes a bit of time to set it up, but here's how I did it:

1) Download Mufter from http://www.planetta.com/terragen/ (yay for Caer)
2) Open a command prompt. cd to your 'units' folder of your mod, with all the FBIs
3) Type find /I "MovementClass=" *.* > movementclasses.txt and open the new txt file inside your units directory. Notice how it's a nice concise list of all the movement classes you've used :D
4) If you want to rename the classes from the OTA names (except for that hovercraft one!), open all your FBI files in Mufter. Then open your movedata.tdf, and start going through your generated list from step 3. Mufter has a fairly obvious interface to use, and I think you're smart enough to handle comparing two lists yourself

If you don't rename the classes, you don't need to mess with Mufter at all, you can just go through the list and find all the unique ones, then go through the movedata file and delete the unused ones. You could also consolidate movement classes if you wanted.

Is there a way I could mess with movement classes to create a hovercraft that strafed? So far I've been using a low flying gunship, but that gives a few annoying things, such as constantly flying high to clear walls/trees, ect.

Thanks.

I don't really know much about scripting, but I think you could do it by making an invisible baseplate that has a really tight turn radius and then making the entire thing move for aiming.

Nemo wrote:Is there a way I could mess with movement classes to create a hovercraft that strafed? So far I've been using a low flying gunship, but that gives a few annoying things, such as constantly flying high to clear walls/trees, ect.

Thanks.

Another problem with that approach is that it would be vulnerable to air-only fire. In Uberhack style mods that would be catastrophically bizarre.

I'm not too worried about how it works with OTA/Uberhack based mods, because when its finished, it'll be part of its own game.

If anyone has heard of wulfram II...I'm (slowly) doing a port of that to spring. So far, I have a tank, with a pulse that fires but doesn't move. <_<

Spring uses the name (looking for "HOVER", case sensitive) of the movement class to decide what type of movement it represents. This is of course a bit hacky but there just isnt any other good way to decide from the data in a TA movement class description. (and you cant treat amphibious and hovers as the same since amphibious units will be affected by slopes on the sea floor while hovers wont) (see moveinfo.cpp).

Aren't BadSlope and BadWaterSlope in the moveinfo entries hover-specific?