FreeOrion

I know, i just didn't want my previous comments to encourage moving it in the opposite direction.


My main concern is that the terraforming buildings definition needs to reference each species by name. If put a layer of abstraction in there, it seems tidy to also include the rest of the EP stuff.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

Avoiding that and making terraforming content more practical was the motivation for my suggestion a few posts ago for an effect (or perhaps a referencable property for use in an effect) to change a planet's type to the next better for its species (or another species that would be determined dynamically - without referencing a particular species by name).

In my previous post I explained (obviuosly very poorly) how this can be done. I don't know how to write the code, but I know the required algorthim, which I could use to calculate it. Please let me know what is confusing about my post and I will try to explain better. Or if it doesn't work tell me why and I can try to correct it.

Your post was missing an image and hard to read, but is or seemed to be an overly complicated description of a simple calculation that also introduced unnecessary new terminology or possibly required unnecessary changes to how species are defined. It also appears to assume a simple ordering of planets from worst to best, which isn't applicable to the current design and is even less applicable to possible cases like there being more than one best planet type for a species. You also don't give any consideration to how this could be accomplished within the existing effects system with a minimum of code changes and what would be easiest to use for content scripters.

A better method would be to find the best planet type(s) for a species, and find which is the fewest steps from a planet's current type, and then report the next planet type in the direction of the best one. For content scripters, this could probably be set up as a referencable property for planets to be used in the SetPlanetType effect, as in . A more flexible system would allow the scripter to specify a species for which the next best planet type is being determined, which need not be the species currently on the planet (if there even is a species on the planet).

If we're suggesting a fundamental change to the terraforming system one *possible* solution would be composite planet types i.e.
Have a planet type determined by the percentage of the planet's surface that corresponds to that planet type.

e.g. Under the new system a planet is 30% Tundra, 10% Radiated & 60% Ocean, the displayed planet type would be Ocean but terraforming would increase the % of the planet which corresponds to the occuping species EP, whilst decreasing the other types.

Issues; would the % of enviroment types be visible to players? Before or after Colonisation? It would allow species with more than 1 EP, how would these planets be terraformed

Pros; simplifies terraforming, introduces new game possibilities? Would allow for more linear population increases that jumping from Adequate to Good as % would increase slowly?

Cons; introduces possibility of two or more dominant environments on a single planet (e.g. 50% Desert, 50% Ocean) what would the displayed planet type be? What would the bonuses/penalties be? What if a planet is 50% Good EP, 50% Hostile EP? Complicates planet creation at start-up (although random number generation could be used)?

I don't think planets are going to fundamentally change. The simplified model of planet types was chosen for the sake of it's simplicity-- over more complicated models, some IIRC similar to what you've suggested.

You've laid out Pros and Cons well, except i don't think it really simplifies terraforming. The Cons are significant, not because they are insurmountable, but any solutions would tend to move FO away from being the kind of game we're trying to make.

What we want here (in my non-authoritative, but informed opinion) is a better way to make terraforming do what it was supposed to do all along.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

As far as I know, only Terraforming is affected. And as Academician pointed out, it actually only works for Trith, since eleazar also changed the Gyisache EP to Swamp.

I believe he is referring to the fact that the planet types are numbered from 1-9 (or something like that), with Swamp and Ocean being the "bookends" and asking if what he's described will make Terraforming work for each species. And I think the answer is "probably/I don't remember", although hopefully defining Terraforming in that manner will end up being unnecessary.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

I've added an (untested) property to planets for scripting to aide terraforming effects. It's used like this:

NextBetterPlanetType returns the planet type that is one step towards one of the referenced planet's species' optimal planet types. This always returns a move towards the overall optimum, ignoring any local optimums that might result in moving to a worse planet type before arriving at (one of) the best.

It'd be nice if the content files were updated soon to make terraforming work for all species. The property mentioned above should make this possible...

I tried using this building as the Humans on a Swamp planet:





What should have happened was Swamp --> Ocean --> Terran

What actually happened was Swamp --> Toxic --> Inferno --> Radiated --> Inferno

Edit:

I tried again as Egassem (EP Inferno) and got Swamp --> Ocean --> Terran --> Ocean

_________________
Warning: Antarans in dimensional portal are closer than they appear.

So it's doing exactly the opposite of what it claims. Amusing...

Edit: In Species.cpp line 282 change > to < and try again? /Edit

That seems to have fixed the problem. Here are the new Terraforming buildings:

_________________
Warning: Antarans in dimensional portal are closer than they appear.

Which files need to be changed ​​to test their effect?

None; those changes were added to the SVN version.

in svn 4217 the change isn't in or? for me it looks so.