Spring RTS Engine

Kloot gets all pissed off when we say shit doesn't work, but he doesn't bother to explain ANYTHING to any of us on how to optimize pathing and unit movement.

So, can some engine dev PLEASE explain, heatmapping, how to use it, And QTPFS or whatever the fuck it's called, and how to use it?

Thank you.

I deliberately don't explain how to "optimize" pathing because everyone's idea of that is different and most information just gets misinterpreted anyway.

For the rest, you should already know how to use QTPFS because your game has a modrule for it (albeit commented out). You should also already know about heatmapping (advance warning: has no effect in QTPFS) because you wrote a guide (not to mention posts like this...) clearly indicating *that* it worked and you had a pretty good idea of the *how* in the past. Nevertheless, it may help to read what imbaczek links to in http://springrts.com/phpbb/viewtopic.php?f=14&t=20011 and/or the documentation in http://springrts.com/wiki/Movedefs.lua#Heat_Tags.

Heatmapping results in units turning in circles even with heatmod of 0.5 and heatproduced of 5 (default is 30).

Only a few units, but you need your units to obey your commands when you give them, not turn and go the other way.

The vast majority of your post is a big cop out. You Sit there and yell at everyone for doing it wrong but when anyone asks you for info you turn around and blow us off with statements that come irritatingly close to "read the code".

My "Guide" was an attempt to make it passable, nothing more. Evo pathing is pretty decent for the most part, but I get tired of units getting stuck on terrain and other stupid crap.

This:

I deliberately don't explain how to "optimize" pathing because everyone's idea of that is different and most information just gets misinterpreted anyway.

Is bs. All you would need to do is explain how you optimize it for your BA vids. The rest of us are capable of figuring it out on our own once we have a point of reference. Part of me thinks that you deliberately don't tell us anything so that you have an excuse to rage as us the moment anyone says the word pathing. You even rage at me, which is rich, considering I am one of two people who keeps continually sticking up for you when everyone else wants to jump on your case.

I'd wager that the vast majority of us would like to be able to use qtpfs, but just turning it on results in terrible behavior and we don't have the foggiest idea how to optimize it, and here you sit, lips sealed tightly.

sim: add heat-inspired path collision avoidance (new heatMapping, hea…
…tMod and heatProduced moveinfo tags)

description of new tags:
- heatMapping (boolean) enables/disables generation and usage of path heat.
default true.
- heatProduced (int) states how much heat to place on a square if a path goes
through it. heat is set to max(currentSquareHeat, heatProduced).
default 30.
- heatMod is the pathfinder cost modifier that is multiplied by the heat
of the current square. default 0.05.

none of those tags affect the path estimator, so changing them doesn't force a repath.

effects should be noticable when ordering tight groups of units to move
through huge flat areas.

I see now in clicking one of your links, heatmapping is explained a little bit more (the barest amount possible). Apparently I should be using 0.05 for heatmod (I used 0.5 in my test), which is arbitrary as all hell, but whatever. More testing is apparently needed, but it would be nice to at least have some inkling of what values produce nice results in certain situations.

Just give us a point of reference. Jesus, is it really that hard? Why do you insist on sabotaging yourself and all of your hard work? You make everyone angry by remaining mute and then basically give everyone the finger, when, with a few paragraphs and some code/tag references, you could give us the tools to create awesome things using your hard work.

I really do not understand your logic at all.

Obviously, from the tone of this post, I'm annoyed.

The BA crowd would wet themselves with joy over what settings you used to make these flash tanks behave like this: http://youtu.be/4rycY4JfLGs

And if the rest of us knew, we could extrapolate from that, settings for our own units.

Kloot wrote:For the rest, you should already know how to use QTPFS because your game has a modrule for it (albeit commented out).

Yeah well, by that logic, I should know vb.net fluently because I have Visual Basic 2008 installed.

Yeah, we can turn qtpfs on, but we don't have the foggiest idea how to use it, and as far as I know, you're the only one who knows how.

If I turn it on in evo, all kinds of crazy nonsensical stuff happens and pathing goes directly to hell. That's what happens by turning it on without changing any settings or anything. It isn't my fault for not knowing how where there is no instruction (that I am aware of). And a 2 sentence description in the wiki is not "instruction".

Could you please provide us with a baseline example? Pick any of your vids showing off the pathfinder, and explain how to achieve those results.

That shouldn't take more than 10 minutes of your time, if that.

Perhaps Forboding had forgotten, or had gotten the information for his modrule from a long forgotten chat? ( or copypasta ).

Eitherway some clarification in a nice format summarising things would be nice. To find QTPFS in the wiki I had to go through a number of pages to arrive here:

