one way stargates exclusively built on planets

Hello!

the arrival location should be that very thing according to me too, but also in game there is a highest mountain altitude, and in case a planet can be targeted, then the line between may show the arrival location (if that is any easier for the devs) - such as slightly over the highest mountains inside the gravity field, and inside the atmosphere on that line between the planets (even if the telporter is off by just a tiny bit) - that should be fine, and that will even promote the arrival location to be an implicit encounter position too - since there is only one of it on a planet for one other planet

i am not fond of your number two proposal because then the position of the "stargate", or "jumpgate" does not matter, and players can not get control over getting to certain planets against other players which is omitting to force them to meet with one another (with you proposing the arrival of players to be relatively random you also propose to not make the players meet one another in game - just like with your number two proposal)

your proposal of number one can be player friendly in numerous ways

for example if the "stargate", or "jumpgate" block literally shows the player the exact lines between planets via an info tab "show on hud" setting (just like gravity field, and sensor range)

or another approach is that for example by being able to build this block onto a mobile grid, and look for it changing color based on its proximity to lines between planets. if this block is right on the line between two planets while it is on a mobile grid, its color changes from red to yellow, and if the player makes the grid of the block to be a station, then it will change to green. (when the block is turned off it does not show any colors). if the player makes the grid containing this block to be a station before a planet is in front of it, the block turns dark blue (like the "night sky" that is black) indicating that it will teleport into space. (in other terms while this block is on mobile grid it can be used to search for these lines, and when this block is stationary, it can be used to teleport up)

or another possible approach is to make the coordinates of planets more available to players to be used

i would like to hear more opinions of you.

do you still think to make your number two important besdies your number one can be made player friendly too?

I concede that my second idea (the turret one) would negate all the fun of searching the right locations.

After that, if the block teleports you at a random position on the visible side of the destination planet, I think it would be useful to be able to connect later two Teleport blocks, like the laser antenna.

• Of course, until the two blocks are linked, a teleport block sends you to a random place.
• Or maybe the link block is a module for the Jump Gate block, like the speed, yield and power ones (A higher tier one, I mean) ? The problem is that i don't see where you can place it the original tech tree. Maybe they will change it with the next Survival update?

Your idea is a great one really. It even allows the jump drive to be kept as a specialized tool for space exploration between worlds.

The ability to use the block itself as a detector is a very cool idea. For the location finder, you could have several possibilities:

• A GPS List of the right locations on the departure planet, that you can find only in the block. It could be precise or approximative, like the search mission GPS coordinates.
• The fact that the line shows when the "Show on hud" toggle is on, like the sensor and gravity areas show for the sensor and Grav Gen block.
• Or with an app on on a LCD screen. Like a compass, but instead showing N S E W, it will show: Ea, Mo, Ma, Eu, Al, Ti, Pe, Tr. (with modded planets, maybe the mod take the first two letters of the planet ?)

For the mod to work in creative/custom worlds, perhaps the mod calculates the GPS coordinate where the line between the center of two planets intersects the surface?

i believe that you misunderstood me a bit regarding the arrival point.

i proposed that from the same planet no matter slight deviations you will arrive to the other planet on the intersection that is closer to the source planet of the line between these planet centers, and that is a littlebit further from the target planet's "top of all mountains radius" from its center (a little bit above top of all mountains) - this means that according to me there should be no random locations to arrive at, but that exact intersection - this is even more easy to do programmatically because then you don't need to care of the arrival point depending on the exact angles, and you don't need to do linking between jumpgates (teleporters), but rather just calculate the line between the two planets' middle points

regarding shorthands for planet names in mods, or generally:

a planet object should be overridable such that its type can be extended with a field that can show a "shortname" of the planet

regarding the "searching for the line that is between planet midpoints and that will intersect the surface on the surface"

premise: programmatically it is more easy than you think. around every planet there should be a theoritical sphere which - even if it is just the player's distance from the planet's center radius - can be intersected with a line that goes through its center. for each such line for each planet in the game intersects such theoritical sphere exactly twice, and exactly at the opposite sides of it. in order to find the proper intersection - the player should head to - on the planet's surface first choose the closer intersection to the other planet, and name it "Thales" point. any segment between this "Thales" point and the seeker player's current position inside the planet's gravity field is angled exactly half of the angle measurable at the center of the planet between the player, and the "Thales" point - let's name it "Center" angle (attention of this is required if it gets to 90 degrees). the segment between the player, and the planet's midpoint is orthogonal (in right angle to) the vector the player has to follow in order to find the proper intersection.

