Opened 6 years ago
Closed 6 years ago
#5065 closed defect (fixed)
Weird (gaia) dock placement in random hellas
| Reported by: | mimo | Owned by: | elexis |
|---|---|---|---|
| Priority: | Should Have | Milestone: | Alpha 23 |
| Component: | Maps | Keywords: | |
| Cc: | Patch: |
Description
Use the attached replay, on r21431 and the faulty dock is just on the right of the player 1 base.
BTW what is the reason to have everything locked in replay? in such a situation, it would be interesting to try to rebuild a dock at the same position to check if it a licit one, but that's impossible. Also, quite often while debugging the AI, i'd like to modify manually some AI behavior to see how it would react, but all these basic needs are now forbidden (while it was possible in the past). There should be either a new checkbox in the developper overlay to be allowed to alter a replay, or these shitty (and useless) locks should be removed.
Attachments (2)
Change History (11)
by , 6 years ago
| Attachment: | commands.txt added |
|---|
comment:1 by , 6 years ago
| Component: | UI & Simulation → Maps |
|---|
by , 6 years ago
comment:2 by , 6 years ago
Wouldn't checking that the front side of the dock is in water enough to prevent such cases?
For the replay, sure but who cares if a replay is OOS? but ok, the alternative method you propose seems to allow me doing what i need. Thanks.
follow-up: 4 comment:3 by , 6 years ago
Wouldn't checking that the front side of the dock is in water enough to prevent such cases?
Kind of but also meh. Ideally a dock should only placed where a ship can be spawned and move. It's a solvable problem though :-)
For the replay, sure but who cares if a replay is OOS?
The ones watching the replay. By definition a replay should show the same thing that happened in the original game (which is why I was wondering if we should hash SP games too, #4202).
OOS not only means a hash mismatch but in the most likely case that entity IDs are off. So the commands saved in the replay (or sent via network for MP games) either don't go to any entity or to the wrong entities. In the average case it means all units of all enemies are idle.
comment:4 by , 6 years ago
Replying to elexis:
For the replay, sure but who cares if a replay is OOS?
The ones watching the replay.
And you think that players are not smart enough to understand that if they change something in a replay, they won't see the same thing?
By definition a replay should show the same thing that happened in the original game (which is why I was wondering if we should hash SP games too, #4202).
That's your definition of the replay, and is quite a restrictive one. For me, the replay have several roles: watching a game of course, but also more importantly in the phase we are, helping to understand bugs or wrong ai behaviour. And none of your following concerns apply when it is a full AI replay.
OOS not only means a hash mismatch but in the most likely case that entity IDs are off. So the commands saved in the replay (or sent via network for MP games) either don't go to any entity or to the wrong entities. In the average case it means all units of all enemies are idle.
follow-up: 7 comment:5 by , 6 years ago
And you think that players are not smart enough to understand that if they change something in a replay, they won't see the same thing?
Yes. And then they report it as a bug. Happened already (in a18 when I distributed the replay patch with observermode using the change-perspective feature.)
And none of your following concerns apply when it is a full AI replay.
In that case it's not a replay but a new game.
comment:7 by , 6 years ago
Replying to elexis:
And you think that players are not smart enough to understand that if they change something in a replay, they won't see the same thing?
Yes. And then they report it as a bug. Happened already (in a18 when I distributed the replay patch with observermode using the change-perspective feature.)
And thus, the solution was to make live of developpers more complicated.
And none of your following concerns apply when it is a full AI replay.
In that case it's not a replay but a new game.
And then? looks like a simple-minded answer which does not go beyong the basic meaning of words. Call it as you want: it is a replay file that you run as a replay file.
(in which case there is the save and load feature)
(in which case there is the save and load feature)
Once again a simple-minded remark. How can you save on a full AI game that you let run during one hour or more, and then want to replay if there was an error or because you notice afterwards that at a certain moment, the ai did something wrong
I'm afraid I know this problem already and haven't found a universal solution.
On previous maps where docks are placed, i.e. Migration, Islands, the RMS knows in advance at which locations it can find water and land.
But on Pompeii and Hellas water could be anywhere and the water can have any size, even only tile.
That's what has happened in that replay too - there is water, just less than the dock size.
On these maps with unknown terrain, the script picks a random point on land, then looks for the closest point on the shoreline, places the dock at that point with the angle parallel to the line of these two points. (This unfortunately also implies that these tiny lakes on land are prioritized)
A flood-filling algorithm would help to detect the size of the body of water (and could be reused in other use-cases).
But the dock case can probably be cought by counting the number of clWater tiles in a circle around that dock candidate position.
It instantly breaking (OOS) the replay - incase of non-hased SP replays even without warning. To do it nontheless for debugging purposes, one can use the change-perspective and control-all-units developer overlay feature.