Spring RTS Engine

I find this situation frustrating. It is not that I am upset with you. I find this situation to be one I dislike and cannot lol about it.

I have no problem lolling for the both of us.

lol, that did make me lol. lol, yeah dude, when I get all serious I have less of a sense of humor then tom does *pokes tom*

How about seperating the code that does path-calculating, and allowing paths to be calculated from the lobby, in the background? :)

I don't know what's going on here but let me say this: lol.

gavan wrote:How about seperating the code that does path-calculating, and allowing paths to be calculated from the lobby, in the background? :)

Or just run spring.exe with the mod and map you want, beforehand

Or... Just get a better processor..

Gameplay, tard, go for gameplay...

edit: ....Will get back to you on that.

Well, what would you expect

Maybe, I was a bit too harsh..

Sorry, Caydr.


Yes, this thread is full of lol's and a funny lookin' poll..

(It must be rigged, huh?)

I'm lost. Just completely lost... when did the system get changed so that footprintx and footprinty from the moveinfo weren't the sole thing that determined where a unit could pathfind? When I first ported AA, the FBI footprint values only drew the green square around the unit, and the moveinfo was what actually determined the unit's ability to move around...

When did that change? I just did a quick test with a bunch of krogoths using a flea's movementclass and they didn't clip to death. This is so weird. That has to be a recent change. Has got to be. There's nothing in the changelog about it... was it changed but not documented? I just don't get it. I had no idea at all.

I'm going to play around with this for a bit... see what sort of effects different footprint sizes in different places in different units has... This completely rewrites the book for me.

Unless of course I'm right. Which I'm already pretty sure I'm not. But if I am, there's going to be gloating like the world has never seen.

...You can understand, based on my understanding of how movement classes worked, why I'd make a poll like this. With an ideal, "more movement classes whenever it might improve gameplay" way of doing it, the loading time would be increased significantly and I wanted a general consensus on what people would think of 40-50 movementclasses. Just subtle variations where appropriate, but general consistency between them (so all "normal" tanks would have the same slope tolerance, same for kbots... just more different footprint sizes and ... stuff...)

Geez, I've got my work cut out for me now. Gotta completely revamp the whole movement system (something I'm certainly NOT too lazy to do if it results in better user experience)... will work on it tomorrow when I get home.

gavan wrote:How about seperating the code that does path-calculating, and allowing paths to be calculated from the lobby, in the background? :)

that's actually a really good idea

I am quite positive that the footprint in a movetype affects the unit. I have had units that have a smaller movetype footprint try to path through spots they cant fit. Conversly I have seen units get stuck in factories because of movetype footprint. It most certainly does affect stuff.

You absolutely need a different movetype to cover all of these:

-Each unit of a different footprint size NO exceptions
-Each unit you want to have a different slope tolerance
-Each unit you want to be amphibious
-Each kind of ship size
-Each Amphibious slope tolerance


Additionally Im not sure the number of move classes influences load time, I think it has more to do with the number of units and other factors. Some could do a test, but I suppose the best would be 20 units 1 movetype, and 20 units 20 movetypes, see which loads faster. Point in case its better to make sure everything is accounted for in this situation than compromise and get issues from condensing a movetype. Make as many as you have units with different footprints, slopetolerances, and move manners.. there is no way around this..

Yeah, I haven't done full blown testing of every possible consequence, I just know it works well enough for KP, where there's no Footprint lines in the movinfo.tdf and were units of different sizes share the same movement without me noticing any issues.

I have seen units get stuck in factories because of movetype footprint. It most certainly does affect stuff.

Well, if you have no,or smaller movetype footprint, how could it make unit getting stuck in factory?

I have had units that have a smaller movetype footprint try to path through spots they cant fit.

Ok, I'll have to try that. Still, 'smaller movetype footprint' makes little sense when there is no movetype footprint. If it mattered with a 'No' defaulted to zero or infinity I'd have noticed issues already, so the more logical explanation was that it wasn't used.

