Spring RTS Engine

JAZCASH wrote:That's just a phase new 16 players maps go through until eventually DSD rolls back into play.

I know you like being a troll but be a little bit nicer. Artturi is working hard on this!

I runned this map with syncdebug test build with 4 players. Thanks to them! It got immediate sync errors but I failed a bit log them and stacktraces stopped. However, Tobi was able to find out that there were different pathing checksums. Next test, after clearing all paths for all players, appeared to be completely sync error free. Mapoptions worked fine and no errors occured ever since.

It's a mystery unsolved. I rest my case, if you are able to figure something out, let me know...

SirArtturi wrote:immediate sync errors [..] However, Tobi was able to find out that there were different pathing checksums. Next test, after clearing all paths for all players, appeared to be completely sync error free. Mapoptions worked fine and no errors occured ever since.

It's a mystery unsolved. I rest my case, if you are able to figure something out, let me know...

Is pathing done after or before applying the mapoptions?

smoth wrote:

JAZCASH wrote:That's just a phase new 16 players maps go through until eventually DSD rolls back into play.

I know you like being a troll but be a little bit nicer. Artturi is working hard on this!

Heh, I knew somebody would make a stupid comment about that post. There's just too many dumbos to let it pass.

Ok, basically, there is no offense in that post. I did not by unkind or any of the nasty words you can think of. I was just stating that everybody returns back to DSD after a week or two of the new maps. That is a fact. Many maps have come before but DSD will eventually dominate once again.

I love all Artturi's, Beh's and many others maps much much more than DSD. I'd prefer they were dominant instead of DSD. But that doesn't change the fact that DSD is a newbwhoreporctech map and it shouldn't stop me from stating that. As much as it does actually suck.

Artturi is not stupid, he does not need any discouraging remarks. As a community, if we want to see things get better around here we need to be supportive. We all know the situation with the average user and their preference to play the same map with the same mod all day long. That has been the case for years. I have made many threads about it and caught ample flak for them.

However, to be discouraging to people who are trying to genuinely provide new and better alternatives. I just cannot see that as appropriate.

Unfortunately that's the situation in most commercial games as well,people play the same map over and over again,in fact,compared to commercial games were not doing so bad.

we are not doing bad at all. I think we need to be a bit more supportive.

Gota wrote:Unfortunately that's the situation in most commercial games as well,people play the same map over and over again,in fact,compared to commercial games were not doing so bad.

Yeah, BA+DSD is just Spring's answer to de_dust or CTF-Face

And I do see other maps in rotation on BA+DSD servers, they just have to be DSD-like (porcy team-maps). You still see Altored_Divide occasionally, you get Tabula_v2 and Small Supreme. FolsomDamSpecial fits with those maps - it's porcy, it's suitable for a large team-game. It could easily sit alongside them as another "I'm bored of DSD, let's play one of those other porcy team maps for a change" map.

Still, the crowd is fickle - I couldn't tell you why (for example) LLTA Complex, DesertSiege and NuclearWinter - other good DSD-style maps - haven't caught on the same.

This map gets played suprisingly a lot. I'm almost certain it will be at least in the group with other similiar newcomer hits like Nuclear Winter, Titan, LLTAComplex, Kappa Basin etc. that tries, not to replace the most popular maps, but to give good alternatives to the big team gameplay map cycle. Moreover, considering the popularity of folsomdamfinal, this should go along very good because its more improved version.

smoth is partly right in what he is saying. I dont need any remarks whatsoever discouraging nor "informative" or "back to the reality." I am very well aware of the situation. If I were not, I wouldnt be making maps like these... However Im not offended or discouraged of Jaz or anyones sayings, because I've already heard and faced them a lot. So np... What annoys me instead, is constant nagging about tiny things that doesnt actually matter. We are not playing crysis here... Let's say for example whining about fog being too laggy or heavy. That doesn't mean that the fog wouldnt suit for the map if its too heavy for your PC for christ sake. Or that doesnt mean you have to use the fog since its a damn option of the map...

Therefore we can stop this popularity "yay or nay" debate and go back to the topic, which is the map itself and the sync errors...

zwzsg wrote:Is pathing done after or before applying the mapoptions?

You mean when is the mapoptions applied during that test process or altogether in maps operation process?

For the test, mapoptions were applied before first run and the syncerrors, aswell as after path clearing and second launch. I always change the options before another run.

And for the operation process, AFAIK, mapoptions are always applied before launch except the spring.exe when spring.getmapoptions == nil. Correct if im wrong...

SirArtturi wrote:damn option of the map...

Unintentional? Probably, but I lol'd the same...

zwzsg wrote:Is pathing done after or before applying the mapoptions?

