Repository navigation
Limitations and Known Bugs
I've implemented a global variable {SetState("first_footfall")} that tells the script if you've already disembarked once on the relevant body. This makes it so that the post-touchdown summary is only read back to the player once, and not every time you get in and out of your rover or ship. This global variable is reset during the action of mapping a body's surface using the Detailed Surface Scanner (DSS), so if you don't DSS scan a planet before landing, it's likely that the post-touchdown summary will not be triggered. Performing a DSS essentially tells the script, "Hey, I've left the previous planet and have moved on to a different one."
In addition, the status.temperature variable will always report 0 if it is read during the "disembark" event due to a limitation of how EDDI fetches suit telemetry from the game. Because of this, I've implemented reportbody.temperature in its place, but this means that the on-foot temperature readouts will likely not match up with what is displayed on your HUD given that reportbody.temperature is the planet's average surface temperature.
There are at minimum 11 different types of atmospheres generated by Stellar Forge in the Elite: Dangerous universe. Each type has unique sky colors, which makes estimating the sky colors of planets with mixed atmosphere compositions difficult. For example, a planet's atmosphere might be labelled as "nitrogen," but only because the primary gas in the atmosphere is nitrogen. The composition could very well be 51% nitrogen, 26% carbon dioxide, 25% ammonia. Consequently, the script will often return three or more sky colors combined.
In addition, when you start mixing two or more different sets of colors, some colors will appear much more dominant than others. In some cases the estimations may not be spot on. I've done my best to write the script in such a way that the estimations should be pretty close, but there are some cases that will inevitably slip through.
The length of daylight from dawn to dusk will not be the same throughout a given planet's orbital period - the eccentricity of the orbit, the axial tilt, and where you're standing on the planet will all affect the perceived length of a day just as it does on Earth. Currently the reportbody.solarday variable from the API is reported as an average day length throughout one orbital period at the equator, and without a variable telling us the current progress of a planet around its orbit or rotational period, there's no way to calculate day length or sunrise duration at the player's current position.
This is why every readout of day lengths ends with "at the equator."
The script's function to inform the player that they are the first to set foot on a given body is based only on data available from Frontier's API, which at the moment is limited to reportbody.alreadydiscovered. This variable only tells EDDI if the planet has already been scanned from orbit, not if it's been set foot on. Consequently, I've set up the script to inform the player of "first footfall" only if the planet has not been discovered at all, since this guarantees that the player will be the first to land on it.
Planets with this specific appearance are currently bugged in-game. They report a surface pressure of zero while still having a sulfur dioxide atmosphere, meaning that I had to put an error-catching exception into my code for these bodies specifically. According to all known laws of Elite: Dangerous, these bodies should either be landable planets with tenuous atmospheres or landable airless planets, but...they're neither.
Oh and by the way, they're also the only bodies in the game that have literally no value for reportbody.landable. Not false, not true, just...empty. It doesn't even throw us a NULL. That made catching these planets in my script really hard.