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
Joined: 22 Feb 2006, 01:02 Location: cheap kitchen
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.
Seems hackish, if only for always having the "Warning!..." in infolog.
when you update the def correctly, it stops warning you.
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)
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum