User:RA2lover/Sandbox/Satellite Dish Automation

• No information on signal strength is provided until a signal is resolved.
• No info on resolution progress is provided in a way accessible to logic automation. This is likely because resolution progress rate could be used to estimate contact angle indirectly resulting in resolution exploits.
• Once resolution is complete, the signal strength value is updated from -1 to the angle between the dish and its contact in degrees. Unlike pre-terrain-update guides, lower signal strength values after resolution result in faster resolution times.
• Contact celestial positions can be triangulated by taking scans from different orientations:
  • 1 resolution constrains the target's position at a given timeframe to a spherical circle in the sky.
  • 2 resolutions from different orientations constrain the target's position to 2 points in the sky (assuming the circles from both resolutions intersect).
  • 3 resolutions from different orientations constrain the target's position to a point in the sky (assuming resolution orientations are not coplanar).

Math can be used to track down those points. Our goal is to calculate the celestial angles at which the circumferences intersect, and point the dish at them. Even though the contact moves, as the error gets smaller resolutions can be made faster.

1 resolution tracking

With 1 resolution, the contact is constrained to a plane normal to our celestial reference point. This can be thought as a unit-hypotenuse right-angled triangle where the hypotenuse goes between our celestial reference point and the contact, the side adjacent to the celestial reference point is offset at an angle equal to our signal strength angle, has a length of cos(said angle), and the opposite side has a length of sin(said angle).

Once the resolution is complete, we know how far the dish is from the contact, but we do not know which direction to point the dish towards. The next step in triangulation is to point the dish into a random direction and pray we've pointed it closer, which may not always be the case.

2 resolution tracking

With 2 resolutions from different directions, the contact is constrained to 2 planes, whose intersection results in a line. The intersection of this line with the celestial circle results in 2 possible points that the target may be in. Which of these still has to be picked at random, however - with the special exception of one of the points being below the horizon and discardable by virtue of being unpointable.

3 resolution tracking

With 3 resolutions from different directions, the contact would be constrained to 3 lines resulting from 3 different 2-resolution tracking systems. This can be converted into a point by solving a least-squares problem, but an approximation reusing existing code for the 2 resolution tracking problem can be made by picking one of the two potential points from the 2 latest resolutions and using the first resolution to ignore the least-likely point.

Medium Satellite Dish Stack Operations

On every logic tick:

• Sweep the entire stack memory, erasing stack addresses which contain a TraderBuyThingData or TraderSellThingData opcode.
• Initialize LastWriteAddress to $0.
• Sweep the entire stack memory, looking for the following instructions and executing them: WriteTraderData, WriteTraderBuyData, WriteTraderSellData.
• After execution of each instruction, set LastWriteAddress to the instruction's address.

Medium Satellite Dish Stack Instructions

WriteTraderData (1)

• Read WRITE_INDEX byte.
• Get strongest contact.
• Write StrongestContactIdHash to WRITE_INDEX
• Write StrongestContactMetadata to WRITE_INDEX+1.
• Write StrongestContactSignalData to WRITE_INDEX+2.

WriteTraderBuyData (5)

• Try getting the strongest contact. If it can't be found, finish instruction without writing anything.
• Read WRITE_INDEX and WRITE_COUNT bytes.
• check if WRITE_INDEX is past the stack memory and finish instruction early if so.
• For each Trader Buy Data instance:
  • Get the item corresponding to that Trader Buy Data.
  • If trader wants at least 1,
  • For Thing trades:
    • Check if the item being traded meets filters:
      • look for FilterPrefabHashEquals, FilterPrefabHashNotEquals, FilterSortingClassCompare and FilterQuantityCompare modifiers from LastWrite+1 up to the end of the stack or the first write instruction it finds (which may not be the same as the executing instruction if the instruction is being executed from address 0 or if the instruction has been overwritten during execution). If any filter criteria evaluate to false, skip to the next item.
      • Write TradeBuyThingData For the Thing being traded.
      • For each child item:
        • Check for PrefabHashEquals, PrefabHashNotEquals using the same filtering rules as above. If none are invalid, write TraderBuyThingChildData for the child item.
          • Note that executable instructions may have been overwritten by previous writes.
        • If outside the write range for the instruction, finish instruction early.
  • For Gas trades:
    • Look for FilterGasContains and FilterGasNotContains instructions from LastWrite+1 up to the end of the stack or the first write instruction it finds (keep in mind write instructions can be overwritten during execution).
      • If no filter rules evaluate to false, write TraderBuyGasData for the corresponding gas.
      • Note FilterQuantityCompare does not filter out gas trades. This may be a bug.
  • Check if past the write range for the instruction, finishing it early if so.

