Setting Parent Body for a SpaceLocation

[y.petremann]

TLDR; with images :
The game currently render like that.

original.png (455.21 KiB) Viewed 78 times

With the proposal it would render like that.

with_parent.png (449.17 KiB) Viewed 78 times

For now we have :

SpaceLocation:distance :: double : Distance from the location's parent body in map coordinates.
SpaceLocation:orientation :: RealOrientation : Angle in relation to the parent body.
SpaceLocation:draw_orbit :: boolean: If false, the orbital ring around parent SpaceLocation will not be drawn for this location.

It would be interesting to add
SpaceLocation:parent :: string : optional, Name of the parent SpaceLocation,

Implication to current version
we consider that current version SpaceLocation prototype are valid and works the same way because parent is not set
not setting SpaceLocation parent imply parent is universe origin if not set

What will it affect :

• Every SpaceLocation has a parent, with the implicit default being the universe origin.
• universe origin would work like current game version.
• distance and orientation are always relative to the parent.
• global SpaceLocation position is obtained with recursed accumulated transforms.
• Orbit rendering:
  • SpaceLocation orbit is drawn around the parent SpaceLocation instead of universe origin
• SpaceConnection Arc rendering:
  1. At game loading, we compute the common SpaceLocation and arc rendering strategy:
     1. if common SpaceLocation equal origin, straight line strategy is used
     2. if common SpaceLocation equal one of the SpaceConnection ends, straight line strategy is used
     3. otherwise arc around common SpaceLocation strategy
     Examples:
     • origin/calidus/nauvis & origin/calidus/nauvis/muluna => origin/calidus/nauvis (straight line strategy because b)
     • origin/calidus/nauvis/lignumis & origin/calidus/nauvis/muluna => origin/calidus/nauvis (arc around strategy because c)
     • origin/calidus/nauvis/lignumis & origin/calidus/fulgora/cerys => origin/calidus (arc around strategy because c)
     • origin/sagitarius/polyphemus/pandora & origin/calidus/fulgora/cerys => origin (straight line strategy because a)
  2. SpaceConnection arc is drawn using common SpaceLocation and rendering strategy

What it will permit :
- The current space map is fundamentally flat. This proposal introduces hierarchical space locations while remaining fully backward compatible.
- adding another star system with his own set of planets with orbits correctly displaying around their suns
- adding moons to planets with orbits around planets instead of sun
- Ease creation of new SpaceLocation around others
- changing a SpaceLocation distance and orientation would move their child SpaceLocation with them

What other modification is needed in the base game :
The Sun need to be a defined Space Location.
Planets need to have parent="sun"

Code: Select all

{
  type="space-location",
  name="sun",
  distance=0,
  orientation=0,
  draw_orbit=false,
  icon = "__space-age__/graphics/icons/starmap-solar-system-edge.png",
  starmap_icon = "__core__/graphics/icons/starmap-star.png",
  starmap_icon_size = 512,
},
{
    type = "planet",
    name = "nauvis",
    parent = "sun",
    ...
}
{
    type = "planet",
    name = "vulcanus",
    parent = "sun",
    ...
}
{
    type = "planet",
    name = "gleba",
    parent = "sun",
    ...
}
{
    type = "planet",
    name = "fulgora",
    parent = "sun",
    ...
}
{
    type = "planet",
    name = "aquilo",
    parent = "sun",
    ...
}
{
    type = "planet",
    name = "solar-system-edge",
    parent = "sun",
    ...
}
{
    type = "planet",
    name = "shattered-planet",
    -- parent = "sun", -- does not need it since the shattered planet son't seems to orbit this star
    ...
}

Related requests :
- Allow to set a space location's parent
- Orbit Line Movement
- Space Connection Curving
- Render planet graphics from lua code

Other works :
- PlanetsLib
The community has been using Planetslib to implement this proposal. They need to fake the orbits by registering a sprite for it, this result in a lot of sprites only for orbits, the rest of the PlanetsLib api has the intent to implements this sugestion.

Example of actual mods that would directly benefit :
- real-starry-universe
- space-exploration
- factorissimo-2-notnotmelon
- intercontinental-rocketry

[plexpt]

+1

[micromario]

This is neat. Currently us modders basically need to keep a spreadsheet of all planets to avoid collisions with other mods in the starmap. This would be a welcome feature.

[y.petremann]

This is neat. Currently us modders basically need to keep a spreadsheet of all planets to avoid collisions with other mods in the starmap. This would be a welcome feature.

This would not prevent them to colide, but it would be less likely

