changing yardmaps (possibly backward compatibility breaking)

[jK]

Anyone who worked unitdef's yardmaps knows how crappy they are.
I touched the code more randomly now, and had to clean it up to understand what it is doing. After understand how it works I want to fix some design failures in it but duno what's the best way to do so.
First an explanation how it works currently (I saw a damn lot incorrect strings n games!):

• o = always blocked
• y = always open for walk & build
• c = yard (can be closed & opened via COB/LUS)
• spaces are ignored
• any other char not listed above is treated as "o"=blocked! (including newlines!)

It's quite obvious that o=blocked, y=open, c=yard doesn't make any sense! Imo it should be:

• x = always blocked
• o = always open for walk & build
• y = yard (can be closed & opened via COB/LUS)
• i= inversed yard (blocks when yard is opened)
• all other chars are ignored (including newlines)

As you directly can see it breaks backward compatibility. Solutions for that are either translate code in _post.lua or using a special char (":" or "#") a the start of the string to switch to the new format. Any opinions?

[hoijui]

some ideas, though i cant see why/which one would be better/good:

1. use upper-case chars for the new system?

2. find a replacement for your new o (open) and y (yard)? (f_ree and t_toggable?)

3.

• x = always blocked
• _ = always open for walk & build
• n = yard closed -> blocking (can be closed & opened via COB/LUS)
• u = yard open -> blocking (inverse of n)
• newlines are ignored (or warning too if not in the right spot?)
• all other chars create a warning

[smoth]

Jk Iamfinewiththis.jpg

[zwzsg]

I remember having something to say about it seven years ago:
http://springrts.com/phpbb/viewtopic.php?f=12&t=2393

[FLOZi]

I don't really see the need for it other than the implementation of i (which doesn't have much use at all, as indicated by zwzsg's link)

[zwzsg]

If it is just switching the characters around their role so they make more sense to you, then DO NOT DO IT! You will confuse hundreds of modders for years.to come. We will gain nothing because anyway it's not like any new letter code will be useable without looking up the reference.

If it is adding new character sfor new features, then ok, but I expect that with 26 letters in the alphabet you'll find enough unused.

Also, please don't use characters that were used in TA for different role. I know how you all enjoy pretending Spring has nothing to do with TA, but having compatible unitdef tags really help for new modders, for people looking up TA doc when Spring doc is lacking, for people porting TA units to Spring, for legacy mods, etc...

[Jools]

• o = always blocked
• y = always open for walk & build
• c = yard (can be closed & opened via COB/LUS)
• spaces are ignored
• any other char not listed above is treated as "o"=blocked! (including newlines!)

It's quite obvious that o=blocked, y=open, c=yard doesn't make any sense! Imo it should be:

• x = always blocked
• o = always open for walk & build
• y = yard (can be closed & opened via COB/LUS)
• i= inversed yard (blocks when yard is opened)
• all other chars are ignored (including newlines)

It is not obvious at all. The first version makes more sense. Look at it visually, not as letters in English alphabet.

[FLOZi]

o - obstacle
y - yard
c - construction

[knorke]

changing around existing letters seems like a bad idea, there will just be confusion.
Being able to dynicamically alter all the yardmap.jpg might be nice, for factories with multiple buildpads and such.
Like Spring.SetUnitYardmap (unitID, "ooocc...")
(do not really need it though, just an idea)

[CarRepairer]

Why not just create a new tag yardmap2 and if present ignore yardmap? With a better name than yardmap2.

[Pxtl]

Why not just create a new tag yardmap2 and if present ignore yardmap? With a better name than yardmap2.

This. If you're going to change the yardmap syntax, call it blockingmap or something.

[jK]

some ideas, though i cant see why/which one would be better/good:

1. use upper-case chars for the new system?

3.

• x = always blocked
• _ = always open for walk & build
• n = yard closed -> blocking (can be closed & opened via COB/LUS)
• u = yard open -> blocking (inverse of n)
• newlines are ignored (or warning too if not in the right spot?)
• all other chars create a warning

Current code already use StringToLower, but I don't think TA supported it and no one used it. So it might be an option. n/u are a nice pair but not obvious imo.

o - obstacle
y - yard
c - construction

Ever played Battleships? All ppl use x for hit/occupied and o for water/open, same for nearly all other pen & paper games.
Neither is y=yard free to my mind, from a non-TA perspective it's what COB/LUS can control (open/close the yard).

And Spring is not TA, so tags should be neutral obvious and not TA obvious.

Why not just create a new tag yardmap2 and if present ignore yardmap? With a better name than yardmap2.

This. If you're going to change the yardmap syntax, call it blockingmap or something.

But ... but ... yardmap is such a nice tagname :<

PS: currently the buildplacing code is ignoring the yardmap, it would be possible to fix this so you could create a small 2x2 building and later build a 8x8 huge building on 4 pillars on top of it (currently not possible). (that change would be a 4 liner)

[Pxtl]

Couldn't you use this to create wierd overlapping buildings?

That is:

Code: Select all

xoox
oooo
oooo
xoox

could overlap with itself

Code: Select all

xoox
oooo
ooxoox
xooxoo
  oooo
  xoox

which would make for ugly collisions if the unit wasn't designed for it.

I'd want to see a special tag for "can build stuff in here" not just using "o" for that.

[PicassoCT]

first of all: our personal comfort is secondary here, if we can make spring more accesable:
(speaking variables?)
o_Open_x_Closed_y_YardMap:

Or you could read it from a supersmall bitmap. black is blocked, white is walk all the time, grey is only if yardopen.


Or we extrapolate them out of the the s3o modell. Devineatly less work for us moddevs.

[Beherith]

A small bitmap is clunky and hard to edit en masse. Its about as horrible as the bitmap feature placement in mapconv.

Im with zwzsg on this issue, if it doesnt add major functionality, im against the change.

[zwzsg]

And Spring is not TA, so tags should be neutral obvious and not TA obvious.

It still immensly help modders when different games share a common modding syntax. Even if this is only two games!

If you were designing a new programming language supporting pointers, would you invert the meaning of * and & just so you could claim to be a different language?

On your house, do you paint the cold water faucet red and the hot one cold just because it feels more logical to you? (red is colder lightwave than blue after all).

PS: currently the buildplacing code is ignoring the yardmap, it would be possible to fix this so you could create a small 2x2 building and later build a 8x8 huge building on 4 pillars on top of it (currently not possible). (that change would be a 4 liner)

Yes, such addition would be cool. Just get a new letter for it.

[FLOZi]

o - obstacle
y - yard
c - construction

Literally don't know what could be simpler and more obvious.

[Forboding Angel]

Imo it should be:

• x = always blocked
• o = always open for walk & build
• y = yard (can be closed & opened via COB/LUS)
• i= inversed yard (blocks when yard is opened)
• all other chars are ignored (including newlines)

Imo this is 100% perfect.

[Forboding Angel]

It's worth noting that I have been doing this for quite a while now, yet I still have to look up what each of the yardmap characters means every time I work with them. The current implementation sucks and needs to be changed.

I could give a crap less if noobs from *A come and have to learn something new. That community has been dying for a decade now anyway.

[Google_Frog]

While the new characters make more sense to me the old ones still make some sort of sense. I don't see the advantages of switching over outweighing the cost.

I like the inversed yard idea though and it would be nice to distinguish between "factory can place nanoframe here" and "other things can place nanoframe here".