ingredients, and setup to create this vector to be followed by the player:

consider the planet the player is on put into the origoo from now on

consider the line between the two planet middle points as "u" line

consider the other planet the vector heads to on the surface compared to the player's current planet as "u" vector that is exactly on "u" line (with the planet the player is on put into the origoo)

consider the player's position on the planet as "z" point, and "z" vector (with the planet the player is on put into the origoo)

consider the player's current planet to possess exactly the magnitude of "z" vector as its radius

consider a plane that is tangent to the surface of the sphere planet, and touches it exactly where the player is standing, and which's normal vector is "z" vector - named as "z" plane

consider "u" line, and "z" plane's poking point "d" point

- note in case "Center" angle is 90 degrees there is no "d" point, for that there is a special case i will describe

further on you will need to calculate angles of five infinite cones all of which's sides are tangent to the planet the player is on, and only the last one's position is important, the others are only helping via their opening angles, or halves of those. between the last cone's point, and "d" point the vector is that is showing the player the direction. all except the second cone are acting like vertices of a shape around the planet's sphere (important: use the z_vector's magnitude as the planet's radius)

consider the first infinite cone as "u" cone

the second infinite cone as "au" cone

- note that the name comes from "anti u cone"

the third infinite cone as "s1" cone

the fourth infinite cone as "s2" cone

the fifth infinite cone as "u'" cone

- note the last infinite cone is named "u'" because its vertex would be in the exact place of "u" cone's vertex if these calculations were in 2 dimensions. between this final cone's point, and "d" pont will be the vector that shows the player the direction

now the calculations:

calculate "u" cone half opening angle =arcsin(abs("z"vector)/abs("u"vector))

- here make sure that you clamp "abs("z"vector)/abs("u"vector)" between -1, and 1, otherwise it will go haywire with rounding errors

at this point let's take care of the situation the "Center" angle is 90 degrees - if it is, then use "abs(z_vector)*tan(u_cone_half_opening_angle)" to elongate the z_vector into a point from which the result vector is pointing towards the other planet (=u_vector-the_origoo_vector_of_this_point), or don't elongate anything at all, and just use a vector that points from z_point to the other planet's middle point - this concludes the result_vector that will show direction in this edge case with no "d" point

in cases "Center" angle is not exactly 90 degrees:

calculate where "d" point is - for this you will need the formula of the z_plane's normal vector, and the formula of the u_line, and you will need to marry these together. z_plane's normal vector is just z_vector normalized. first you multiply the components of z_vector to its own normal vector's components, you summarize these components, then multiply it with -1 (let's name this "zn")

