Counter for 50% of the land in territorial lord doesn't reset

Bug #858517 reported by Hans Joachim Desserud on 2011-09-24
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Undecided
Unassigned

Bug Description

I played a game with win condition territorial lord with another player.
* I had 50% of the map, so I got the message I needed to hold it for 20 min in order to win.
* After a while I got another message saying I needed to hold it for 15 more min.
* At this point the other player managed to conquer some of my land, and I must have dropped down below 50% again.
* After a pretty tight battle over the border I was finally able to push the other player back again and start reclaiming some of my lost land.
* Even though I reconquered what I had lost and into previously enemy territory I did not receive any additional messages, and while we agreed I had won, the game did not seem to be aware of this.

It seems the counter did not reset when I dropped below 50% again. So if a player loses the majority of the map, even if that player is able to regain it the game will not notice it. The win condition should be able to handle that players in the lead are knocked down, but may make a comeback later.

Widelands build 16 (though I don't think this has been changed since release)

Steven De Herdt (stdh) wrote :

Hello Widelands!

While playing against the AI I experienced this as well. Now I took a look at it, and apparently the player number isn't properly reset when you drop below 50%, leaving you with a bogus remaining_time when you exceed the threshold again. I think you can solve this by letting one of your enemies get over half the land, then reclaim and hold 50% yourself. Or you can apply the attached patch, but note that I haven't tested either one.

I have to say that I find the code a bit untidy, but that may be because I'm new to Lua. For example, most calculations are done once for individual players, and once for teams - not quite concise. But that's more a matter of style.

As a matter of function, I'd like to mention that:
*The code assumes a constant land mass. Don't know if that could be a problem outside of the Atlantean campaign.
*In a corner case, it's -probably- possible to fall below the 50% threshold and exceed it again in one sample period. Gotta be fast though.
*Like in Autocrat, if you've (almost) won, the game can take some time before it sends you that message.

These problems could be solved by using hooks. Would that be worth it?

Last question: is the amount of conquered land indicated in the graph the same as that calculated in this script? If not this may lead to frustrated player strategies...

Steven De Herdt (stdh) wrote :

Oh yes, another question: is it possible to debug the win condition in Lua? I can't seem to reach the appropriate variables in the console.

SirVer (sirver) wrote :

> I have to say that I find the code a bit untidy, but that may be because I'm new to Lua. For example, most calculations are done once for individual players, and once for teams - not quite concise. But that's more a matter of style.
it is - please feel free to clean it up - maybe you can come up with an iterator like approach that can make the distinction between team and player go away. Patches are very, very welcome.

> *The code assumes a constant land mass. Don't know if that could be a problem outside of the Atlantean campaign.
Only the atlantean campaign changes the land mass for now - i think it is safe to assume this inside a regular game.

> *In a corner case, it's -probably- possible to fall below the 50% threshold and exceed it again in one sample period. Gotta be fast though.
Then the win condition is slightly incorrect - seems not to matter to me that match. It would not be game breaking, would it?

> *Like in Autocrat, if you've (almost) won, the game can take some time before it sends you that message.
Could you elaborate what you mean here - I do not get it.

> These problems could be solved by using hooks. Would that be worth it?
Yes - hooks would be the correct approach but require coding and documenting them. If you would want to work on this it would be awesome. I can help you out with information wherever needed.

> Last question: is the amount of conquered land indicated in the graph the same as that calculated in this script? If not this may lead to frustrated player strategies...
I am not sure what you mean - the leftmost statistics button (land conquered) is calculated in c++, but the one this script uses is calculated in Lua. So even when they started out to be the same, they might have diverged. Of course using the one from inside the c++ code would be better - but it is also more coding work to be done. Again, feel free to fix this :)

> Oh yes, another question: is it possible to debug the win condition in Lua? I can't seem to reach the appropriate variables in the console.
yes, there is only one lua namespace in which everything is running - so you should be able to access anything that is not created with the local keyword in Lua. Note that when you use print() in the console, the output will go to the terminal and not appear in the console. So maybe this is the problem?

Changed in widelands:
status: New → Confirmed
SirVer (sirver) wrote :