Something interesting is that someone could make a final-fixes mod to check if some planets collides and simulate them orbiting a bit (changing orientation) to make them not colliding, with current implementation this is impossible because moons would not be around their planets, but with the proposal, it would be possible.

[redplasticstraw]

+1

adding moons to planets and have the orbit draw properly would be really cool

[plexpt]

I find the proposal quite intriguing. It has the potential to significantly enhance the game's space simulation experience.

Enhanced Space Simulation: Introducing the parent attribute would allow us to simulate a more accurate representation of the universe, including star systems, planets, and moons. This would add depth to the game's exploration and construction aspects.

Mod Compatibility: This change would directly benefit several existing mods, such as real-starry-universe and space-exploration, enabling them to provide a more realistic space environment.

Expansion of Gameplay: Not only would this addition increase the depth of the game, but it would also offer players more opportunities for creativity and exploration, such as rearranging the map by altering the distance and orientation of a SpaceLocation.

I support this proposal and am excited to see how it could be implemented in the game. I'm also curious about the developers' thoughts and plans regarding this change.

[plexpt]

viewtopic.php?f=28&t=120727

[DeadMG]

I'd also like more control of the starmap, particularly it would be nice if it could be modified dynamically. I'm thinking of making a mod where certain events may re-arrange the starmap or block some locations

[y.petremann]

After lots of time, I reiterate this proposal with some consideration:

The community has been using Planetslib to implement this proposal. They need to fake the orbits by registering a sprite for it, this result in a lot of sprites only for orbits.

Also as for now space connection are handler in a strange way by mods, and placing planets at sweet spots is needed to have perfect space connection
I propose that space connection use some special logic:

• if a space connexion connect a space location and his parent, then it goes in straight line between the two
• if the space connexion connect two space location with common ancestor, then it goes in an arc around the deepest common ancestor
  • two planets around a star
  • two moons around a planet
  • a moon and another planet around a star
• if the only common ancestor is the universe origin, then it goes in straight line between the two space location
  • space gates connecting two stars
  • two planets on two stars

This proposal on space connection force the devs to declare the sun as a SpaceLocation and to add it as parent to planets

[y.petremann]

Would really love if this would be part of 2.1

[front]

Add this as a related request.
viewtopic.php?t=134210

This would have been to allow planetslib to render moons instead of visible planets in space, as that mod is basically deprecated.

[y.petremann]

Add this as a related request.
viewtopic.php?t=134210

This would have been to allow planetslib to render moons instead of visible planets in space, as that mod is basically deprecated.

I added it to the main post as a related request, and sure being able to see moons from planets or see planets from moons would be interesting
but i think it would be a hard part since we would need to reference each body we want to show and where for each Space Location.

We can take the Nauvis, Lignumis & Muluna example: Lignumis & Muluna are moons of Nauvis
So when orbiting Nauvis, we should see Nauvis and Lignumis & Muluna orbiting around
But when orbiting Muluna, does Nauvis show in the background as distant planet, what about Lignumis ?
The logic is the same for Lignumis.
How does mods would manage this ?

[front]

Add this as a related request.
viewtopic.php?t=134210

This would have been to allow planetslib to render moons instead of visible planets in space, as that mod is basically deprecated.

I added it to the main post as a related request, and sure being able to see moons from planets or see planets from moons would be interesting
but i think it would be a hard part since we would need to reference each body we want to show and where for each Space Location.

We can take the Nauvis, Lignumis & Muluna example: Lignumis & Muluna are moons of Nauvis
So when orbiting Nauvis, we should see Nauvis and Lignumis & Muluna orbiting around
But when orbiting Muluna, does Nauvis show in the background as distant planet, what about Lignumis ?
The logic is the same for Lignumis.
How does mods would manage this ?

Currently, visible planets in space just reads that data from planetslib, and "just knows" how everything is set up. Your proposal moves that exact same data into the base game, so we can read it from there. If the base game does the moon renders, then no other action is needed. it is just there.


I don't consider the orbit graphics a problem for now (I'll fully support having the game do it natively), the tooling/math we have for it is solid until you reach a radius of 1000 on the map (that is where it starts breaking down, 2000 is the absolute limit). The distance between the sun and the shattered planet is 80, so we have plenty of room to work with.
The existing tooling is already working under 2.1, Panglia will most likely be the first moon using it.

Take that suggestion as the bare minimum we need to make it work the way it should. If we don't get moons because it is not needed for the base game (a perfectly valid argument from wube that they usually use), but we can place the planet renders on the map then we can do it from there. IF we don't, we can still use the space map sprites for distant objects like we do now but I don't want to do that unless that is the only option we have.
IF we get all of that, perfect. If we don't, this is the minimum and we want this anyway for other stuff.