second you need to multiply the components of u_vector with the normalized z_vector, summarize it, then multiply it with -1 (let's name this "un")

now "m" equals "zn/un". multiply u_vector with "m", and you get "d" point

- note: "un" is zero when the "Central" angle is 90 degrees

for the final part of the calculation:

calculate the infinite cone's opening half angle that is facing against the "u" cone the way that it intersects it exactly where the u_cone is touching the sphere that is with origoo midpoint, and z_vector magnitude radius (au_opening_half_angle = pi/2 - u_opening_half_angle)

normalize u_vector, i will name it "u_n"

consider the coordinates of Thales point using magnitude of z_vector as current planet's radius (Thales vector = u_n*abs(z_vector))

calculate distance between "d", and "Thales" point, i will name it "a"

calculate distance between "z" point, and "Thales" point, i will name it "b"

calculate distance between "d", and "z" points, i will name it "c"

- preferably subtract "d" from "z", as this will be required later as a vector "c_vector"

calculate the angle between u_vector, and z_vector (which is the angle in "Thales" point let's name it "Thales" angle) = arccos( (c*c-a*a-b*b)/(a*b*-2) )

if this angle is over 45 degrees (angle > pi/4), then subtract it from 180 degrees (= pi-Thales angle), otherwise just use the "Thales" angle as it is.

calculate "Center" angle (=2*Thales angle)

now calculate s1 cone's full opening angle (=pi-"Central" angle - au_half_opening_angle), but if "Center" angle is greater than 90 degrees (angle > pi/2) then multiply the resulting angle in radians with -1.

s2 cone's full opening angle is (pi-s1)/2

the last cone "u'" cone's half opening angle is "l" angle = (pi/2)-s2

now you need to calculate the "u'" cone's vertex's coordinates

first you need to determine the distance of the tangent point of this cone to the planet that is expected to be with z_vector magnitude radius that is "t = abs(z_vector)*tan("l" angle)"

then you need the normal vector between "d", and "z" points, and for that the earlier got "c" distance can be the base, since that is the magnitude of the vector that is needed, in other terms make "c_vector" (=z_vector-d_vector), and then normalize it with "c", let's name it "c_n"

now the "d" point's distance from the "u'" cone's vertex is "du" = t+c

now in order to get the "u'" cone's vertex with the "d" point in the origoo multiply "c_n" with "du", and name it "L''"

now to get the same thing with the player's current planet's middle point in the origoo add "d_vector" to it (that is based on "d" point's position relative to the planet's middle point in the origoo). "L'" = "L''"+d_vector

for a result vector that points the player towards a line between two planets you will have to move both "d" point, and "L'" points into world coordinate system by adding the player's current planet's middle point to both of these points ("D"="d"+planet_world_p; "L"="L'"+planet_world_p), and then subtract "D" from "L" (result_vector = L-D)

these calculations were working on my side - albeit that does not gurantee that i can write everything with exceptional precision. if i notice mistakes in this very explanation i will try to comment it.

- in other terms make it so that these points can be seen in gravity field only, and with geometry magic calculate the vector the player has to follow in order to get from one such point to another on, or close to the surface of the planet. maybe even include an indicator in case the position is right beneath the other planet rather than just showing it

further more when it comes to modded planets:

each planet in game (even without mods) should be an object that is type of "Planet". an instance of a planet stores information related to the highest mountain on it, and the gps coordinates (world coordinates) of it currently.

further the coordinates of each planet should be a single entity like an object of type "FixedPlanetCoordinates". currently planets are parts of the "game world" as fixed objects, and so currently it is rather easy to keep their static not moving world coordinates as members of the planet instances rather to an environment's. there should be one such entity for each planet instance, but this entity does not make sense without the environment the planet is in - in case modders try to achieve for example orbiting planets, so i suggest to besides this static placement introduce "NonfixedPlanetCoordinates" as a type, and use it to index planets in an environment. (beside this it is still possible to store the planets' fixed center points in "world coordinates" inside the planets according to free will)

so these planets should be present in an environment - lets say another object with type "SpaceEnvironment" - such that when a planet is added by someone in lets say creative game mode (or even removed), or lets say it spawns into the game by default, that planet is immediately added (or removed) to the respective envrionment. (i say "respective" here because modders should be able to override the used environment in order to facilitate environments with orbiting, and rotating planets to ensure backwards compatibility)

in the environment each "NonfixedPlanetCoordinates" is tied to its respective planet in a two dimensional array - such that based on the planet's center the planet can be referred to, and based on the planet its center can be referred to in the environment.

by letting the modders override such environment, it is possible for them to determine (to mutate the array) where are they expecting a moving planet, and even fire events when such center point changes - in other words my suggestion is that when the devs need to declare lines between planets, they should use this environment rather to the fixed world coordinates of planets in order to facilitate modders' work in changing a planet's place, or refresh the lines between planet midpoints using events in case those planets are moving. (without mods the line has to be refreshed once when the planet is created, and be deleted once when the planet is deleted, or just grant the ability for modders to set up their own events related)

abouth that 2d array: technically devs should not expect millions of planets in a game world, and even if they did, they would only store the reference of planets, and the reference of those's "movable positions" in that mutable array. everytime a player spawns, or deletes a new planet, this array has to be reinstanciated in the environment (not the entire environment for the modders' sake) - this will result in the events related are needed to be unsubscribed from the old, and then subscribed to the new instance of array

so programatically it is possible to facilitate modders' work, but i am not familiar with the actual current situation , and i am also not familiar with a possible solution for the devs they would rather choose over my proposal.

i noticed a mistake already,

so when you calculate the edge case of "Center" angle being 90 degrees it is possible to translate u_vector into world coordinates from the player's position rather from the planet's middle point - achieving the proper vector that is parallel to the u_line

also there are two additional edge cases - which when the player is located exactly on the u_line. in these cases "Center" angle is 0 degrees - with the closer intersection's case in which "Thales" angle approaches 90 degrees, and with the further one's case "Thales" angle is 0 degrees

the true purpose of the algorythm was to determine jump path around planets in case the gps marker was located on the other side hidden by the planet's gravity field

there is also an edge case where the block is right in the middle of the planet - in which case it is zero distance away from the planet's midpoint resulting in all the lines crossing the block from all the planets resulting in the block possibly unable to determine where to jump the player (possibly)