WriteTraderSellData (6)

• Try getting the strongest contact. If it can't be found, finish instruction without writing anything.
• Read WRITE_INDEX and WRITE_COUNT bytes.
• check if WRITE_INDEX is past the stack memory and finish instruction early if so.
• For each Trader Sell Data instance:
  • Get the item corresponding to that Trader Sell Data.
  • If trader offers at least 1,
  • For Thing trades:
    • Check if the item being traded meets filters:
      • look for FilterPrefabHashEquals, FilterPrefabHashNotEquals, FilterSortingClassCompare and FilterQuantityCompare modifiers from LastWrite+1 up to the end of the stack or the first write instruction it finds (which may not be the same as the executing instruction if the instruction is being executed from address 0 or if the instruction has been overwritten during execution). If any filter criteria evaluate to false, skip to the next item.
      • Write TradeSellThingData For the Thing being traded.
      • For each child item:
        • Check for PrefabHashEquals, PrefabHashNotEquals, FilterSortingClassCompare and FIlterQuantityCompare using the same filtering rules as above. If none are invalid, write TraderSellThingChildData for the child item.
          • Note that executable instructions may have been overwritten by previous writes.
          • Note the criteria for children are interpreted differently than WriteTraderBuyData. This may be a bug.
        • If outside the write range for the instruction, finish instruction early.
  • For Gas trades:
    • Look for FilterGasContains and FilterGasNotContains instructions from LastWrite+1 up to the end of the stack or the first write instruction it finds (keep in mind write instructions can be overwritten during execution).
      • If no filter rules evaluate to false, write TraderSellGasData for the corresponding gas.
      • Note FilterQuantityCompare does not filter out gas trades. This may be a bug.
  • Check if past the write range for the instruction, finishing it early if so.

Medium Satellite Dish Stack data

TRADER_ID_HASH

Trader ID	Hash value	Trader Slot Type
OreTrader	-1374574351	Basic, Medium, Large
AlloyTrader	54412100	Basic, Medium, Large
HydroponicsTrader	-1077922067	Basic, Medium
GasTrader	-470575659	Basic, Medium, Large
Construction Trader(space is included)	175935584	Basic, Medium, Large
LiquidTrader	135244511	Medium, Large
FoodTrader	-82964957	Utility
HardwareTrader	1325142661	Utility
ConsumablesTrader	-1650376125	Utility
MedicalTrader	-1012213572	Utility
ApplianceTrader	-1590718013	Utility
GeneticsTrader	-188927486	Exotics
RareItemsTrader	649254485	Exotics

SHUTTLE_TYPE

Shuttle Type	ID	Size	Runway Length
None	0	3x3
Small	1	3x3
SmallGas	2	3x3
Medium	3	5x5
MediumGas	4	5x5
Large	5	6x6
LargeGas	6	6x6
MediumPlane	7	7x7	15
LargePlane	8	9x9	20

Gas traders always use SmallGas/MediumGas/LargeGas.

Landing Pad Connectors

Liquid I/O connectors move liquid by volume at Setting L / tick, behaving like volume pumps.

Gas I/O connectors move gas by volume (Setting L / tick), but have a minimum movement rate equal to Setting mol/tick making them faster than volume pumps at low pressures (starting from ~2400 kPa at room temperature).

Gas I/O Connector Setting defaults to 50 and can be adjusted from 0-50.

Liquid I/O Connector Setting defaults to 9 L/tick and can be adjusted from 0-10L / tick.

Landing Pad I/O connector pressure/temperature/ratio data performs reads on the landing pad network, not the I/O network, requiring either a separate sensor or limited network pressure/temperature for fine input rate adjustments.

Gas/Liquid Tank connector setting is hardcoded at 20 (L|Mol) / tick and 5 L / tick, respectively.