[PATCH] WithinStarlaneJumps implementation

tzlaine · **Joined:** Thu Jun 26, 2003 1:33 pm **Posts:** 1092

Geoff the Medio wrote:

I think there might be a problem with the present WithinhStarlaneJumps code.

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...

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.

cami · **Joined:** Tue Sep 20, 2011 10:32 pm **Posts:** 49

From Universe::WithinJumpsImpl, rev. 4280:

Quote:

retval.second = retval.first.size() - 1; // number of jumps is number of systems in path minus one for the starting system

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.

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!

Geoff the Medio · **Posted:** Sat Oct 15, 2011 6:11 pm

tzlaine wrote:

Quote:

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.

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.

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 · **Joined:** Thu Jun 26, 2003 1:33 pm **Posts:** 1092

Geoff the Medio wrote:

tzlaine wrote:

Quote:

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.

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.

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...

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.

FreeOrion

[PATCH] WithinStarlaneJumps implementation

Who is online