Spring RTS Engine

After talking with Godde about the situation with gundam's movedefs and how some of them were being ignored because they were too large and we started talking about movdefs and it occurred to me that we content developers were manually checking our movdefs. This is obviously a recipe for disaster.

As you all know the pathfinder has been difficult to deal with. However, we have largely blamed the engine devs for it and not the content developers. In truth both parties need to be responsible. So I began to look into movdefs. It is my understanding that the paths which are precalculated use these defined movdefs. SO I thought, we know if a footprint of a unit is in conflict with the movedef the unit gets stuck. How much else this effects I began to wonder about.

So I decided after talking to Godde that I would write some code to check movdefs. I have had two other projects vet the code and it seems to work. Gundam I have seen marked improvements on my unit pathing:


------------- the files -----------
movedefs.lua - loads movdefs and ensures all default tags are present
movedefs_tags.lua - has a listing of all relevant tags and a default setting where possible
movedefs_post.lua - checks unit against the movedef, if a value is in conflict prints a warning and sets the unit to use the movedef value.
movedefs_classes.lua - stores your movdefs

------------- Q&A -----------
Q: does this work for BA?
A: dunno and don't care.

Q: What tags does it check?
A:
crushstrength,
submarine,
depthmod,
slopemod,
heatmapping,
heatmod,
heatproduced,
footprintx,
footprintz,

Q: Why doesn't it check minwaterdepth, maxwaterdepth, maxslope?
A: Because the movdef tags and unit def tags for these things are for different purposes. It is an issue with poor naming and the wiki needs updating.

Q: so what does the unitdef minwaterdepth, maxwaterdepth, maxslope get used for?
A: Transport unloading and checking build slopes.

Q: Why should this be used?
A: Poor pathing is not ONLY the engine's fault. it is also the fault of us content developers for making conflcting data.

Q: Does this touch any files?
A: No. At load it plays around with the lua tables

Q: Where does it go?
A: /gamedata/.

Q: I already have a movdef.lua, replace that?
A: no copy it, the contents of that file need to go into movdef_classes.

P.S. Mucho thanks to slogic, flozi, kloot, godde and nemo for helping me dig for info

I'm just curious what the screen shot represents?

The unit was given an order to go outside of the cattle gates. Normally he would get lost or confused. He made it just fine. The green line was the path he took wandering in the maze

Cool beans! Sheds some light on the poor sea pathing of a mod (your scripts ran fine )

Thanks!

can this be stickied for a while?

P.P.S. I know every year I do something for christmas but this was all I could get done so please don't be upset if this is all I can give you guys this year.

aww how sweet, smoth cares about ba players ! i knew it!

Wait, I thought Gundam 1.23 was our Christmas present.

lol we are on 1.26. You guys WERE going to get 1.27 but irl and spring issues have prevented that from happening.

I guess with changes to depthmod in 86.0, this needs updating?

in \movedefs.zip\movedefs.lua\:

local preProcFile = 'gamedata/movedefs_pre.lua'
local postProcFile = 'gamedata/movedefs_post.lua'

what are these files? preProcFile seems unused.

yep it does, I didn't think anyone needed to use it but once and since the major mods had already run it and felt like it was no longer cared about.

PreProc was added because I could add it while I was there. Didn't know if someone would need it, but just in case, I added support for it all the same.

PostProc is where I was doing the actual check of the defs. I wanted to match the existing spring structures with regards to def processing and it felt cleaner to put all my def alterations there.

just in case, I added support for it all the same.

i think it is just a variable that never gets used?

Also wouldnt this be less cumbersome as a gadget? (except for setting values but one would just be interessted in the notice anyway)

knorke wrote:Also wouldnt this be less cumbersome as a gadget? (except for setting values but one would just be interested in the notice anyway)

Opinions etc. I don't see it that way.

*edit* to be clear and not be mistaken for being defensive. I see it as cleaner this way because it matches all my other def altering code.

As gadget you would have only 1 file (instead of 4) that you plug into your game (without altering anything else in the game), look at the output, remove the file. Anyway, just an idea.

You didn't look at the source.
*edit*
I cannot get on the chat because weblobby currently requires me to install spring.

The source does more than just compare. I understand what you feel it is doing but it also does some silent overrides to cover sloppy defs better.

smoth wrote:The source does more than just compare. [...]it also does some silent overrides to cover sloppy defs better.

As I said:

knorke wrote:(except for setting values but one would just be interessted in the notice anyway)

If you find an error you would fix it anyway, instead of going with some default override. Not having to touch anything of your game would be worth it imo.

knorke wrote:If you find an error you would fix it anyway, instead of going with some default override. Not having to touch anything of your game would be worth it imo.

I do. In the post, I replace the unit def with the movedef when the unitdef does not properly match.

Seems hackish, if only for always having the "Warning!..." in infolog.
But the idea could be taken one step further: Not add footprint and some other tags to the unitdef files at all. Have as much as possible automatically applied, not just in case of mismatch.

knorke wrote:Seems hackish, if only for always having the "Warning!..." in infolog.

when you update the def correctly, it stops warning you.

knorke wrote:But the idea could be taken one step further: Not add footprint and some other tags to the unitdef files at all. Have as much as possible automatically applied

I agree but then I would be forcing my design concept. I should do this for GRTS though, no point in having those tags in unit defs. I wonder if it would work.

this code was created with 2 thoughts:

1) After talking with godde, I needed to check my movedefs.

2) I should make a more flexible version for people to see how many movedefs they need to fix.(forb used it like this IIRC) Others may not use the code but the knowledge to write their own.(which did happen, nio wrote his own)

For the record CT used this and I was very happy Smoth made it. I think it's a great tool because it revealed a lot I didn't know about movedefs (that the engine doesn't tell you about anyways...)

With the new depthmod stuff coming up I think it would be great to add it in.