This page follows standard player exploration from survey equipment and queued destinations to geological knowledge, gravitational survey locations and the first transit into a connected system. It separates what a race knows from the bodies and jump links that every race shares. It covers ground geological surveys and geological probes. Full star system generation and the exploration behaviour of special races have their own pages. The move action rows of the game database as shipped define the survey orders, and the rules below describe how the game carries them out.

Knowing a system, surveying a body, charting a jump point and exploring its connection are separate changes of state. A geological survey reveals mineral deposits that already exist. A ground survey can change those shared deposits. Completing the gravitational survey of a system does not explore every jump connection.

Record Meaning
FCT_RaceSysSurvey row This race knows the system, with its own name, discovery time, map coordinates and survey summary flags.
FCT_SystemBodySurveys row A row for a race and body pair means that race has geologically surveyed that body. The row holds no copy of the deposits.
FCT_MineralDeposit rows The actual deposits every race shares, with Amount, Accessibility and the depletion baselines HalfOriginalAmount and OriginalAcc.
GroundMineralSurvey in FCT_SystemBody The shared ground survey potential of the body, or its completion. Stored as 0 Completed, 1 Minimal, 2 Low, 3 Good, 4 High and 5 Excellent.
FCT_RaceSurveyLocation rows The races that completed one gravitational survey location. The location itself, in FCT_SurveyLocation, is physical and shared.
FCT_RaceJumpPointSurvey row The race’s own Charted and Explored integers for one jump point, plus Hide, MilitaryRestricted, IgnoreForDistance and AlienUnits.
WPLink in FCT_JumpPoint The actual connection, stored as the ID of the linked point. It exists whether or not a particular race knows it.

Adding a body survey row is safe to repeat. The game adds the row only when the race and body pair has none. A jump point connection is set on both ends at once, as exploration and first transit describes.

When a race first learns of a system, the game records the current game date and time as Discovered and DiscoveredTime, and sets up the system name and the map scale (KmPerPixel). The name comes from a given name, from the known-star catalogue or from the naming theme, with “System #” and the system number as the last fallback. Sol is named Sol when no name is given. A system with no bodies starts with GeoSurveyDefaultDone set. Other systems do not become geologically known merely because their system record exists. A separate full-system survey step creates the body survey row for every body in the system. Without mineral generation it stops there. With mineral generation it also runs ground mineral generation on each body whose shared ground status is not Completed, then marks that body Completed. Race setup, imported knowledge and rewards use this step, and it reaches further than an ordinary orbital survey completion.

In fleet orbital work, the ComponentValue of a survey sensor is a rate in survey points per hour. Gravitational sensors are component type 6 (Survey - Gravitational) and geological sensors type 7 (Survey - Geological) in DIM_ComponentType. A ship’s capacity is the sum, over its sensor components, of undamaged component count x ComponentValue. Fleet survey work always applies bonuses, and for geological and gravitational sensors three adjustments follow. The capacity is multiplied by the ship’s effective survey commander multiplier. It is then multiplied by the ship’s CrewMorale. When the ship is undermanned, it is multiplied by CurrentCrew / class Crew. The commander adjustment needs an assigned ship commander and a capacity above zero. The calculation consumes no mineral stock and no probe ammunition.

The effective survey multiplier starts at 1. When the ship has an undamaged Science Department, an assigned science officer sets it to that officer’s full Survey bonus. When the ship has an assigned captain and a positive command and control capacity, the multiplier is then multiplied by 1 + (captain Survey bonus - 1) / 2, which is half the captain’s bonus. A ship whose class Size is 20 HS or less counts as having one Command and Control component when its actual capacity is zero. The ship capacity still needs a captain before it applies this multiplier, so a science officer alone gives no bonus in this case. The morale and crew reductions have their own conditions, and apply whenever the capacity is above zero. Commander experience covers how the Survey bonus grows.

