Some zone rendering tweaks ...

[voodoo]

I'm often annoy while playing sumo as superposed zones hide my screen. On the other hand, I'm not fond of alpha disabled lines rendering neither. To fix this issue, I've added a setting, zone_floor_scale_pct, to render zones on the floor instead of as vertical walls. Using zones height and this additional setting, I was able to get this:

So the issue was fixed but the rendering was a bit squared. When it's about vertical rendering, the square effect is not a issue but on the floor, I saw it a bit ackward. Anyway, another setting, zone_seg_steps, makes it smoother:

Last issue, that was fine for sumo but floor rendering makes it hard to see zones far away like in wild fortress...
zone_proximity_distance and zone_proximity_offset allow to use zone_height>0 and have to smoothly hidden while coming close to a zone.

As all other settings in zonev2, default values are used if nothing is specified but each zone can have different values. So I've also add support for these settings (plus already existing settings as height, bottom, segments, segment_length, in zone parsing code.

zone_floor_scale_pct set inner zone radius on the floor. It should be between 0 and 1. Default is 1.0 which means no floor rendering.
zone_seg_steps set number of steps to render each segment. Default is 1.
zone_proximity_distance is the distance from which zone height start to shrink. Default is -1 which means this feature is disabled (zone_height is used).
zone_proximity_offset is the distance at which zone height reach 0.
If zone_proximity_offset<zone_proximity_distance, zone height shrinks from zone_height to 0 as cycle comes closer to the zone.
If zone_proximity_offset>zone_proximity_distance, zone height grows from 0 to zone_height as cycle comes closer to the zone.

Here's the branch.

[Phytotron]

Nice. But could you (or someone) combine those into one or at least fewer settings? There's so much settings bloat in this game.

[sinewav]

You know, I was kind of thinking the same thing. What would be good is maybe a menu entry for "zone style" (flat|raised) and maybe a depth/height value and a length value. I think a lot of combinations can be covered with just that.

That said, I think the new code is really cool. I've often wished for a setting like that, but never voiced it.

[Lucifer]

Nah, keep the settings, but make like 6 files meant to be INCLUDEd that have preconfigured zones that will hopefully satisfy 95% of the players so the only ones who have to tweak these settings are just a few that really need them.

I didn't look closely at your post, but there is a patch included, right?

[Word]

That's just what I needed, thanks voodoo!

[voodoo]

Nice. But could you (or someone) combine those into one or at least fewer settings? There's so much settings bloat in this game.

Well I can merge 2 of these 4 settings, zone_proximity_distance and zone_proximity_offset into a zone_proximity_range one. There's two way to do that:
The first one is to use a configuration function instead of a setting but you lose the ability to get current value with tab.
The second one can be to extend conf settings to support tuple. I've tested it and it works fine with boost::tuple, including completion.

Nah, keep the settings, but make like 6 files meant to be INCLUDEd that have preconfigured zones that will hopefully satisfy 95% of the players so the only ones who have to tweak these settings are just a few that really need them.

I didn't look closely at your post, but there is a patch included, right?

Sorry, I don't understand the 6 files thing The source is in bazaar, I've fixed the link in first post.

edit: er, I understand it now... I was under influence or something
About tuples, using boost conveniently allow to use iostream. default delimiters and separator are parenthesis and space which means a range must be entered that way: zone_proximity_range (40 20)

[Z-Man]

Well I can merge 2 of these 4 settings, zone_proximity_distance and zone_proximity_offset into a zone_proximity_range one.

Noooonononono. That doesn't make things easier at all and may create trouble later on when we tackle a better setting system.

I'd say: ignore Phytotron on this, what he really wants is not possible right now, at least not in a reasonably convenient way. I guess what he wants is a single MENU ITEM where you can select zone rendering modes: Vertical, Flat (plus some more), Custom. And Custom would ideally pop out more menu items where you can tweak the individual settings. We do want the full flexibility for map creators and tweakers and there is no way around having all the different settings for that.

[voodoo]

Yeah, I was expecting this kind of answer actually This point worth be taken into account globally, with scripting probably.
Anyway, I'll look for include files/menu options things.

[voodoo]

I've added 3 configurations files for vertical/flat/combined zone rendering settings.
I've also added a menu entry into system menu/display settings/details:

It's a selection item slightly modified to allow an additional custom item acting as a submenu. I'm not sure if there was any way to do it without modifying uMenuItemSelection, so if it's not the right way, I'd need to fix it.
So the selection have the same 3 entries as included config file (I'm actually calling them, hardcoded, sorry), plus the additional custom entry. Pressing enter on it enter following submenu:

Checking for include files and building selection on the fly might be more flexible but hardcoded selection was easier. Is it fine ?
Also, as my english is far to be perfect, feel free to change labels and help texts.

[Z-Man]

That looks mighty fine. I'll have a look at the code later, but hardcoded config file paths are definitely fine. That's what we're doing for the default keyboard settings, too.

[Phytotron]

I'd say: ignore Phytotron on this, what he really wants is not possible right now, at least not in a reasonably convenient way.

Didn't he just do it?


I would just question why you need all those settings in the second menu. I know you all are all into customization and tweaking of every little detail, but I think sometimes you gotta just make a decision. "This is how it is." Overwhelming (and often vague) choices and bloat aren't exactly appealing or useful design.

[voodoo]

Oh. Sorry if you think I've ignored you. I've not. Actually, I took time to see if your suggestion (which I fully understand) was feasible within the scope of this branch, but the only reasonable thing I could do was to merge 2 of these 4 settings, as I explain above. Trying to merge the 4 settings into one would have make no sense as there's still at least 4 related settings that can't be merged without breaking backward compatibility. Any other solution requires a global refactoring which is not requiring the same amount of effort and time. However, the tuple support that I've described above is still included as it does not harm and bring convenient flexibility if it is ever required.

About the detail submenu content, based on all the response I had, I just thought it could worth the little extra effort to include existing related settings into it. About how obscure or vague are these settings, I'm fully open to any suggestion to adjust the logic behind them and of course to correct descriptions that are probably as poor and uninspired as my english skills are.
The new menu selection and related detail submenu can be easily disabled if they make no sense or do not fit in the game. In both case, it's just about commenting out 1 line in the code.

I was just sharing something I was testing to improve my own sumo experience. Never meant to offense anyone.

[Z-Man]

I'd say: ignore Phytotron on this, what he really wants is not possible right now, at least not in a reasonably convenient way.

Didn't he just do it?

Yes and no; he ignored what you said (get rid of config variables, which is horrible and does not make sense) and instead did what you really wanted (I guess).

[Jip]

Very nice!
Is it going to be merged in mainline?

[Phytotron]

what you said (get rid of config variables....

Not actually what I said, but that's cool.