Universe Generation
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.
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.
-
- Space Floater
- Posts: 27
- Joined: Tue Aug 06, 2013 6:44 pm
Universe Generation
New test build (SVN 6838) seems to have a universe generation glitch. I've tried a few dozen starts and get plenty of Caretaker fruit planets but either none or only 1 for Ki Spice & Probiotic soup planets. For the last 2 tests I had changed the research time and cost for the SPY_DETECTs to cost .1 and take 1 turn so by turn 5 I could survey a large number of planets. I had 6 Fruits, 1 Soup and no Spice. The prior game had 7 Fruits and 0 of the others.
Op Sys: Win 7 Home 64bit
I attached my turn 5 save by suffixing .txt to end of filename.
Op Sys: Win 7 Home 64bit
I attached my turn 5 save by suffixing .txt to end of filename.
- Attachments
-
- FreeOrion_i_i_0005_20140207_125622.sav.txt
- (1008.15 KiB) Downloaded 77 times
Re: Universe Generation
I have actually noticed a lack of variety in growth specials as well, hadn't occured to me to check actual numbers.
FWIW for you, as you're using a test release, if you're just looking at generation, either use multiplayer or convert to Super Testers, they can see the whole galaxy immediately they take over your homeworld, useful for this sort of thing.
Looking at the specials file, Fruit should be slightly more common as it has one more possible spawn planet type, but has otherwise the same chances. My current game, which I'm about to finish, has 4 Fruits but none of the others, on a medium specials layout.
Checking through, Fruit is the only growth special I've got with the exception of Slimaline Crystals, which has only appeared on asteroids and should be appearing randomly on lots of planet types.
FWIW for you, as you're using a test release, if you're just looking at generation, either use multiplayer or convert to Super Testers, they can see the whole galaxy immediately they take over your homeworld, useful for this sort of thing.
Looking at the specials file, Fruit should be slightly more common as it has one more possible spawn planet type, but has otherwise the same chances. My current game, which I'm about to finish, has 4 Fruits but none of the others, on a medium specials layout.
Checking through, Fruit is the only growth special I've got with the exception of Slimaline Crystals, which has only appeared on asteroids and should be appearing randomly on lots of planet types.
- Attachments
-
- growth-specials.png (33.13 KiB) Viewed 1581 times
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Universe Generation
It seems I've noticed that also. Natives is another thing that often seems really skewed to me; to help track that I just recently added a little extra server-side logging to universe/UniverseGenerator.cpp. It sounds like I should probably add some more logging to show the distribution of specials & then commit that so that everyone interested can see their actual numbers.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Universe Generation
ok, I put in those changes, and indeed the growth specials are unbalanced -- Fruit and Crystals are maxing out, but no others are spawning. I'll look at it more.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Universe Generation
Having been curious, the next game I've started is set to High specials, despite this I'm not seeing many at all, of any type. Admittedly it's still Low planets, but at 400 systems and my Laenfa having got through half the ring I'd expect to see more than I'm seeing, of any type.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
-
- Space Floater
- Posts: 27
- Joined: Tue Aug 06, 2013 6:44 pm
Re: Universe Generation
Sorry I posted the problem to the wrong spot. Thanks for moving it to its own thread.
Thanks MatGB for the Super Testers suggestion I should have thought of that.
Dilvish, how would I access the server-side logging to universe/UniverseGenerator.cpp?
Thanks MatGB for the Super Testers suggestion I should have thought of that.
Dilvish, how would I access the server-side logging to universe/UniverseGenerator.cpp?
Re: Universe Generation
Look here. freeoriond.log will be the name of the server logWhat Exit? wrote:Dilvish, how would I access the server-side logging to universe/UniverseGenerator.cpp?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Universe Generation
Ok, so I think I have it figured out. The problem summary is that the current code and data structures lead to high odds (very high in low planet galaxies) that the specials other than Crystals and Fruits will come up when a system is under consideration and then be skipped over. The basic solution is that AddStartingSpecials() needs some more randomness injected into it.
The basic structure of AddStartingSpecials() is an outer loop over all objects once, and an inner loop that cycles through the specials. In the inner loop it checks if the current special has not reached its spawn limit and is compatible with the current object, if so it marks a flag that it is attempting to add a special and does a random roll check against the special's frequency, adding it to the object if that passes. If at the end of the inner loop it advances to the next special (back to the beginning if need be), and then if it's reached the first special it had checked for that object, or if the flag is marked that it attempted to add a special to that object, then it drops out of the inner loop and the outer loop advances to the next object.
With just those details so far that's not necessarily a flawed approach; it has a potential weakness because it's always processing objects and specials in a fixed order (objects are essentially considered in order created, and specials are considered in alphabetical order); in the past that had worked out. The recent code change that made this go from working well enough to not doing so, is that now rather than creating all the systems first and then creating all the planets, we now create a system and its planets together. This interacts poorly with the current distribution of specials taken alphabetically -- the growth specials other than Crystals have a much much higher spawnrate than any other special, and are almost entirely clumped together. The new object distribution creates the most problems in low planet setups, where the objects tend to alternate System, Planet, System (systems might be found in a row, but planets are almost always folllowed by systems). To cut a long story short, the structure leads to high odds (very high in low planet galaxies) that the specials other than Crystals and Fruits will come up when a system is under consideration and then be skipped over.
I'll try implementing things so that at the start of each outer object loop, it will select a new random order for the specials to be considered for that object.
The basic structure of AddStartingSpecials() is an outer loop over all objects once, and an inner loop that cycles through the specials. In the inner loop it checks if the current special has not reached its spawn limit and is compatible with the current object, if so it marks a flag that it is attempting to add a special and does a random roll check against the special's frequency, adding it to the object if that passes. If at the end of the inner loop it advances to the next special (back to the beginning if need be), and then if it's reached the first special it had checked for that object, or if the flag is marked that it attempted to add a special to that object, then it drops out of the inner loop and the outer loop advances to the next object.
With just those details so far that's not necessarily a flawed approach; it has a potential weakness because it's always processing objects and specials in a fixed order (objects are essentially considered in order created, and specials are considered in alphabetical order); in the past that had worked out. The recent code change that made this go from working well enough to not doing so, is that now rather than creating all the systems first and then creating all the planets, we now create a system and its planets together. This interacts poorly with the current distribution of specials taken alphabetically -- the growth specials other than Crystals have a much much higher spawnrate than any other special, and are almost entirely clumped together. The new object distribution creates the most problems in low planet setups, where the objects tend to alternate System, Planet, System (systems might be found in a row, but planets are almost always folllowed by systems). To cut a long story short, the structure leads to high odds (very high in low planet galaxies) that the specials other than Crystals and Fruits will come up when a system is under consideration and then be skipped over.
I'll try implementing things so that at the start of each outer object loop, it will select a new random order for the specials to be considered for that object.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Universe Generation
ok, I think I have it fixed now; at the very least I'm getting reasonable looking distribution of growth specials. I went ahead and committed the fix. I also added a small chance (currently 8%) of considering more than one add-attempt per object. Since each add-attempt has a strong chance of failing, the effect of that is to increase the total number of applied specials by about that same chance amount, and give a much much smaller chance of applying two specials to an object (seems to be working out to something less than half a percent right now). I thought I remembered there being some chance of that before also, though I didn't find any hint of it in the latest code. That could easily have the chance lowered or taken out altogether; feedback requested.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Universe Generation
Will need to wait until it's compiled into a new exe next week, I looked into compiling myself and I don't think my laptop will manage it, it's below the min specs in the wiki and isn't in great condition anyway. Given the current test release has the generation code in default but SVN has the new folder and that requires changes in compiled files I'll do some test generations as soon as a new version is available.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Universe Generation
I think adrian_broher has been making some changes that ease the compilation demands, so I wouldn't assume it won't work without giving it a try. But it might still be a lot of hassle; I'm not familiar with the windows setup. If we're lucky Vezzra might have time for an early build.MatGB wrote:Will need to wait until it's compiled into a new exe next week, I looked into compiling myself and I don't think my laptop will manage it, it's below the min specs in the wiki and isn't in great condition anyway.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Universe Generation
The reason I do the weekly builds on Monday is that usually the weekend is where people get quite a lot of work done, so making new builds on Monday ensures all the weekend work gets into them. I won't have time for new builds today (Saturday), as it's already too late in the evening now, but if so desired, I can make new test builds tomorrow (Sunday) instead of Monday. It just doesn't make much sense to make builds on both days IMO.Dilvish wrote:If we're lucky Vezzra might have time for an early build.
Re: Universe Generation
Normally, Monday builds make sense, but the current test still has the ships starting with no structure issue and a few other things theoretically fixed, that alone makes testing other features a PITA as it's hard to know what is and isn't balanced when the AI fleets sometimes die when you sneeze at them, etc.
If you can do one tomorrow, that'd definitely help me as there's a chunk of things fixed in SVN that I'd love to test properly, but I think your normal approach works best unless there's a major issue, as with the current and previous builds.
If you can do one tomorrow, that'd definitely help me as there's a chunk of things fixed in SVN that I'd love to test properly, but I think your normal approach works best unless there's a major issue, as with the current and previous builds.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Universe Generation
Done.MatGB wrote:If you can do one tomorrow, that'd definitely help me as there's a chunk of things fixed in SVN that I'd love to test properly
Re: Universe Generation
Whoohoo! Thanks Vezzra!Vezzra wrote:Done.MatGB wrote:If you can do one tomorrow, that'd definitely help me as there's a chunk of things fixed in SVN that I'd love to test properly
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0