Natives Ate My Homeworld!

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

Natives Ate My Homeworld!

#1 Post by Dilvish »

In a game a little while ago my starting system had a native planet in it, with a High Tech Natives special no less, which seemed pretty strange but I didn't really stop to think it through, I just started a different game.
But now this!
natives_ate_my_homeworld.png
natives_ate_my_homeworld.png (531.22 KiB) Viewed 738 times
Apparently the natives got placed over the top of my empire's homeworld-- the planet is listed as the Homeworld both for Humans and for Silexians. I tested with a plain vanilla build and got the same result.

Galaxy Setup:
Seed: sRsqcj44
Systems: 600
Irregular2
Low Planets, Low Monsters, rest Medium
15 Maniacal AI
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

Re: Natives Ate My Homeworld!

#2 Post by Morlic »

Gleaming gardener robots, left on their own
I always knew you couldn't trust those roboters who were "left" by their creators...
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Chriss
Dyson Forest
Posts: 231
Joined: Sun May 11, 2008 10:50 am

Re: Natives Ate My Homeworld!

#3 Post by Chriss »

Not with 7988 as Cray... recompile is in the works
Attached patches are released under GPL 2.0 or later.

Chriss
Dyson Forest
Posts: 231
Joined: Sun May 11, 2008 10:50 am

Re: Natives Ate My Homeworld!

#4 Post by Chriss »

Yeah, got the same issue. Natives are definitely placed there as confirmed by the logs. I'll debug this a bit, it should not happen from my first glance at the code.
Attached patches are released under GPL 2.0 or later.

Chriss
Dyson Forest
Posts: 231
Joined: Sun May 11, 2008 10:50 am

Re: Natives Ate My Homeworld!

#5 Post by Chriss »

It's an issue in universe_generator.py in create_universe. The code which assigns the home system to each empire uses home_systems.pop() so afterwards, home_systems is empty when it is passed to generate_natives. This then causes the condition jump_distance > 1 between native systems and empire home systems to be useless, as there are no empire home systems.

The patch adds a call to compile_home_system_list to the call of generate_natives, so that it gets the correct list. However, I'd suggest that someone with more python knowledge than me to change the code which uses pop(). I guess it should use a local variable or somesuch and clean that up afterwards so it is not used afterwards. I'm not sure on the python way for such things. Care to enlighten me? ;)

So, the gardener revolution is squashed. May they care to their own gardens from now on. ;)
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Attached patches are released under GPL 2.0 or later.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Natives Ate My Homeworld!

#6 Post by Vezzra »

Chriss wrote:It's an issue in universe_generator.py in create_universe. The code which assigns the home system to each empire uses home_systems.pop() so afterwards, home_systems is empty when it is passed to generate_natives. This then causes the condition jump_distance > 1 between native systems and empire home systems to be useless, as there are no empire home systems.
Oh crap, that screw up is mine. :oops: When I refactored/restructured the server-side Python interface, I had to change these lines and forgot that the list is needed afterwards. Doh!

Fixed.
The patch adds a call to compile_home_system_list to the call of generate_natives, so that it gets the correct list.
Erm, no, that won't work. Two consecutive calls to compile_home_systems won't give you the same list (unless you make sure to initialize the RNG with the same seed before making the calls), besides the call to this function being an expensive one (the function's method of determining the home system list isn't exactly fast and efficient).
However, I'd suggest that someone with more python knowledge than me to change the code which uses pop(). I guess it should use a local variable or somesuch and clean that up afterwards so it is not used afterwards. I'm not sure on the python way for such things. Care to enlighten me? ;)
Using "zip" like it's been done before I decided to mess things up, as I should have right away. ;) So, instead of doing:

Code: Select all

    for empire, psd in psd_map.iteritems():
        home_system = home_systems.pop()
        if not setup_empire(empire, psd.empire_name, home_system, psd.starting_species, psd.player_name):
            report_error("Python create_universe: couldn't set up empire for player %s" % psd.player_name)
it's far better and more elegant to do:

Code: Select all

    for empire, psd, home_system in zip(psd_map.keys(), psd_map.values(), home_systems):
        if not setup_empire(empire, psd.empire_name, home_system, psd.starting_species, psd.player_name):
            report_error("Python create_universe: couldn't set up empire for player %s" % psd.player_name)
:D

Post Reply