Honeycomb special creates systems with stars but no planets

[Vezzra]

Recently an adjustment to planet placement went in (PR#718), which ensured that systems with stars (meaning, with a star type other than "no star", "blackhole" or "neutron") has at least one planet or asteroid belt. However, the Honeycomb special removed the planets of the surrounding systems, so planetless stars can still occur.

Shall we keep that as a exception to the "no planetless stars" rule, or shall we set the star type of the affected systems to "no star"? Or does anyone have another idea?

[MatGB]

Awhileback I had a commit in my working branch which rather than destroying the planets instead made them all asteroid belts. Given that it didn't rename them you ended up with a fairly substantial clue that the Honeycomb was nearby and I think it worked well.

But I never finished it off and the splitting of the FOCs scripts up meant it'd need redoing and, frankly, I forgot about it until today.

I would rather that the stars remain there, the Honeycomb is meant to be one of the ultimate specials and having it affect the nearby neighbourhood is kinda cool, so I'd have the planets broken up into asteroids than anything else, but I don't have a strong opinion. I did the change myself partially entirely for my own benefit (the removal of no star systems was somethign I'd been after for ages afterall) and partially to test that I understood how to do the scripting right.

It is now even more incongruous, and for an experienced player would be an obvious clue, so I think having the asteroids with planet names might be better overall, give players that don't know a clue there's something up, etc.

[Sloth]

Awhileback I had a commit in my working branch which rather than destroying the planets instead made them all asteroid belts. Given that it didn't rename them you ended up with a fairly substantial clue that the Honeycomb was nearby and I think it worked well.

But I never finished it off and the splitting of the FOCs scripts up meant it'd need redoing and, frankly, I forgot about it until today.

I would rather that the stars remain there, the Honeycomb is meant to be one of the ultimate specials and having it affect the nearby neighbourhood is kinda cool, so I'd have the planets broken up into asteroids than anything else, but I don't have a strong opinion. I did the change myself partially entirely for my own benefit (the removal of no star systems was somethign I'd been after for ages afterall) and partially to test that I understood how to do the scripting right.

It is now even more incongruous, and for an experienced player would be an obvious clue, so I think having the asteroids with planet names might be better overall, give players that don't know a clue there's something up, etc.

Sounds like a good solution. I like it.

[Vezzra]

@Mat, yep, sounds like a interesting solution - go ahead

[MatGB]

Will do, I forgot to mention but I'm away for the week and only have my laptop (which I never set up for Git work), the work's on my desktop, OK to do it over next weekend when I get home?

But yeah, in my current game I found another Honeycomb and, post recent changes it was even more jarring, the description says stripped of resources and destroyed, an asteroid field is as good as empty space, which I now dislike even more (and not just because it makes supply linking the Huge world after you've taken the Warden out a pain (unless oyu're George, obviously).

[AndrewW]

I did have one game with the honeycomb special in the same system as the experimenters. That could be interesting, asteroid belt the experimenters homeworld?

[Sloth]

I did have one game with the honeycomb special in the same system as the experimenters. That could be interesting, asteroid belt the experimenters homeworld?

The honeycomb doesn't touch the experimentor outpost:

Code: Select all

        EffectsGroup
            scope = And [
                Planet
                Not Species
                Not HasSpecial
                WithinStarlaneJumps jumps = 2 condition = Source
                Not ContainedBy Contains OR [
                    Design name = "SM_EXP_OUTPOST"
                    Building name = "BLD_EXPERIMENTOR_OUTPOST"
                ]
            ]
            activation = Turn high = 0 
            effects = Destroy

[AndrewW]

The honeycomb doesn't touch the experimentor outpost:

It didn't in that game, both where present in the same system. Just thinking something to consider in all of this if they do happen to appear in the same system.

[Sloth]

It didn't in that game, both where present in the same system. Just thinking something to consider in all of this if they do happen to appear in the same system.

Maybe we can add a tag for important/unique specials like the honeycomb ("legendary"?) and make sure that the experimentors don't spawn in a system with one of those specials. We could also prevent multiple legendary specials spawning in the same system.

[Vezzra]

OK to do it over next weekend when I get home?

Sure.

[Sloth]

I went ahead and produced a tiny PR that applies the changes suggested by Mat here: https://github.com/freeorion/freeorion/pull/774

I haven't participated in developing FO for more than 8 month, feeling a bit rusty.

[MatGB]

I went ahead and produced a tiny PR that applies the changes suggested by Mat here: https://github.com/freeorion/freeorion/pull/774

That looks to be more comprehensive than I did, but I hadn't tested it, for future ref is set planet size needed for this?

Regardless, can't test it here so don't want to merge, but does look fine to me, and it doesn't need a stringtable update so if anyone wants to confirm it's fine and merge it I'm very happy to see it (especially given Honeycomb is Sloth's baby)

I haven't participated in developing FO for more than 8 month, feeling a bit rusty.

I kept planning to get in touch check you were OK, don't need to now —will really appreciate assitance if you're available in the next Release cycle, Fighters is going to be a fairly big job and I always like bouncing ideas around with you.

[Sloth]

..., for future ref is set planet size needed for this?

I'm not 100% sure, but i guess it should be possible to have large or huge asteroid belts and for example population uses Target.SizeAsDouble (which will allow lots of Exobots on these asteroids).

will really appreciate assitance if you're available in the next Release cycle, Fighters is going to be a fairly big job and I always like bouncing ideas around with you.

I haven't even tested fighters yet, but i'm quite impressed by the amount and quality of the changes i've noticed so far (especially the UI upgrades).

[dbenage-cx]

Maybe we can add a tag for important/unique specials like the honeycomb ("legendary"?) and make sure that the experimentors don't spawn in a system with one of those specials. We could also prevent multiple legendary specials spawning in the same system.

Are specials (or ship designs) compatible with tags? Neither have them currently, I suspected that tags were not designed with them in mind (not strictly objects).

[Vezzra]

..., for future ref is set planet size needed for this?

I'm not 100% sure, but i guess it should be possible to have large or huge asteroid belts and for example population uses Target.SizeAsDouble (which will allow lots of Exobots on these asteroids).

Yes, setting planet type and size is required in this case. AFAIK the engine expects asteroids and gas giants to be of the "special" planet sizes "asteroid" and "gas giant". The "tiny" ... "huge" sizes are not intended for asteroids and gas giants. Mixing these up will produce unpredictable results. So you have to set both type and size accordingly if you want to create/convert something into a asteroid belt or a gas giant.

If we want to apply the standard sizes ("tiny" ... "huge") to asteroids and gas giants as well (so we can have different sizes of these), this will require changes to the backend C++ code.