The fleet capacity takes the fleet’s ships that have at least one undamaged component of the requested type, works out each ship’s capacity with bonuses, and adds them up one ship at a time. For geological and gravitational sensors, each undermanned ship then multiplies the entire running fleet total by that ship’s crew fraction. This comes on top of the ship’s own crew reduction and can reduce the contributions of ships counted earlier. The order in which the game visits the ships therefore matters. The fleet rate is not simply the sum of each ship’s crew-adjusted rate.

The working rate in survey points per hour is the fleet capacity, times the survey bonus of the fleet’s admin command for the current system, times (Survey Speed divided by 100). Survey Speed is an option of the Game Information window (SurveySpeed in FCT_Game, 100 is normal). Geological work recalculates this rate on every work step. Gravitational work calculates it only while the fleet’s stored gravitational rate is 0, then keeps using the stored rate once it is above 0. The fleet holds both stored rates, only the survey work sets them, and queuing a new order does not reset them. A change in crew, equipment, command bonus or Survey Speed therefore reaches the geological rate at once, while a gravitational rate already stored above 0 stays as it was. The fleet summary in the Naval Organization window works out its Geo Survey and Grav Survey figures separately, so that display does not show whether the stored gravitational rate was refreshed.

For sensor design sizes, technology ratings and geological probe payloads, see component design and probe design. Those design values are separate from the capacity of a damaged ship in play.

The DIM_MoveAction rows in the game database as shipped assign 9 Geological Survey to a system body with MoveRequirementID 6 (geological survey capability) and 12 Gravitational Survey to a survey location with MoveRequirementID 5 (gravitational survey capability). A fleet meets these requirements when a ship’s class has GeoSurvey or GravSurvey above 0 in FCT_ShipClass. The game does not recalculate the undamaged capacity in play for this. The order list and the work a fleet can actually do can therefore disagree after damage or crew losses. Queuing an order directly sets up its remaining work. The standing order target searches add further exclusions.

The geological target search looks at bodies in the given known system. It excludes fixed bodies (FixedBody), bodies this race has already surveyed, the race’s banned bodies in FCT_BannedBodies, and the destinations of queued geological survey orders of this race or of any race it holds a geological survey treaty with (GeoTreaty in FCT_AlienRace). The standing orders SV: Asteroid, SV: Moon, SV: Planet and SV: Planet or Moon (DIM_StandingOrders OrderID 1, 2, 3 and 9) filter by body class. SV: Body (OrderID 4) and the batch orders have no body-class filter here. The search picks the body with the shortest travel distance with Lagrange points, then requires that distance to be strictly less than the standing order distance limit. A body exactly at the limit fails.

The default limit is 10,000,000,000 km. A positive Maximum Geological Survey Radius set for the fleet in the Naval Organization window (MaxStandingOrderDistance in FCT_Fleet) replaces it. The game applies the larger limits of 12 and 15 billion km only in the NPR widening described next. When the first search of a geological batch order or of SV: Three Locations finds nothing for an NPR fleet, the game widens its limit from 10 to 12 billion km, or from 12 to 15 billion km. Player fleets get no automatic widening. When no candidate is left, or the nearest one fails the distance limit, SV: Body, SV: Five System Bodies and SV: Thirty System Bodies (OrderID 4, 13 and 49) set GeoSurveyDefaultDone on the race’s record for the system. This can mean that every remaining body is queued, banned, fixed or beyond the limit. It does not mean that every physical body has a body survey row. The body-class orders and SV: Three SB/Locations (OrderID 52) do not set that flag in this search.

The gravitational target search removes the locations this race has surveyed and the locations targeted by queued gravitational survey orders of this race or of any race it holds a gravitational survey treaty with (GravTreaty). It returns the nearest remaining location by travel distance with Lagrange points. It applies no distance limit. It returns no location at once when exactly 30 locations are surveyed. Neither search checks ship capacity.

SV: Five System Bodies and SV: Thirty System Bodies queue up to five or thirty bodies. After each choice the next search starts from the coordinates of the body just picked. Each queued order removes its target from the next search. SV: Three Locations (OrderID 14) works the same way for locations. SV: Three SB/Locations first finds the nearest candidate of each kind with the travel-distance searches, but then compares the two by straight-line distance. A tie goes to the geological body. Its final pick can therefore differ from the faster Lagrange route.