Depends how you define "applying".

The map info (SMD) is read before pathing. So the Lua is executed before pathing too.

Whenever the map info (that may be modified using map options) is used depends on the particular key. MinHeight and MaxHeight are used once when loading the heightmap, sun color & direction is used every time the world is rendered, etc.

All options that influence pathing data should be included in the path hash, though, therefore triggering re-pathing whenever you change such option.

(See also the thread about this.)

smoth wrote:Artturi is not stupid, he does not need any discouraging remarks. As a community, if we want to see things get better around here we need to be supportive. We all know the situation with the average user and their preference to play the same map with the same mod all day long. That has been the case for years. I have made many threads about it and caught ample flak for them.

However, to be discouraging to people who are trying to genuinely provide new and better alternatives. I just cannot see that as appropriate.

Encouragement and discouragement isn't going to make any difference. Support and all that bollocks is stupid when there is nobody actually doing anything about it. I'm being realistic. DSD does tend to be the map that everybody comes back to after about a week or two of these awesome maps. Imo, that needs to be stopped.

I could quite happily delete DSD from my maps folder if I knew I would be able to play games as much as I would with DSD in my map folder.

If I had my way, I wouldn't allow any hosts to host nothing but one map. Secondly, I would give higher ranked players more vote weight as they're usually the ones trying to play something other than DSD cause they're sick of it.

Artturi is doing something. I wouldn't be so supportive if I thought artturi was an asshat.

This is a good solid map.

Be nice.

Not saying this map sucks, it looks great really. Havent played it yet though.

smoth wrote:Artturi is doing something. I wouldn't be so supportive if I thought artturi was an asshat.

This is a good solid map.

Of course it is. I never said it wasn't and I haven't been unsupportive in any of my posts here.

What I wanted to say is that, considering the pathing depends on the map heightmap, and that the map heightmap depends on the map option, if the map option makes the map heighmapt change before the pathing is done, then the checksum the pathing file end up with depends on what was the map option at the time. Two users who played alone the same map with different map options end up with different pathings. When they meet online, the pathing files are different and it desyncs.

My theory is probably all wrong, just checkin'

zwzsg wrote:What I wanted to say is that, considering the pathing depends on the map heightmap, and that the map heightmap depends on the map option, if the map option makes the map heighmapt change before the pathing is done, then the checksum the pathing file end up with depends on what was the map option at the time. Two users who played alone the same map with different map options end up with different pathings. When they meet online, the pathing files are different and it desyncs.

My theory is probably all wrong, just checkin'

it is wrong. Works fine in gundam.

zwzsg wrote:What I wanted to say is that, considering the pathing depends on the map heightmap, and that the map heightmap depends on the map option, if the map option makes the map heighmapt change before the pathing is done, then the checksum the pathing file end up with depends on what was the map option at the time. Two users who played alone the same map with different map options end up with different pathings. When they meet online, the pathing files are different and it desyncs.

My theory is probably all wrong, just checkin'

Heightmap is included in path hash (refer to other thread for applicable definition), so path files should have a different name depending on the value of this option.

EDIT: Hmm, you do give me one new theory tho... the hashing is pretty whacky. I'm pretty sure I can construct a map with a map option that reliably breaks pathing and causes sync error, by generating a hash collision using a map option. (and if I'm right I can do this with any heightmap..., just needs some particular minHeight and maxHeight values.)

Tobi wrote:

zwzsg wrote:What I wanted to say is that, considering the pathing depends on the map heightmap, and that the map heightmap depends on the map option, if the map option makes the map heighmapt change before the pathing is done, then the checksum the pathing file end up with depends on what was the map option at the time. Two users who played alone the same map with different map options end up with different pathings. When they meet online, the pathing files are different and it desyncs.

My theory is probably all wrong, just checkin'

Heightmap is included in path hash (refer to other thread for applicable definition), so path files should have a different name depending on the value of this option.

EDIT: Hmm, you do give me one new theory tho... the hashing is pretty whacky. I'm pretty sure I can construct a map with a map option that reliably breaks pathing and causes sync error, by generating a hash collision using a map option. (and if I'm right I can do this with any heightmap..., just needs some particular minHeight and maxHeight values.)

Well, couple questions arise considering this map. There is no actually any options effecting heightmap, unless typemap doesn't do that? However, There is minheight and maxheight values assigned in general.lua if mapoptions are used. Although they are very same as in compilation and not used in mapinfo, could this have some effect? You see, I haven't done everything same as in smoth's options...

Edit: Ok here are the lua's if you are interested to take a look.

http://pastebin.com/m7259f147
http://pastebin.com/m7e2b38e
http://pastebin.com/m6e4da445