repeatably disappearing ship in [5971]

Describe your experience with the latest version of FreeOrion to help us improve it.

Moderator: Oberlus

Forum rules
Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Post Reply
Message
Author
User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

repeatably disappearing ship in [5971]

#1 Post by Dilvish »

This seems like the same thing that Big'Oh (sp?) ran into a little while back, but I don't think anyone had it repeatable before this; the saved game will be attached to the following post ) since I have 3 screenshots attached here).

Start by clicking the fleets at Pyrrus, and selecting the bottom fleet, of two scouts:
Screen1.png
Screen1.png (49.62 KiB) Viewed 690 times

Drag the bottom scout (Veiovis) to the new fleet bar, and go ahead and select the new fleet to verify you see Veiovis there (though this is not necessary to replicate the disappearance):
Screen2.png
Screen2.png (49.87 KiB) Viewed 690 times
Now open up the Production window (should come up centered on Pyrrus) and add a Mark I to the queue. Close the Production window, click on the original scout fleet (264, with Zephyrus), then click back to the fleet with Veiovis, and Veiovis has disappeared. (it reappears next turn)
Screen3.png
Screen3.png (42.69 KiB) Viewed 690 times
I tried running with a profiler/memory-checker, and this does not appear to be associated with read/writes of unallocated/freed memory (though it seems likely there is some kind of bad memory access going on). I didn't see anything pertinent in the log files.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: repeatably disappearing ship in [5971]

#2 Post by Dilvish »

here is a saved game file...

**edit** I'm posting this in case anyone else wants to look at it; I don't have time to do make any more debugging attempts with it just now, but I plan to look at it more over the weekend if not sooner.
Attachments
DisappearingShip.sav.zip
(45.03 KiB) Downloaded 60 times
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: repeatably disappearing ship in [5971]

#3 Post by Dilvish »

OK, I got this figured out and fixed. When new objects are created, the client normally gets an ID through a special network message with the Server, so that is in charge of ensuring no conflicts between object IDs. Probably because of that reliance on the server, Universe::InsertID wasn't bothering to check if it needed to update m_last_allocated_object_id. Because the client would (as of recently) sometimes get "temporary" object IDs directly based off m_last_allocated_object_id ( for calculating Effects for pedia displays on ships, etc), this was leading to conflicts in which the client would overwrite its local copy of a permanent object (which would then reappear next turn with the Server update).
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: repeatably disappearing ship in [5971]

#4 Post by Geoff the Medio »

Sounds to me like a better / additional fix would be to change how temporary-object ids are selected...

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: repeatably disappearing ship in [5971]

#5 Post by Dilvish »

Geoff the Medio wrote:Sounds to me like a better / additional fix would be to change how temporary-object ids are selected...
Well, regardless of what might also be done for the temporary IDs, it seems to me this change is appropriate in its own right -- it seems a bit inherently buggy to let the client ignore updating m_last_allocated_object_id when it gets an ID from the Server.

As far as changes to how the temporary IDs are obtained, one alternative that comes to mind, at least for the current use, would be always select the temporary ID as MAX_ID, since the object gets deleted immediately & doesn't get referred back to. (Though if we went that route then for safety we should probably adjust a little more code so that MAX_ID is normally reserved, even if it is not expected that normal object usage would ever get to an ID that high). Other than that I don't see much alternative to the current approach.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: repeatably disappearing ship in [5971]

#6 Post by Geoff the Medio »

Dilvish wrote:...it seems a bit inherently buggy to let the client ignore updating m_last_allocated_object_id when it gets an ID from the Server.
Setting the last allocated id whenever an ID is received from the server doesn't handle all possible cases either, as there could be other clients getting IDs after, about which other clients won't have any knowledge. So the last allocated id is only current / accurate on the last client to receive such an update.
...always select the temporary ID as MAX_ID...
That, or some other constant special-use ID for temporary objects would be fine, as long as there's only ever need for one temporary object at a time. Alternatively, negative (more negative than -1, which is also a special case ID) could be used for multiple temporaries. I'm not sure whether there's any need for multiple temporaries, though.

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: repeatably disappearing ship in [5971]

#7 Post by Bigjoe5 »

Geoff the Medio wrote:
Dilvish wrote:...it seems a bit inherently buggy to let the client ignore updating m_last_allocated_object_id when it gets an ID from the Server.
Setting the last allocated id whenever an ID is received from the server doesn't handle all possible cases either, as there could be other clients getting IDs after, about which other clients won't have any knowledge. So the last allocated id is only current / accurate on the last client to receive such an update.
Which shouldn't affect this case at all, though, and in theory would never cause problems because "real" objects are only ever created on the server.

That said though, the Universe has a function called InsertID, which allows the ID to be specified when inserting an object. For now, I can change the problem code to call that function with -2 or something, but a more robust solution that handles multiple temporary objects is probably more appropriate. Since the immediate problem is gone, I'll probably just implement the second solution.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: repeatably disappearing ship in [5971]

#8 Post by Geoff the Medio »

Bigjoe5 wrote:...I can change the problem code to call that function with -2 or something...
I suggest adding another global, similar to INVALID_OBJECT_ID = -1, perhaps TEMPORARY_OBJECT_ID = -2, for that purpose.

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: repeatably disappearing ship in [5971]

#9 Post by Bigjoe5 »

Geoff the Medio wrote:
Bigjoe5 wrote:...I can change the problem code to call that function with -2 or something...
I suggest adding another global, similar to INVALID_OBJECT_ID = -1, perhaps TEMPORARY_OBJECT_ID = -2, for that purpose.
Yeah, I was going to suggest something like that, but that's not very robust to the possibility of multiple temporary objects being created at one time. I'm starting the think that having a function that will return a unique ID for an arbitrary number of temporaries would be more work that I want to do for such a small not-even-feature, though, so I'll probably just default to TEMPORARY_OBJECT_ID for now.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: repeatably disappearing ship in [5971]

#10 Post by Geoff the Medio »

Bigjoe5 wrote:...not very robust to the possibility of multiple temporary objects being created at one time.
If need for multiple temporaries arises, the means for getting IDs for them can be changed. For now, if only one temporary ID is needed, a fixed value for it should suffice.

Post Reply