The intersystem standing orders MV: Geosurvey System and MV: Gravsurvey System (OrderID 6 and 10) treat a system as a destination while its GeoSurveyDefaultDone or SurveyDone flag is not set, and route over known explored connections. Those flags do not prove that a local target is available to this fleet. Route restrictions and transit capability are covered in movement routing.

Queuing a survey order stores the remaining work as SurveyPointsRequired on the order. Geological work starts at Radius / 10, with the body Radius in km and a minimum of 1. Gas giants and superjovians (BodyTypeID 4 and 5) use the radius divided by 100, with a minimum of 1. The division keeps decimals, and the resulting requirement is not rounded. Gravitational work starts at the whole-number JumpPointSurveyPoints of the system the order starts in. Both values are fixed when the order is queued.

Survey work runs after the approach movement and after any order delay has run out. For remaining sub-pulse seconds t and rate R, the work generated is W = R x t / 3600. When the remaining requirement P is greater than W, the order subtracts W and uses up the rest of the sub-pulse. Otherwise the order completes at once, including when P equals W, and passes t x (W - P) / W seconds on to further orders. That positive remainder is cut down to whole seconds, so fractional unused seconds are lost. The completed order’s remaining work is not set to zero. Only an incomplete pass reduces it. The move action catalogue lists the survey actions with the other orders.

At zero capacity with work left, W is 0, progress does not change and the pass is used up. The survey branches log no cancellation for zero capacity, unlike the salvage check. Salvage, by contrast, ends its order when the fleet has no salvage capability. The formula would also be undefined for a zero requirement with zero work. Normal body requirements are at least 1, and this should not be read as a protected zero-work timer.

Progress is per order. It is not pooled with other fleets or with the geological probe pool. Clearing or replacing the order discards its remaining work. Keeping an arrived order lets it resume. Copying an order copies its current SurveyPointsRequired. Cycling orders copies a completed order this way, so the copy carries the completed order’s leftover value. A survey completed by another race or fleet does not merge points partly built up. The automatic searches avoid duplicate queued destinations, but the survey work does not check again whether the body is already surveyed before completing. For order cancellation, timers and queue cycling see order lifecycle.

Orbital completion first makes sure the race has a body survey row, then reads the deposits that already exist on the body. It does not run ground mineral generation. When the body has deposits, the game logs a New Mineral Deposit event (event names are rows of DIM_EventType) (“discovered minerals on” the body, with a deposit summary), adds “Minerals discovered on” the body to the fleet history and records the measurement Bodies With Minerals Discovered. A d20 roll of 10 then awards survey discovery experience to the fleet’s ships. A body without deposits still becomes surveyed.

A ruin is reported when the body’s RuinID is above 0 and its AbandonedFactories is above 0, with a Ruins Located event, the measurement Ruins Discovered and a ship history entry. These reports do not depend on whether minerals exist. A ground mineral survey status other than Completed produces a Ground Survey Potential event that names the potential, and refreshes the ground survey site list of any open tactical map. Completion then shares the result with geological treaty partners and completes the order. Neither a ruin discovery nor a construct discovery starts ground xenoarchaeology, identifies the ruin civilisation or activates the construct. Salvage and archaeology describes those later operations.

Mineral quantity and accessibility belong to the body, and no race keeps its own geological copy. A race that has surveyed the body sees its current deposits, for example in the mineral ring of the tactical map. Later mining depletion and ground survey discoveries change that shared source. See production mining for extraction, exhaustion and the role of HalfOriginalAmount and OriginalAcc.

The ground survey step takes every ground formation with daily geological survey points above 0 that is assigned to a population. The formation’s race must have surveyed the population’s body from orbit, and the body’s shared GroundMineralSurvey must not be Completed. No move order is needed. Progress builds up in the population’s ground survey pool (GroundGeoSurvey in FCT_Population), so formations assigned to the same population add to one pool in turn. Populations on the same body keep separate pools. Once one completion marks the shared body Completed, later formations skip it.