Oh, I forgot to mention: I applied your patch in r6577 and added you to the list of contributors. Thanks for your work.

Changed in widelands:
status: Confirmed → Fix Committed
milestone: none → build18-rc1
Steven De Herdt (stdh) wrote :

First, I should mention that it's indeed possible to properly reset the counter by letting an enemy control >50% of the land. Not exceedingly useful information, but still.

>Abstraction over team <-> player; hooks
I'd like to try this, but it will probably take me some time. The hooks I wanna look at too, later though.

>Corner case
Not that important, I agree.

>Delay in sending victory condition status.
Both in Autocrat and Territorial Lord, the game checks victory conditions in timed intervals, which means it can take up to the sampling time before it realizes something has changed. When a player destroyed their enemy's last building (Autocrat), respectively took control of the tower that made their land-ownage exceed 50% (TLord), it can take a few seconds (up to 30 with TLord) before they receive a message notifying them of this fact. This makes the game look slow, a nasty player might even say retarded!

>Amount of land conquered,C++ (graph) <-> Lua (win cond.)
This is certainly different as I noticed. The win condition only counts walkable (or with immovable) fields. Quite apart from the question that the graph and win condition should agree over the amount of land conquered, would it be desirable for the graph not to count water/dead fields, in general?

>Debugging Lua
The win conditions' variables and functions are indeed 'local', that was the problem. Do you happen to have some pointers to good info about debugging embedded Lua? (I should read the tutorial on that first.) Also, Widelands' debug window is a bit inflexible, but at least it exists!

>Added to the list of contributors
Nice, thanks. I understand you would not object to more patches in order to justify this... ;)

New bug: apparently, this win condition does not survive a save-load cycle. Nothing happens when I conquer over 50% after loading. Is the Lua code responsible? Does this need a new bug assigned?

SirVer (sirver) wrote :

> I'd like to try this, but it will probably take me some time. The hooks I wanna look at too, later though.
Whenever you find time is fine :)

>>Delay in sending victory condition status.
>Both in Autocrat and Territorial Lord, the game checks victory conditions in timed intervals, which means it can take up to the sampling time before it realizes something has changed. When a player destroyed their enemy's last building (Autocrat), respectively took control of the tower that made their land-ownage exceed 50% (TLord), it can take a few seconds (up to 30 with TLord) before they receive a message notifying them of this fact. This makes the game look slow, a nasty player might even say retarded!
The only way to fix this would be to check the victory conditions in the
game engine (c++) and make it accessible to Lua. Or to check it more
often. As most players play at times 2 or even 3, the delay translates
to 10 secs max in real time. Quite acceptable to me - but we could also
check more often - we can spare the cyles.

>>Amount of land conquered,C++ (graph) <-> Lua (win cond.)
>This is certainly different as I noticed. The win condition only counts walkable (or with immovable) fields. Quite apart from the question that the graph and win condition should agree over the amount of land conquered, would it be desirable for the graph not to count water/dead fields, in general?
I would agree to this - usable land is a much more useful statistic than
owned land. Feel free to take a stab at this (and fix the Lua code to
use this statistic then).

>>Debugging Lua
>The win conditions' variables and functions are indeed 'local', that was the problem.
Well, they should be I guess - after all they contain some state that is
private to the win conditions. But making them global for debugging
seems to be the way to go :)

>Do you happen to have some pointers to good info about debugging embedded Lua?
No, sorry. It is mostly learning by doing.

> Widelands' debug window is a bit inflexible, but at least it exists!
Yes, there is much to make it more useful, but it is already useful as
is :)

>>Added to the list of contributors
>Nice, thanks. I understand you would not object to more patches in order to justify this... ;)
You already earned this spot by contributing code - more is always
welcome of course.

> New bug: apparently, this win condition does not survive a save-load cycle. Nothing happens when I conquer over 50% after loading. Is the Lua code responsible? Does this need a new bug assigned?
That is really odd - I did load and continue to play win condition
games. I think this deserves a new bug report - even better if you can
find a small repro case with a simpler win condition.

SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers