Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Make Liminal be sensitive to overillumination/overdarkening #6740

Closed
Discontinuum opened this issue Jun 2, 2022 · 13 comments · Fixed by #6749
Closed

[Feature Request]: Make Liminal be sensitive to overillumination/overdarkening #6740

Discontinuum opened this issue Jun 2, 2022 · 13 comments · Fixed by #6749
Labels
Enhancement Issues that are requests for new features or changes to existing ones. Units Issues that involve unit definitions or their implementation in the engine.

Comments

@Discontinuum
Copy link
Contributor

Discontinuum commented Jun 2, 2022

Describe the desired feature

Liminal in 1.16 has +25% when 0 light and 0% otherwise. I think such abrupt behaviour is inconsistent with the logic of other light-sensitive alignments. Even +1% light makes it 0%, it makes this alignment weird-behaving in various scenarios of partial light (like the 24 hour schedule). So my proposal would be to make the formula for liminal be 25%-abs(light). This way it would be the same in terms of 1v1 multiplayer balance (@Hejnewar can confirm, I think), but it will make liminal much more consistent with another light-sensitive alignments

Ofc this is to be done for 1.17 and later 1.18 only, not in 1.16 (becase of backward compatibility)

UPD: I found that liminal is even more tricky, it works like bonus = std::max(0, max_liminal_bonus-std::abs(lawful_bonus)); where max_liminal_bonus is calculated over the whole schedule. Then my proposal would be to remove max(0, to make liminals get pentalties for overillumination/overdarkening. Tbh I don't know whether the current system is good, cause it makes liminal be kinda different on different maps (so on an eternal twilight map a liminal fights without any bonus, on a map with a regular day it fights better during twilight).
And also it's kinda complicated and not elaborated in the help.

So, my proposals:
Either max_liminal_bonus-abs(light)
or just 25-abs(light)

@Discontinuum Discontinuum added the Enhancement Issues that are requests for new features or changes to existing ones. label Jun 2, 2022
@Discontinuum Discontinuum changed the title [Feature Request]: Make Liminal be sensitive to partial illumination/darkening [Feature Request]: Make Liminal be sensitive to overillumination/overdarkening Jun 2, 2022
@Wedge009 Wedge009 added the Units Issues that involve unit definitions or their implementation in the engine. label Jun 2, 2022
@Elvish-Hunter
Copy link
Contributor

Elvish-Hunter commented Jun 3, 2022

The liminal alignment has always been kind of confused in its implementation.
If I remember everything correctly, at first it was defined as if lawful_bonus == 0 then 25 else -abs(lawful_bonus); then it was changed to just be -abs(lawful_bonus) (so always a penalty, in fact); now we have a more complex max(0, max_liminal_bonus - abs(lawful_bonus)) (so always a bonus). And just to complicate things further, I believe that at some point we even supported a liminal_bonus= key inside [time] tags (I'm not sure if it's still working).
Your proposal suggests to make it 25 - abs(lawful_bonus), which would be the fourth different implementation, when the other three alignments have always been the same from the beginning. I'm not complaining against it (it'd be simpler to calculate than the current system, so I'd actually be in favor), however I believe that we should decide once and for all what we expect from the liminal alignment and how we want it to behave.

@Discontinuum
Copy link
Contributor Author

I agree that this should be discussed, especially considering that the current system turned out to be quite sophisticated and not intuitive.

First, what the general idea of the liminal alignment (as I see it). A liminal unit fights best in the neutral ToD and fights worse and worse if more light/more dark. This kind of unit uses shadows and other effects of mixing light and dark to his benefit, but pure light/dark hampers him.

How it is implemented now. The system is quite elaborate, I admit, it was introduced in the commit 4048387
First, the system determines the maximum absolute level of dark/light in the ToD schedule. In the vast majority of cases it's 25% but it doesn't have to be (the most obvious example is Indoors schedule, or any kind of Eternal Twilight). Then this maximum absolute level is called max_minimal_bonus and the actual bonus is determined as max(0, max_liminal_bonus - abs(lawful_bonus))

What is not good in this system? First, it makes the liminal alignment map-dependent (schedule-dependent) and therefore quite hard to grasp. In a scenario with the standard schedule our liminal unit has +25% at dawn/dusk and fights better than our lawful/chaotic guys, then we move indoors and it has 0% and have no advantage, although it's kinda the same light level as it was before, when he had an advantage. Second, it's not only oversophisticated by itself, it makes illumination/darkening work inconsistently with liminals. On the standard map at dawn a liminal has +25% bonus and 0% if illuminated/darkened. But in the map with eternal twilight illumination/darkening has no effect at all on liminals, because of max_liminal_bonus=0 and max(0,. I don't think 0 cap is logical, it's not important in the usual situations (the standard schedule) but takes away ability to use illumination/darkening properly, especially super-illumination (like +30, +40, +50).

I would note separately that the description of all this behaviour is quite sparse and confused. It's not documented in the wiki, a "liminal_bonus" parameter of maps is only briefly mentioned in the Lua page without any explanation. The in-game help confuses the thing even further, it simply states that "liminal: +25% at dawn/dusk, 0% otherwise" (which is not true neither outdoors, nor, let say, in a deep underground).

So, I have two proposals. If we want to keep this logic behind finding max_liminal_bonus (which I believe isn't nice because of its inconsistency effects), then I propose to make formula max_liminal_bonus - abs (lawful_bonus) (so just eliminate max(0, part). More simplistic and logical way, according to me, is just 25 - abs(lawful_bonus). It's consistent with illumination-sensitive alignments logic, it's consistent with liminal behaviour in the standard case now

@CelticMinstrel
Copy link
Member

I think the reasoning behind the current system was that for schedules that have a continuum of lawful bonuses, this system makes liminal roughly inverse to it, sort of like the following chart:

lawful    0      5      10     15     20     25
liminal   25     20     15     10     5      0
chaotic   0     -5     -10    -15    -20    -25

@knyghtmare
Copy link
Member

#2664 (comment)
I suppose this was one?

@CelticMinstrel
Copy link
Member

CelticMinstrel commented Jun 4, 2022

Yeah, that comment explains my rationale.

I think the cases mentioned by @Discontinuum were overlooked though – that is, when you have a schedule that's of a single alignment. There's two cases of this. However, one of these is already handled, and the other is cannot be handled.

Eternal twilight

Here, based on the intended meaning of liminal, they should have a permanent bonus. Unfortunately, there's no way to calculate this, because there's nothing to calculate it from, so I don't think it can be directly implemented into the system. I believe there's an extra key to manually set the max liminal bonus for the schedule though. I suppose we could make the max liminal bonus default to 25 if the calculation yields 0, though… but we'd need to distinguish that from explicitly setting it to 0.

Eternal daylight (or night)

Here, liminal should always be at a disadvantage, which means they never get a bonus nor a penalty and are effectively equivalent to neutral units.

@CelticMinstrel
Copy link
Member

CelticMinstrel commented Jun 4, 2022

Okay, so if I understand correctly, one of the primary complaints here is that the formula renders liminals immune to illumination-type abilities in some cases.

So consider this schedule:

Time -5 -4 -3 -2 -1 0 1 2 3 4 5
Chaotic 25 20 15 10 5 0 -5 -10 -15 -20 -25
Lawful -25 -20 -15 -10 -5 0 5 10 15 20 25
Liminal 0 5 10 15 20 25 20 15 10 5 0

If my math is correct, applying illumination (+25% capped to 25%) gives this:

Time -5 -4 -3 -2 -1 0 1 2 3 4 5
Chaotic 0 -5 -10 -15 -20 -25 -25 -25 -25 -25 -25
Lawful 0 5 10 15 20 25 25 25 25 25 25
Liminal (current) 25 20 15 10 5 0 0 0 0 0 0
Liminal (proposed) 25 20 15 10 5 0 -5 -10 -15 -20 -25

And applying darkening (-25% capped to -25%) gives this:

Time -5 -4 -3 -2 -1 0 1 2 3 4 5
Chaotic 25 25 25 25 25 25 20 15 10 5 0
Lawful -25 -25 -25 -25 -25 -25 -20 -15 -10 -5 0
Liminal (current) 0 0 0 0 0 0 5 10 15 20 25
Liminal (proposed) -25 -20 -15 -10 -5 0 5 10 15 20 25

Then the other complaint is that liminal stops functioning in an eternal twilight schedule. I think the easiest way to handle this would be, as mentioned earlier, for the calculated max liminal bonus to be no less than 25.

(You also mentioned the underground and indoors schedules, but I think it should work as expected there? Or was it that liminal functions but interacts differently with illumination/darkening?)

@Discontinuum
Copy link
Contributor Author

If my math is correct, applying illumination (+25% capped to 25%) gives this:
Time -5 -4 -3 -2 -1 0 1 2 3 4 5
Chaotic 0 -5 -10 -15 -20 -25 -25 -25 -25 -25 -25
Lawful 0 5 10 15 20 25 25 25 25 25 25
Liminal (current) 25 20 15 10 5 0 0 0 0 0 0
Liminal (proposed) 25 20 15 10 5 0 -5 -10 -15 -20 -25

Incorrect. I talk about uncapped illumination/darkening, that goes over 25, not the capped one. So the table with my case looks like this (for illumination)

Time -5 -4 -3 -2 -1 0 1 2 3 4 5
Chaotic 0 -5 -10 -15 -20 -25 -30 -35 -40 -45 -50
Lawful 0 5 10 15 20 25 30 35 40 45 50
Liminal (current) 25 20 15 10 5 0 0 0 0 0 0
Liminal (proposed) 25 20 15 10 5 0 -5 -10 -15 -20 -25

@CelticMinstrel
Copy link
Member

So when it's capped, the current liminal is correct in your mind?

@Discontinuum
Copy link
Contributor Author

Discontinuum commented Jun 4, 2022

So when it's capped, the current liminal is correct in your mind?

Yes. For the standard schedule, if illumination/darkening abilities are capped so light is always in range -25%..25%, the current system works fine. My concerns are the cases when the light level can go beyond the -25..25 range and non-standard schedules.

A brief summary: the current formula max(0, max_liminal_bonus - abs(lawful_bonus)). My basic proposal is to make it max_liminal_bonus - abs(lawful_bonus) so a liminal unit gets penalties in the case of extreme light/dark (as the deep underground -30%, lava during the day +35% or UMC uncapped illumination/darkening abilities). The extended proposal is to make it 25 - abs(lawful_bonus), so instead of using the schedule to calculate max_liminal_bonus, use always 25 by default.

@CelticMinstrel
Copy link
Member

And that proposal doesn't change anything for typical schedules, so it seems reasonable. My proposal then is to change the formula to max_liminal_bonus - abs(lawful_bonus) and also alter the calculation of max_liminal_bonus to clamp it to a minimum of 25.

@newfrenchy83
Copy link
Contributor

newfrenchy83 commented Jun 5, 2022

And that proposal doesn't change anything for typical schedules, so it seems reasonable. My proposal then is to change the formula to max_liminal_bonus - abs(lawful_bonus) and also alter the calculation of max_liminal_bonus to clamp it to a minimum of 25.

I will pull a PR based on your proposition, but let me know one thing, the clamp to a minimum of 25 must be applied in case here liminal bonus specified in scenario or only on liminal_bonus calculation based in Tod only?

@CelticMinstrel
Copy link
Member

The minimum is only for the automatic calculation. If someone explicitly sets max liminal bonus to 15, we should honour that choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Issues that are requests for new features or changes to existing ones. Units Issues that involve unit definitions or their implementation in the engine.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants
@CelticMinstrel @Elvish-Hunter @knyghtmare @Wedge009 @newfrenchy83 @Discontinuum and others