Daily survey points are the sum, over the formation’s elements, of Units x sum of the Geosurvey values of the element class's components (DIM_GroundComponentType). When the formation has a commander, that total is multiplied by the commander’s effective ground survey bonus, described under own and parent bonus propagation. The formation’s daily points already include the commander bonus. The ground survey then applies the commander bonus a second time, together with elapsed seconds / 86400 and Survey Speed / 100. For base daily points B and commander bonus C, the work is B x C² x days x speed factor. This double application is how the game behaves, not an assumed intended rule. The completion threshold is the same radius-based geological requirement as orbital work. Reaching it exactly completes the survey, no unused time is returned, and the population’s pool is not reset at completion.

Completion logs a Geo Survey Complete event (“has completed a ground survey of” the body), runs ground mineral generation for the body and the surveying race, then always marks the body Completed. Even when mineral generation stops at its first chance roll, the ground survey opportunity is used up. The ground survey step makes no geological treaty sharing call. Races that already have a body survey row nevertheless see the same changed deposits.

For a ground survey, generation keeps the existing deposits. Let r be the body radius, at least 100, and A = (system AbundanceModifier + 4) / 4, doubled inside the life zone. Generation first needs a d10000 roll of at most whole-number(A x (Density x 10 + r / 100) x 100). For each mineral ID from 1 to 11, the next roll is a d10000 that must be strictly less than Density x A x 30 x 100, where 30 is the base ground survey chance. The chance is doubled for mineral 1 (Duranium). In a ground survey the ground potential then changes it. Minimal divides it by 4, Low by 3 and Good by 2, High leaves it unchanged and Excellent doubles it. A Completed status ends the mineral rolls.

A successful roll gives an amount of (d100 / 100 x r)², doubled for Duranium. Accessibility starts from b = 1 - r / 2000 (Duranium 1 - r / 4000) and becomes b + d100 x (1 - b) / 100, rounded to one decimal place, where an exact half goes to the even neighbour. In a ground survey, Excellent potential adds 0.2 and High adds 0.1, then the result is held between 0.1 and 1. An existing deposit takes the generated amount and the generated accessibility separately, each only when it is higher. The generated amount replaces the current amount and is not added to it. The existing HalfOriginalAmount and OriginalAcc stay unchanged. A new deposit sets HalfOriginalAmount to half its generated amount and OriginalAcc to its generated accessibility. This difference matters for later depletion. Each new deposit, amount increase and accessibility increase is reported in an event.

Initial ground potential, set when minerals are generated without a surveying race, marks bodies with a radius below 2500 km Completed. Otherwise a d100 gives Completed on 1 to 80, Low on 81 to 90, Good on 91 to 96, High on 97 to 99 and Excellent on 100. This roll has no Minimal outcome. It runs after the mineral rolls, and a failed first chance roll ends generation before it runs. Initial minerals and ground potential covers the system creation side.

The probe step takes every missile salvo whose missile type has Geostrength above 0 in FCT_MissileType. It finds the first body in the same actual system whose coordinates differ from the salvo’s by less than 1 km in X and less than 1 km in Y, a square tolerance rather than a radial one. It needs no separate target order and no orbital knowledge. Points go into a probe survey pool kept for each body and race pair (FCT_MissileGeoSurvey), so several surviving salvos of that race at that body add to the same pool. Points generated are Geostrength x current missile count x elapsed seconds / 3600 x Survey Speed / 100, using the current missile count. No ship commander, admin command, morale or crew modifier applies.

When the pool reaches the body requirement, the game gives the race a body survey row, removes the pool and the completing salvo, and reports existing minerals, ruins, constructs and ground potential. It does not generate ground deposits. It does not run the treaty sharing, measurements or experience awards of fleet completion. The completion does not remove every salvo that contributed. Each salvo is handled on its own from the salvos present when the step began. The completing salvo’s missiles are all used up together, even when their accumulated work overshot the requirement.

