tmktahu / ips Goto Github PK

IPS needs a mono receiver option.

To do this, we need to take one receiver and loop it through the transmitter station messages and store them one at a time between coordinate update cycles. Since we can't dynamically create references to different variables, we need to hard code the variable assignments, which means they need to be on different lines that we loop through.

To loop through lines we have 2 options from what I'm aware of:

1. Keep a count and use a goto(??+count), then increment and loop the count as needed.
2. Have the lines set a variable that contains the index of the next line to be used.

I believe option 1 is most code efficient, but only if the incremented variable is 1 character. Since we use all single-character variables already, this may not be any more efficient than just hardcoding the next target line number. Plus we may not be strapped for space on these lines.

But, we have another issue. IPS functional lines are tight right now, and we don't want to increase our update time if we can help it. That means we need to skip the first line of functional code, which means the x and y calculations need to be done on these alternate mono lines.

So the plan is we go for option 2 initially. Each line should:

• Read the current signal strength from the receiver and store it.
• Calculate X and Y so the code can pick up normally.
• Flip the receiver to the next target message.
• Set the next goto number for the next loop.

During initial implementation, I encountered a problem with the receivers. The update time after a new target message has been set is sporadic and unreliable. This means that receiver values get stored in the wrong variables. Since our math requires certain variables to contain distances to specific transmitter stations, this royally ruins the coordinate calculations.

So we need a way to reliably predict receiver updates, force a receiver update, or have checks in place for bad receiver values. How we do this is the next big TODO.

A huge + to using a coordinate system is knowing what direction you are flying. But pulling this off is tricky.

We can represent a direction as a vector, and we can get this directional vector by subtracting our current coordinate from our previous coordinate. But this only gives us pitch and yaw information relative to the axes. Technically, this is enough to display a direction, but the rotation of the display depends on the ship's roll.

To calculate roll, I can think of 2 options:

1. Calculate coordinates for a left and right edge of the ship to define a left-right axis. Then compare the rotation of this axis to the coordinate grid to get the roll. This method requires at least 2 independent coordinates.
2. Assume the rotation based on change in direction combined with player input. If we store the previous directional vector and compare it with the current directional vector, we can get the change relative to the coordinate grid. From there we check the user's FCU input controls to see what they are pressing. With all that, we can assume the ship's rotation.

Option 1 is probably the cleanest, but requires at least 2 independently calculated coordinates. Since we would like the Module to be as accurate as possible, these would have to be quad coordinate systems, which is a lot of receivers. It would work, but the construction overhead is eh.

Option 2 would be the cleanest design-wise, but probably the most tricky and error prone. My instinct is the update speed may not be great either given the additional calculations and then tapping into the FCU values. But it could work.

TODO:

• Research options 1 vs 2 to see what the code and construction overhead of each would be.
• Brainstorm display options. How do you go about displaying direction with current control devices?
• Look at methods of comparing two directional vectors. Dot product with law of cosines?

Instead of trying to tie velocity directly into the base IPS code, I want to house it in a separate module.

In a perfect world, the module would have the following features:

• 0.2 update speed
• optional ability to store speed and velocity on memory chips
• option to display speed on the same text panel as standard IPS
• method of stabilizing the output to buffer against random coordinate spikes

But given line restrictions, not all of this may be possible. The speed calculation can only be compressed down so far.
d=sqrt((:x-x)^2+(:y-y)^2+(:z-z)^2)/t is the smallest form I know of, which is 36 characters.

In addition, velocity involves direction and speed, which means we want the ability to store a vector and the speed itself. the vector in question is [:x-x, :y-y, :z-z], so if we want to store those values then there need to be 3 additional assignment statements.
:u=:x-x :v=:y-y :w=:z-z d=sqrt(:u^2+:v^2+:w^2)/t ramps us up to 48 characters.

We also need to grab the current coordinates and save them for the next iteration, which is another round of assignments.
:u=:x-x :v=:y-y :w=:z-z :d=sqrt(:u^2+:v^2+:w^2)/t x=:x y=:y z=:z brings us to 64 characters.

And then we have the problem of display. We only have 6 characters left and need a goto statement in there as well, so display is pretty much impossible on this line.

We could consider making base IPS handle display optionally, but the code is so tight there to begin with that we would end up sacrificing configurability for more displayed information.

TODO:

• Consider the downsides of a 0.4 update time to allow for display and potentially stabilizing logic.
• Brainstorm the idea of a Display Module for the IPS system that purely handles display of information.
• Write up a properly minified version that does not store the velocity vector.
• Write documentation that explains the reasoning behind separating velocity out into its own module.

