Spring RTS Engine

Wet/Dry options can't be done from modoptions, which is why I want to retroactively add them to all old maps via base.

FLOZi wrote:Wet/Dry options can't be done from modoptions, which is why I want to retroactively add them to all old maps via base.

My response to this would be to fix the "can't be done from modoptions" part.

SinbadEV wrote:

FLOZi wrote:Wet/Dry options can't be done from modoptions, which is why I want to retroactively add them to all old maps via base.

My response to this would be to fix the "can't be done from modoptions" part.

Map (and its option code) is loaded before mod, afaik. Meaning that isn't really practical.

A dry option can perfectly be a modoption. But it would still be more logical to have it in the map tab.

SinbadEV wrote:No! I'm not sure if we should call this kind of reaction a Smoth-gasm, Argh-rage, AF-drop...

Argh threatens to take back his contributions.

Af attacks other related projects.

I feel disrespected and see no reason to devote my time in efforts that are met with ill will. That is a trepandation.

Don't compare me to argh, I don't do this for some sort of personal ego boost. I am not af. I do not do things when i feel I am hurt for doing them. That makes me nothing like them.

SinbadEV wrote: I understand when people demonstrate a lack of appreciation for your hard work it is upsetting... but the loud-minority that harshes your praise-buzz shouldn't stop you from contributing.

praise buzz? This crap was done 6 months ago and people are still just now looking at it. It was included in gundam rts and people could give two fucks. In general I saw my work as ignored and I was fine with that. I was temporarily elated that someone else found something I wrote useful. then immediately disappointed to see a community member I respect, Z, rip it apart rather than ask questions about why it was done the way it was.

Oops, have I angered the Smoth? I'm not sure if ripping means stealing or badmouthing, but I'll assume the later. Don't be so sad, Smoth. Your code is so liked that not only other mappers start using it, but you even have FLOZi lobbying for inclusion in base file. Not an random clueless enthusiastic forum noob, no, but FLOZi, a knowledgeable, temperate, veteran modder. That such a person finds your code so good he sees it fit for being applied to every Spring map should be telling.

As for me, I didn't even disagree, I just mentionned I'd like the code to proof checked first.

zwzsg wrote:A dry option can perfectly be a modoption.

By what method? Spring.AdjustHeightMap / Spring.SetHeightMapFunc? You know as well as I do good sir that that method is computationally expensive (and does not change the F2 map), whereas the mapoptions have access to the smd and can change min/max height in the blink of an eye.

Well, if it's only done once at startup, and use the SetHeightMapFunc, it's not that bad. Maybe two more seconds in a 10 second loading. I had not noticed about the F2 map though. So yeah, doing it map side would be best.

zwzsg wrote:Well, if it's only done once at startup, and use the SetHeightMapFunc, it's not that bad. Maybe two more seconds in a 10 second loading. I had not noticed about the F2 map though. So yeah, doing it map side would be best.

I should probably have mentioned that I tried to do it that way first.

Suffice to say trying to do all the map in GamePreload() resulted in a lot of hangs and std:bad_alloc crashes Doing it for all the land under 0 height was more tolerable, depending on the map. But the F2 map is a major barrier I couldn't figure a way past.

Perhaps we need an "automagical" SMD loader as well, so that all these variations are intrinsically supported via the options or simple config?

I am not so sanguine about map-side game alteration; I suspect that will cause more problems than it's worth.

Smoth, I don't think Z meant what he said the way you took it.

As for Z and flozi, please take a hard look at Tale of two hills and the code therein. THe way stuff is done in there is nothing short of genius.

Beherith wrote:ZW, have you tried the map xenolithic v4? That should have working snow for you.

I tried Xenolithic V4, ATI driver errored out, screen went black, alt-tab and ctrl-alt-suppr did nothing, had to reboot. A bit like CA. I suspect some bug was introduced in 0.81 as I never had such severe issues in previous version of Spring.

So I'm finally looking over this again.

I'd like to see a wetness (perhaps Map Default/Dry/Half/Double options), invert heightmap and night/day control retroactively applied. With the code rewritten to always default to the maps original configuration in all aspects.

Any major concerns with those? Anyone feel others should be part of the defaults?