Already-surveyed quirk. A salvo at a body its race has already surveyed is removed, but the handling of that salvo goes on. The same salvo can still create or add to a probe pool and reach completion and reporting. Removal is therefore no guard against further work in the current pass, and a leftover pool can be created although the race already has orbital knowledge of the body. Moving away or losing a salvo does not itself clear that separate body and race pool in this step, and the pool is saved with the game.

Ordinary systems have 30 gravitational survey locations in three rings around the coordinate origin (0, 0). Locations 1 to 6 sit at bearings 0, 60, 120, 180, 240 and 300 degrees. Locations 7 to 18 sit at 15, 45, 75 and onward in steps of 30 up to 345 degrees. Locations 19 to 30 sit at 0, 30, 60 and onward in steps of 30 up to 330 degrees. The base radii are 2, 4 and 6 billion km, multiplied by the system scale S. S is the square root of the primary mass when that mass is at most 1 solar mass, and the cube root of the mass otherwise. JumpPointSurveyPoints is 400 x S, cut down to a whole number. Recalculating the locations for the primary star changes their positions and the system requirement, but not the work already fixed in queued orders.

Finishing one location records the race on it (once only), rolls a d20 and awards survey discovery experience on a 10, charts jump points from the location, tries to complete the full gravitational survey, shares the location through treaties and completes the order. A successful charting adds “Jump Point discovered in” the system to the fleet history. The full survey needs exactly 30 locations that record this race. It sets SurveyDone and logs a System Surveyed event (“Gravitational survey completed in” the system). It does not need any jump point to have been found. A separate full gravitational survey step, used by other routes, records the race on every location, charts from each one and sets SurveyDone directly.

Charting checks each physical jump point in the system. For each point it keeps only the locations strictly farther from the origin than the jump point, comparing squared distances, then takes the nearest of those locations to the point by squared straight-line distance. Only that one location can chart the point. This is neither a radius around the surveying ship nor the nearest location without the outward condition. The race must already have a jump point survey row for the point with Charted 0. Success changes Charted to 1. It does not set Explored or resolve a destination. One location may chart several jump points, and many locations chart none.

The game assumes that a location farther out than the jump point exists. It does not fall back to the outermost ring. When a jump point lies outside every location, charting fails with error Function #2568 and the charting step ends there, so the remaining jump points of the system go unchecked for that location. The rest of the location completion carries on. A local discovery by a fleet records the measurement Jump Points Discovered, adds ship history and logs a Jump Point Detected event (“discovered a new jump point in” the system). Charting from shared survey data charts the same way but does not count as a local discovery. Its event reads “New jump point detected in” the system “as a result of survey data provided by” a race name. The game takes that name from the source race’s own list of known races, looking for an entry that is the source race itself, so the event is not guaranteed to name the source race.

Charted means the race knows where the point is. Charted 1 with Explored 0 is a separate condition of its own. Explored means the race knows the connection. The physical link (WPLink) may already exist because another race went through it. The game gives a race the far end’s position only when the physical link exists and that race has Explored 1. Jump point stabilisation and gates and the gravitational SurveyDone are separate again.

A jump transit first checks drive, gate and shock requirements and runs the departure sensor checks. When the order has no resolved destination system yet, the game completes the jump point exploration before it moves the fleet. Only a successful transit reaches this point. Exploration is therefore an information and link step inside the transit, not a gravitational work timer and not a requirement to survey all 30 locations. See movement jump modes for drive coverage, shock, scatter and failure.

Exploration reuses the system of an already linked point. For an unlinked point it picks an eligible existing system or generates a system, subject to the Known Star Systems option (UseKnownStars in FCT_Game), forbidden destinations and the last-unlinked-point protection. The protection applies when the departing point is the only unlinked jump point in all the systems the race knows, and a generated destination then gets at least 2 jump points. In known-star mode the optional existing-system attempt needs a d15 roll of 10, more than ten systems in the game and the protection off. In procedural mode the game makes up to twenty system-number picks in total, continuing after a pick only while the protection is on and the rolled number already belongs to an existing system. When no destination results, the game generates one, as an NPR system for an NPR explorer and as a player system otherwise. Connection selection on first exploration and star system generation cover those rules.