Right now configuring the Waypoints Course Module is pretty gross. It requires a lot of setup, and one of those setup pieces is manually saving each waypoint coordinate in memory chips.

I want to create a companion script specifically designed to help with saving waypoints. It should have the following features:

• Display for the currently waypoint selected and its current coordinates.
• Buttons/switch for flipping between selected waypoints.
• Button to save current coordinates into currently selected waypoint.

One way we can achieve a ~0.2 second update time is to run multiple instances of IPS at the same time offset from each other. The code is compatible with itself, so you can already run several instances at once without problems.

But because line execution time is not perfectly 0.2 seconds, multiple instances will eventually become out of sync with each other. To handle this we want to try and add a line to the execution code that automatically syncs different IPS chips together after some time has passed.

Because this would add 0.2 seconds to update time, bringing us to 0.8 seconds. Because of that we want to make this multi-instance IPS version separate from the 1-chip version. In addition, it will need to run on 4 chips and the syncing logic will need to handle starting each chip on a different line to keep them offset from each other.

The current IPS implementation uses euclidean coordinates. Primarily this is because it's easier to wrap my head around euclidean coordinate math. But eventually professional chips will become available, and with them access to trig functions.

The question is what would a coordinate system look like if the core math was based on a spherical or cylindrical coordinate system? Major questions include:

• How much more complicated is the math?
• Is the math smaller or more efficient?
• How annoying is the conversion from spherical to euclidean for display purposes?
• Could this tie in with a system that automatically calculates transmitter station coordinates as mentioned in #7?
• Could this tie in with a system that could keep track of a ship's pitch/yaw/rotation #4?
• How would it impact configurability?
• How would it impact interaction with modules?

The transmitters for IPS are currently hardcoded, but in the future we may want to change them or even make them dynamic. I need to figure out if this is possible with the mathematical method I used to calculate coordinates.

Fang's Method has specific requirements regarding the first 3 transmitter stations.

• First station must be [0, 0, 0].
• Second station must be on the x-axis [x, 0, 0].
• Third station must be [x, y, 0].

Because of this, we can't just easily swap out transmitter coordinates and have it work. The fourth transmitter station is the easiest to swap out since its coordinates are calculated based on the first three. But even then, the 4th station coordinate requires a selection between 2 possible coordinates.

Swapping the first station is the big problem since it functions as the origin point of the coordinate grid. If you get too far from the first station, then you need to define a new origin point. And by defining a new origin point, you need to define the x-axis all over again, and the second station, and the third, ect. Plus the whole grid changes initial rotation.

While it is possible to automatically do all of these calculations, it would require professional chips. We may get them before we get transmitters, in which case we could theoretically make this whole process automatic. But it would be an extensive system.

A better way may be to do the calculations external to the game and then define different origin points and constants related to them. Then you would flip between origin points dynamically and offset the resulting coordinates to fit the grid as a whole. But, that whole system will be much too large to exist in IPS by itself. It will need to be a separate module dedicated towards managing the origin point and current constants.

TODO:

• Learn when transmitters will be released in comparison to professional chips.
• Write up pseudocode for an origin management module.
• Go back and separate what parts of the math would need to be done per origin point to get the required constants.

Turns out the SSC grid rotation is all out of wack. Directions flown in the SSC do not line up with positions in real space. My theory is the transmitter stations in the SSC are not aligned the same way relative to the rest of the world as they are in real space.

This means my assumptions for directions in the SSC based on looking at the planet and belt are wrong.

Previously, I had assumed (based on the planet and belt positions) that these directions were correct:

• UP = +x (towards the belt)
• DOWN = -x
• LEFT = +y
• RIGHT = -y
• FORWARD = -z
• BACKWARD = +z

But then using the code in real space reveals that flying towards the belt is the -z axis direction, while still being correct in the SSC. That means the UP direction in the SSC is actually the -z direction, despite the world visuals indicating otherwise.

So, the grid rotation is 90 degrees off. Chances are the transmitter stations are 90 degrees off in the SSC world, which causes this bug. Since the +y axis seems to be correctly placed, that means the BACKWARD direction in the SSC world is my +x axis in real space.

I need to measure the BACKWARD directional vector in the SSC with no rotation applied and then recalculate the rotation constants.

Configuring the Waypoint Course Module is pretty bleh, especially when it comes to code edits required for specific numbers of waypoints.

I want to find a way to reduce the amount of code tweaking needed for the module to function correctly. I believe this can be achieved by abusing runtime errors when attempting to access non-existent global variables.

The goals are:

• Overall reduce the required code tweaking needed.
• Make the code work with any number of waypoints (2-16) without needing to delete or edit lines for it.