FLOZi wrote:I'd like to see a wetness (perhaps Map Default/Dry/Half/Double options), invert heightmap and night/day control retroactively applied. With the code rewritten to always default to the maps original configuration in all aspects.

Not wetness, dryness maybe, but def not wetness.
Invert heightmap is a gimmick I have never seen anyone use it. No need or point in using it.
Day/night will have color issues.
Snow, rain and fog should be possible with the least amount of hiccups.

Yes. I don't think there should be any mapoptions forced for maps by default. All those stuff should be opt-in by the mapper.

Auswaschbar wrote:Yes. I don't think there should be any mapoptions forced for maps by default. All those stuff should be opt-in by the mapper.

And they will be, for new maps. The point is to fulfil missing functionality in current maps with no mapoptions of their own.

Beherith wrote:Not wetness, dryness maybe, but def not wetness.
Invert heightmap is a gimmick I have never seen anyone use it. No need or point in using it.
Day/night will have color issues.
Snow, rain and fog should be possible with the least amount of hiccups.

• So we still need to rerelease maps for 'flooded' or 'wet' versions? What difference does it make if we dry a wet map vs flood a dry map?
• Invert may not get used much, but it is an interesting option that won't break anything.
• Only if they are coded without respect to the maps default settings.
• You complain about wind breaking immersion on asteroids but want to see snow on a desert map?

FLOZi wrote:

Auswaschbar wrote:Yes. I don't think there should be any mapoptions forced for maps by default. All those stuff should be opt-in by the mapper.

And they will be, for new maps. The point is to fulfil missing functionality in current maps with no mapoptions of their own.

Yeah, they have no mapoptions of their own. So its natural to assume mapper didn't want any mapoptions in them.

If you miss certain stuff in particular maps, go make mutator. But please leave current maps as they were designed.

Auswaschbar wrote:

FLOZi wrote:

Auswaschbar wrote:Yes. I don't think there should be any mapoptions forced for maps by default. All those stuff should be opt-in by the mapper.

And they will be, for new maps. The point is to fulfil missing functionality in current maps with no mapoptions of their own.

Yeah, they have no mapoptions of their own. So its natural to assume mapper didn't want any mapoptions in them.

If you miss certain stuff in particular maps, go make mutator. But please leave current maps as they were designed.

Not really. Noone was really using mapoptions until a month ago. Most mappers aren't lua coders. And as I said, default options will leave it as designed. It'll add to the possibilities, not detract.

There are over 1200 map files on springfiles.com, over 90% won't have any map options, do you really suggest we make 1200 mutators just to add control over water levels?

FLOZi wrote:

• So we still need to rerelease maps for 'flooded' or 'wet' versions? What difference does it make if we dry a wet map vs flood a dry map?

To make a wet map dry the mapoptions can simply increase maxHeight by -minHeight and set minHeight to 0.

(Random thought: if minHeight and maxHeight are not specified in the SMD, can Lua actually access them at the time the SMD is being loaded, and mapoptions are being applied? If not, then a dry option is impossible.)

To make a dry map wet at least you need to know how wet it should be. There is no clear way to automatically decide this value, and to make it user settable doesn't make a lot of sense, frankly. (You need testing to find what water height works properly.)

Tobi wrote:

FLOZi wrote:

• So we still need to rerelease maps for 'flooded' or 'wet' versions? What difference does it make if we dry a wet map vs flood a dry map?

To make a wet map dry the mapoptions can simply increase maxHeight by -minHeight and set minHeight to 0.

(Random thought: if minHeight and maxHeight are not specified in the SMD, can Lua actually access them at the time the SMD is being loaded, and mapoptions are being applied? If not, then a dry option is impossible.)

Easy enough to disable the option entirely if the min/maxHeight is not found in SMD (or otherwise accessible).

To make a dry map wet at least you need to know how wet it should be. There is no clear way to automatically decide this value, and to make it user settable doesn't make a lot of sense, frankly. (You need testing to find what water height works properly.)

I disagree, I think making it user settable makes perfect sense. The player knows what water depth is suitable for the game they are playing. The mapper, clearly, can not ever know that, unless they force their map to only play one game.