When a newly created race is waiting for its starting exploration, an extra step runs. It completes that race’s gravitational and geological surveys of the first chosen destination, with ground mineral generation, generates its starting exploration and colonies, then picks a replacement destination from the systems it has explored. The final link can therefore lead to a different system from the first choice. Redirect after a new race appears gives the details.

At the destination, a single unlinked jump point is used directly. With none, a new point is created. With several, one is picked at random. Both ends receive the link and each other’s ID in WPLink. A newly created physical point gets uncharted and unexplored rows for every race that already knows its system.

When the race does not know the destination system, the game creates its jump point survey rows for every point there, marks the arrival point Charted 1 and Explored 1, creates and names the new system record and places it on the galactic map relative to the origin system. It logs a New System Discovered event (“has discovered the new system of” the name). When the race already knows the destination, the game marks the arrival point charted and explored and logs a New System Discovered event that reads “has discovered a new connection to the known system of” the name. In both cases the departure point becomes Explored 1, and the order stores the destination system and arrival point (NewSystemID and NewWarpPointID in FCT_MoveOrders). The same destination is copied to the queued orders of other fleets of the race that target the same departure point and have no destination yet. These normal discovery paths run no geological survey of any body.

Only a genuinely new system discovered by a fleet earns the measurement Star Systems Discovered and a ship history entry in this step. The game then works out the colony cost of each destination body with an atmosphere for the race’s primary species, and records Habitable World Discovered for the bodies whose current colony cost is 0. A new route to an already known system gets none of these awards. The transit then moves the fleet, sets its entry jump point and timestamps, runs the arrival checks and shock, and completes the order. System discovery timestamps, explored flags and physical arrival records are therefore set by different steps. The medal conditions that use these measurements have their own page.

Geological treaty sharing goes through the discoverer’s known races that hold a geological survey treaty (GeoTreaty). The partner must already know the system and must not already have a body survey row. The game then gives the partner a row, even for a body without minerals. The partner receives its Geological Survey Data, Ruins Located events only when the body has deposits, unlike the local fleet discovery, which reports ruins either way. What the partner is told and the wording of its events can therefore differ. Sharing gives the partner access to the body’s deposits, not a copy of them. Treaties covers how the treaty flags are set.

Gravitational treaty sharing likewise needs the partner to know the system already and to lack the surveyed location. The game records the partner on the location, charts jump points for the partner from that location and tries the partner’s full survey completion. It does not explore those connections or give the partner an unknown system in this step. Queued-target exclusion uses the source race’s current treaty flags, not an assumption that alliances are symmetric.

Importing a system survey from another race returns an existing system record unchanged. For an unknown system it creates a record with the source race’s name for the system and builds a jump point row for each physical point from the source race’s Charted and Explored values, or 0 and 0 when the source has no row. A row becomes Explored 1 only when the linked far point already has a row for the importing race, and that far row is then marked explored too. This is a conditional rebuild, not a straight copy of the values, and it imports no geological or location knowledge. Intelligence rewards can separately grant a full geological or gravitational survey of a system the race already knows. The geological reward picks a system the source race has fully surveyed and the recipient has not, with at least one body that is not a comet, and adds the body survey rows without mineral generation. The gravitational reward picks a system with SurveyDone set for the source and not for the recipient, and completes the full gravitational survey there. See intelligence rewards.