Even if sharing movementclass between different size had issues, which I don't even believe it has, at least now Caydr know there is a third way between his two poll options. Considering he deemed the issue important enough to deserve a GD poll, Caydr had to be made aware of it. Since he completly ignored KDR_11k short and to the point message, I had to emphase it with some snicker.

Fanger wrote:Additionally I'm not sure the number of move classes influences load time, I think it has more to do with the number of units and other factors. Some could do a test, but I suppose the best would be 20 units 1 movetype, and 20 units 20 movetypes, see which loads faster.

Never noticed how the "Pathing 32 1/20" ""Pathing 32 2/20" etc... is what takes the longest when playing a new map & mod? When making one-unit test mods, it often happened to me to grab the full moveinfo.tdf of another mod, to be annoyed by the long pathing time, and to remove all but one class, and then difference is huge and clear.

I tested it, Kernel Panic assumes a 1x1 footprint for all units for pathing.

Indeed, I just tested too, and with no footprint in the movementclass, a big tank stay stuck trying to pass into a narrow it can't fit in.

Caydr wrote:But if I am, there's going to be gloating like the world has never seen.

Have fun!

IF the moveinfo footprint is larger than the actual footprint and the factory is meant to take the units actual footprint, the unit will look at its pathing which is determined by the moveinfo and go aha I cannot move through here and thus it will be stuck dont tell me this isnt the case becasue it is. Additionally of course a unit with no footprint in the move type cant move, you essentially made it not exist..

Frankly Zwzsg, unless you get me code proof that having lots of movement types causes slow down in loading, Im inclined to not make a judgement either way.. I personally think its better to go for more accurate movement than to skimp and have potential issues..

Um first off, every single movetype causes Spring's pathfinder to re-evaluate the map. Try NanoBlobs vs. AA, and watch how long it takes on that step of loading a new map.

HOWEVER. Now that this stuff is cached by Spring... who gives a flying chipmunk? Players will only have to do this ONCE PER MAP, ONCE PER VERSION OF SPRING. And even less, if the devs leave that part of Spring alone, which, quite frankly, I doubt will be happening after this version's (finally) out.

So, if it really makes that big of a difference in gameplay, by all means, use it.

HOWEVER. How often does a pathfinding mistake really screw up a mod or a game? I dunno about you guys, but I guess I just see this as a very minor issue, with relatively minor gameplay ramifications, and has hidden processing costs, to boot. It's a less-obvious version of 24-sided cylinders, but it's still waste, when elegance is required.

Oh, sure, sometimes a tank might get stuck. Big whoop. Micro it. They get stuck sometimes, even if the pathfinding is supposedly perfect. However, I'd wager that most of the time, the tank pathfinds adequately for the purpose. Maybe not perfectly, but adequately. Every map that gets made for each movement type has to get used by each unit, when you give it a move order- and I strongly suspect that if you are caching fewer of these, then pathfinding calc takes less time.

Let's do a simple experiment: somebody, take a KP unit, and let's compare two scenarios:

1. Unit has 1X1 footprint (smaller than the actual footprint, duh), and will occasionally get hung up on map features.

2. 30 units, all with perfect (but DIFFERENT) settings. It doesn't matter if their footprints are all the same, differences in the Slope Tolerance values of 1 point are sufficient.


My guess is that when we look at CPU hit, no. 1 wins, hands-down.

And, to put things into perspective.... I'm working on a mod with about as many units in it as AA. Guess how many Movetypes I've used, thus far? 9. It'd take some very serious proof to convince me that this is worth either eating up some player's life on Earth, or eating additional CPU during anything but light combat, to convince me that Caydr's argument has serious merit.

This makes me wonder if Gundam has proper footprints, the units tend to get stuck on small openings between buildings.

give me a list on the forum and I will look into them.

I think it was a bunch of RGMs (both types) and an Ez8, also T2 cons have this tendency to get stuck on buildings.