When I say "we" I'm one of the devs for planetslib.

[y.petremann]

Add this as a related request.
viewtopic.php?t=134210

This would have been to allow planetslib to render moons instead of visible planets in space, as that mod is basically deprecated.

I added it to the main post as a related request, and sure being able to see moons from planets or see planets from moons would be interesting
but i think it would be a hard part since we would need to reference each body we want to show and where for each Space Location.

We can take the Nauvis, Lignumis & Muluna example: Lignumis & Muluna are moons of Nauvis
So when orbiting Nauvis, we should see Nauvis and Lignumis & Muluna orbiting around
But when orbiting Muluna, does Nauvis show in the background as distant planet, what about Lignumis ?
The logic is the same for Lignumis.
How does mods would manage this ?

Currently, visible planets in space just reads that data from planetslib, and "just knows" how everything is set up. Your proposal moves that exact same data into the base game, so we can read it from there. If the base game does the moon renders, then no other action is needed. it is just there.


I don't consider the orbit graphics a problem for now (I'll fully support having the game do it natively), the tooling/math we have for it is solid until you reach a radius of 1000 on the map (that is where it starts breaking down, 2000 is the absolute limit). The distance between the sun and the shattered planet is 80, so we have plenty of room to work with.
The existing tooling is already working under 2.1, Panglia will most likely be the first moon using it.

Take that suggestion as the bare minimum we need to make it work the way it should. :) If we don't get moons because it is not needed for the base game (a perfectly valid argument from wube that they usually use), but we can place the planet renders on the map then we can do it from there. IF we don't, we can still use the space map sprites for distant objects like we do now but I don't want to do that unless that is the only option we have.
IF we get all of that, perfect. If we don't, this is the minimum and we want this anyway for other stuff.

When I say "we" I'm one of the devs for planetslib.

For me the main problem are orbits and space connections:
- unfortunatly space connection curve selection is actually unsolvable with planetslib currently, if we could at least have a way to define our own curve
- for orbit I proposed that planetslib would get shipped with a set of pre generated orbits and planets could tell "hey you know my radius, use the best pregen orbit and scale it down/up":

- we could register new or replacement orbits with a function like auto_orbit.attach_pregen(25,"__mod__/graphics/orbit-25.png")
- this would permit that changing orbit radius even in final-fixes would automaticaly select the best orbit from the pool of auto orbits
- multiple planets/moons could use the same orbit sprite implicitly
- an unused orbit would not necessarly be loaded
- modders would not need to generate their own orbit sprites (but they still could if they want)

[front]

For me the main problem are orbits and space connections:
- unfortunatly space connection curve selection is actually unsolvable with planetslib currently, if we could at least have a way to define our own curve
- for orbit I proposed that planetslib would get shipped with a set of pre generated orbits and planets could tell "hey you know my radius, use the best pregen orbit and scale it down/up":

- we could register new or replacement orbits with a function like auto_orbit.attach_pregen(25,"__mod__/graphics/orbit-25.png")
- this would permit that changing orbit radius even in final-fixes would automaticaly select the best orbit from the pool of auto orbits
- multiple planets/moons could use the same orbit sprite implicitly
- an unused orbit would not necessarly be loaded
- modders would not need to generate their own orbit sprites (but they still could if they want)

Remember that you can't generate the orbit at runtime. My last PR to planetslib includes a number of pre-generated orbits from existing moons, together with their settings. That should be enough to get anyone started.

This is not every orbit, but in practice it should be enough. IF we need more, then I expect Kryzeth (redrawn space compatibility) to jump in and make it sane like he usually does.
Every unused orbit also increases the file size of planetslib, and we won't make it require a separate asset mod just for this. This is my chosen middleground.

The actual helper function is:

Code: Select all

PlanetsLib.get_orbit_sprite(radius)

It returns the sprite for your orbit. Throws an error if that radius is not available, then tells you what orbits are included.

This is not released yet, will be in the next version.

[y.petremann]

I've taken some times to actually try to showcase what would be different if we were using the parent property.

I've updated the original message with images of a demo I've made about implementing the parent property

- No more orbit sprite to put simply for a simple line
- Space Connections to actually orbit around common ancestor

Here the images of the demo I've made about that:

original.png (455.21 KiB) Viewed 69 times

with_parent.png (449.17 KiB) Viewed 69 times

Also I've put more time in reverse ingenering to load factorio data and making the original starmap than to implement the logic around the parent property