Saved state Stored in
Physical survey location ID, system, location number and coordinates, and race and location records FCT_SurveyLocation (SurveyLocationID, SystemID, LocationNumber, Xcor, Ycor) and FCT_RaceSurveyLocation (RaceID, SystemID, LocationNumber).
Race and body geological survey rows FCT_SystemBodySurveys. A routine save adds only the rows created since the last save. A forced full save deletes and rewrites them all.
Probe geological pool, with body ID, race ID and accumulated points FCT_MissileGeoSurvey (SystemBodyID, RaceID, SurveyPoints).
Race system name, discovery and map state, SurveyDone and GeoSurveyDefaultDone FCT_RaceSysSurvey.
Race jump point Charted and Explored, and the restriction and display flags FCT_RaceJumpPointSurvey.
Move order Arrived and remaining SurveyPointsRequired FCT_MoveOrders.
Shared ground survey status and the population ground survey pool GroundMineralSurvey in FCT_SystemBody and GroundGeoSurvey in FCT_Population.

The saved order remainder lets partial survey work resume after loading. The fleet’s stored survey rates are not saved, and FCT_Fleet has no column for them. Body mineral amounts, original accessibility and half-original amount are saved as physical deposit data in FCT_MineralDeposit, not as part of any race’s geological survey. See movement persistence and production.

When the galactic map is prepared, the game clears each known system’s lists of charted and explored jump points, rebuilds them from the race’s jump point rows, and recalculates the pending ground survey flag from bodies the race has surveyed whose shared ground status is not Completed. These are display caches. The system summary’s stored surveyed percentage is the race’s surveyed body count divided by the body count, times 100, rounded, an exact half going to the even neighbour, and a system with no bodies shows 100%. The direct survey labels in the System Generation and Display window instead round an exact half up. A separate completeness check, used by the geological intelligence reward, compares the race’s body survey rows with every physical body in the system. GeoSurveyDefaultDone is the working flag of the target search and may differ from both.

Survey location markers on the tactical map, labelled “SL” and the location number, are filled for locations the race has surveyed and hollow otherwise. The Hide Surveyed Locations option hides the surveyed ones. A filled marker shows completed location knowledge. It is not a charted or explored jump point marker. A fleet’s location description checks its current coordinates and its current order to say “Surveying” and the target. That text does not mean the fleet has a work rate above zero.

These are calculations from the formulas above, not recorded game observations.

Inputs Result
Ordinary body of radius 6371 km, working orbital rate 12 points per hour Requirement 637.1 points. Uninterrupted work needs 53.091666… hours, travel and delay not included. A gas giant of radius 63710 km has the same requirement.
Remaining P = 5, R = 12 per hour, t = 1800 seconds W = 6. Completion passes 300 seconds to later work. P = 6 completes too, passing 0 seconds.
P = 1, R = 7 per hour, t = 600 W = 7/6. Unused time is 85.714… seconds, cut down to 85.
Ship A contributes 10. Ship B has base 10 and half crew. Morale and commander are 1 Ship B contributes 5, then the fleet total is (10 + 5) x 0.5 = 7.5. Visiting B first gives 5 x 0.5 + 10 = 12.5.
Ground base B = 10 per day, commander C = 1.2, speed 100%, one day The formation’s daily points are 12, and the ground survey step adds 14.4 points. With a 10-point threshold the survey completes on this pass and the excess is not refunded.
Two probe missiles, Geostrength 0.5, speed 100%, one day at the body The shared body and race pool gains 24 points. After one missile is lost, the same duration adds 12.
Primary mass 0.25, or mass 8 S = 0.5 or 2. That gives 200 or 800 points per location, and ring radii of 0.5 or 2 times their base radii.
Existing amount 1000, generated amount 1500, old HalfOriginalAmount 500 The current amount becomes 1500, not 2500. HalfOriginalAmount stays 500. A lower generated accessibility leaves the old current accessibility in place.
Nearest eligible geological body lies exactly at the distance limit It is rejected. SV: Body or a geological batch order can set GeoSurveyDefaultDone although this body remains physically unsurveyed.
One location charts three jump points, with 29 of 30 locations complete Three points become Charted. None becomes Explored by charting, and SurveyDone stays unset until the thirtieth location records the race.

Related community documentation and developer posts. These may describe a different game version.