To be honest, I don't know. It was there before, so I kept it. I wasn't sure why it was there, but it looked like the previous value was the same as the new one, and so the "- 1" should be preserved. Feel free to fix this if it's incorrect.Geoff the Medio wrote:In Universe::JumpDistance why is 1 subtracted from the number looked up in m_system_jumps? With it there, I get natives in the wrong places, and few elsewhere, and without it, things look correct...Geoff the Medio wrote:I think there might be a problem with the present WithinhStarlaneJumps code.
[PATCH] WithinStarlaneJumps implementation
Moderator: Committer
Re: [PATCH] WithinStarlaneJumps implementation
Re: [PATCH] WithinStarlaneJumps implementation
From Universe::WithinJumpsImpl, rev. 4280:
I don't know what johnson_shortest_paths returns for inaccessible nodes, I suppose some very high value, which should be ok as well for now. However, if a path was found, it returns the edge weight sum along the path, which in our case equals the number of edges on the path. This is the correct distance and so I think we can safely remove the "-1" from JumpDistance().
update: additionally, the same computation has been performed in JumpsBetweenObjects(). Thus, the -1 has to be removed there as well!
The original distance returned was the number of vertices on the path, minus one, which equals the number of edges on the path. If no path was found at all, -1 was returned.retval.second = retval.first.size() - 1; // number of jumps is number of systems in path minus one for the starting system
I don't know what johnson_shortest_paths returns for inaccessible nodes, I suppose some very high value, which should be ok as well for now. However, if a path was found, it returns the edge weight sum along the path, which in our case equals the number of edges on the path. This is the correct distance and so I think we can safely remove the "-1" from JumpDistance().
update: additionally, the same computation has been performed in JumpsBetweenObjects(). Thus, the -1 has to be removed there as well!
Yesterday, we were still on the brink. Fortunately, today we have come one step further.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: [PATCH] WithinStarlaneJumps implementation
Someone posted a bug report including a save file that I can't open the the latest SVN build with Boost 1.47 on Windows. So, I searched a bit more, and according to the boost 1.47 documentation, the issues with binary archive portability are presently related to floating point types. Are you sure portable binary serialization of FreeOrion saves should be working? It doesn't seem very reliable...tzlaine wrote:I wouldn't worry too much about this. For platforms with the same type-sizes (sizeof(some_type) is the same for both) and the same endiannesses, the save files should be portable. And they should even be portable across 32- vs. 64-bit systems, as long as we don't try to serialize longs.After a bit of googling, it appears that boost::serialization binary archives aren't portable between OSes. I switched to binary serialization a while ago to reduce the file sizes, but apparently that has broken cross-platform serialization...
I assume you both were running on Linux, though... I don't know if the portability issue would arise between different distros, although it seems plausible.
Re: [PATCH] WithinStarlaneJumps implementation
No, I'm not. Though why binary floating point representations should differ among the three platforms we support is a mystery to me. It may be a 64- vs. 32-bit build issue.Geoff the Medio wrote:Someone posted a bug report including a save file that I can't open the the latest SVN build with Boost 1.47 on Windows. So, I searched a bit more, and according to the boost 1.47 documentation, the issues with binary archive portability are presently related to floating point types. Are you sure portable binary serialization of FreeOrion saves should be working? It doesn't seem very reliable...tzlaine wrote:I wouldn't worry too much about this. For platforms with the same type-sizes (sizeof(some_type) is the same for both) and the same endiannesses, the save files should be portable. And they should even be portable across 32- vs. 64-bit systems, as long as we don't try to serialize longs.After a bit of googling, it appears that boost::serialization binary archives aren't portable between OSes. I switched to binary serialization a while ago to reduce the file sizes, but apparently that has broken cross-platform serialization...
I assume you both were running on Linux, though... I don't know if the portability issue would arise between different distros, although it seems plausible.