http://springrts.com/wiki/Modrules.lua, and found:

bool allowHoverUnitStrafing Default: true if using QTPFS pathfinder New in version 92.0
Allows hovercraft units to slide in turns.

and an example on lobby integration:

Configurable by modoptions
Interestingly modrules.lua can read modoptions, so these parameters can be scripted to be configurable from the lobby. For example to allow selecting either legacy default pathfinder or QTPFS via a modoption:
system = {
pathFinderSystem = (Spring.GetModOptions() and (Spring.GetModOptions().qtpfs == "1") and 1) or 0,
},

The QTPFS page itself is empty:

http://springrts.com/wiki/QTPFS

My general conclusion from just the wiki is that there is only 1 option that is different in QTFPS involving strafing of hovering units.

emmanuel's report said (quote) "heat seem not produce noticable effects" to which you literally replied "I've never gotten heat to really do anything that I can tell" (in direct contradiction to many of your posts here). So what conclusion am I more likely to draw from that? "Forb knows what he's talking about" or "Forb must have amnesia"?

when anyone asks you for info you turn around and blow us off with statements that come irritatingly close to "read the code"

So the links I pasted weren't enough info for you? What would be then? Also, "read the code" pretty quickly becomes the best answer because explaining crap beyond a certain level of detail would be equivalent to writing code but with more words and less precision.

Heatmapping results in units turning in circles even with heatmod of 0.5 and heatproduced of 5 (default is 30).

Yes, the heatmapping implementation is far from perfect (not a new fact). That's why it was disabled in the first place (not a new fact to you either). Still not the same as claiming you never got it to do anything or that it has no noticable effects. Use phrases like "I never got heatmapping to perform effectively without bad results" if you want to avoid confusion.

Evo pathing is pretty decent for the most part, but I get tired of units getting stuck on terrain and other stupid crap.

Tested the 92.0 candidate builds?

All you would need to do is explain how you optimize it for your BA vids. The rest of us are capable of figuring it out on our own once we have a point of reference.

No, I don't, because those vids are all based on default settings and anyone including you can fire up the engine (with BA) to replicate them, then start playing with the parameters and learn more than from my dry instructions. But most people aren't so adventurous and it seems they never will be.

The BA crowd would wet themselves with joy over http://youtu.be/4rycY4JfLGs

From a PM conversation I had with Beherith, I can safely say that's not anywhere close to the emotional response the BA crowd would have and that it doesn't meet their "ideas" of optimized pathing whatsofuckingever, so I really don't care.

Just give us a point of reference.

I gave you the best point of reference on heatmapping that exists (imbaczek's docs). Do I feel like improving it, given that the feature is semi-functional at best and not my own work? Not really.

it would be nice to at least have some inkling of what values produce nice results in certain situations

Sure, yet I am the best person to provide nice defaults for a feature I didn't write because...? And in the case of heatmapping good defaults may not even exist.

Yeah, we can turn qtpfs on, but we don't have the foggiest idea how to use it, and as far as I know, you're the only one who knows how.

"How to use it"? We're talking about a damn pathfinder, all you do is tell units where to go and the code will figure out the rest. It does not come with a 500-page manual you need to read first.

I'd wager that the vast majority of us would like to be able to use qtpfs, but just turning it on results in terrible behavior and we don't have the foggiest idea how to optimize it, and here you sit, lips sealed tightly.

...

If I turn it on in evo, all kinds of crazy nonsensical stuff happens and pathing goes directly to hell. That's what happens by turning it on without changing any settings or anything. It isn't my fault for not knowing how where there is no instruction (that I am aware of)

WTF?

This is the first time you have ever even mentioned these problems to me, so how do you expect me to know about this, by consulting my crystal balls? Furthermore, do you really think I would just sit on my hands ignoring such bugs if I had encountered them in testing for myself? How can you possibly make the colossal mental leap from seeing obviously broken behavior to thinking "naw imma just assume there be hidden switches and kloot ain't tellin' us what they are cuz hell, he likes sabotaging his own efforts"??

Again, WTF?

(how QTPFS should work, out of the box, in any game, and FWIW I test-ran Evo 5.97 on this development build and had absolutely no issues with QTPFS enabled, so... you tell me what to believe here)

AF wrote:To find QTPFS in the wiki... <snip>

Yet you somehow managed to avoid hitting http://springrts.com/wiki/Modrules.lua# ... nderSystem which tells you how to enable it?

It is intentionally a wanted page - for now.

Kloot wrote:emmanuel's report said (quote) "heat seem not produce noticable effects" to which you literally replied "I've never gotten heat to really do anything that I can tell" (in direct contradiction to many of your posts here). So what conclusion am I more likely to draw from that? "Forb knows what he's talking about" or "Forb must have amnesia"?

Maybe you should use your brain and think "Forb must have done some testing after reading what I wrote".

Tested the 92.0 candidate builds?

Well gee, I've been posting 92+ bugs on mantis for a week. What do you think?

No, I don't, because those vids are all based on default settings and anyone including you can fire up the engine (with BA) to replicate them, then start playing with the parameters and learn more than from my dry instructions. But most people aren't so adventurous and it seems they never will be.

It's hard to be adventurous when you have no fucking idea what does what and how what you are doing will affect the outcome.

What are you so afraid of, Kloot?

I gave you the best point of reference on heatmapping that exists (imbaczek's docs). Do I feel like improving it, given that the feature is semi-functional at best and not my own work? Not really.

I was referring to QTPFS and the pathfinder in general.

Sure, yet I am the best person to provide nice defaults for a feature I didn't write because...? And in the case of heatmapping good defaults may not even exist.

I was referring to QTPFS.

"How to use it"? We're talking about a damn pathfinder, all you do is tell units where to go and the code will figure out the rest. It does not come with a 500-page manual you need to read first.

Well then the code has a learning disability, because I'm pretty sure my order didn't tell those units to drive in the opposite direction.

This is the first time you have ever even mentioned these problems to me, so how do you expect me to know about this, by consulting my crystal balls? Furthermore, do you really think I would just sit on my hands ignoring such bugs if I had encountered them in testing for myself? How can you possibly make the colossal mental leap from seeing obviously broken behavior to thinking "naw imma just assume there be hidden switches and kloot ain't tellin' us what they are cuz hell, he likes sabotaging his own efforts"??

Well, you have had people jumping all over your case for 6+ months about the pathfinder. I have been trying to be supportive and not pile on more. I understand how frustrating that can be.

You not explaining to us the nuances of the pathfinder directly hurts you. I don't understand how you are blind to that.

(how QTPFS should work, out of the box, in any game, and FWIW I test-ran Evo 5.97 on this development build and had absolutely no issues with QTPFS enabled, so... you tell me what to believe here)

I will play a game and record it. If that really is the case (not that I think you're lying, just so that way I have a point of reference), then hells yeah! Evo will be the first game to effectively use QTPFS! That's pretty cool!

Sadly, the results were pretty dismal: http://www.twitch.tv/forbodingangel/b/371397927

Uploading to youtube as soon as twitch gets off of it's ass and actually uploads it.

Edit: http://youtu.be/zxvmF_gb7Ng

Thanks for taking the time but the "Reading Estimate PathCosts" text on http://i.imgur.com/RthT1Os.jpg means QTPFS wasn't loaded at all. Press 'i' ingame if you want to be sure.

LUPS errors are with 99% certainty due to the GML build type that is now default.

the units stuck on hillsides could be because the current pathing and old pathing code can from time to time PUSH units into places they should not be able to get in. Resulting in stuck units.

I don't understand...

Is the above incorrect? Because that's what was in modrules.lua

where do I get your working copy from? I can take a look forb.

https://code.google.com/p/evolutionrts/ ... les.lua#13 ?

Knorke, if you notice in the vid, I am using Evolution RTS - $VERSION. That is my local working copy, so, since I don't want to screw up my releases nor pointlessly enable QTPFS with a commit, I uncomment it, and then run spring using my working copy.

@smoth
http://evolutionrts.googlecode.com/svn/ ... iondev.sdd

missing , after }

Arugh -_-

Thanks.

Actual QTPFS this time: http://www.twitch.tv/forbodingangel/b/371489066

http://youtu.be/oPUOfE63VNw

Results are very QQ.

FLOZi wrote:

AF wrote:To find QTPFS in the wiki... <snip>

Yet you somehow managed to avoid hitting http://springrts.com/wiki/Modrules.lua# ... nderSystem which tells you how to enable it?

It is intentionally a wanted page - for now.

I found it, but the on off switch isn't what was asked for, it was how to configure and optimise.

Apart from units getting stuck on edges of path-able regions, that QTPFS demo looked pretty good. Units (especially ships) get stuck on the edge of pathable regions with classic pathfinder too, although you can mitigate the effect a bit by carefully smoothing your heightmaps.

(I'm guessing the jumpiness in the video is your recording and not a spring problem? It dosn't happen for me, although when the game gets very large QTPFS does eventually slow down.)

Yeah, the jumpiness is just the encoder being stupid.

Actually, in the normal pathfinder, units never get stuck on the building features.

Heightmap is 16bit, plus, as per usual, compiled with -l (because I like what running lowpass does for the final heightmap).