• Previous Design Documents
• TornStars UnstableSpace

/Simple Rebalance   /TornStars MetaGame   /TornStars UnstableSpace

Torn Stars: Unstable Space

This document attempts to describe the Unstable Space feature set, as currently implemented. Not as designed. Or not as desired.

The status key is

• uncoded the feature was only started in code.
• coded the feature is mostly done pending small design changes.
• tested the feature is finished and tried, but has not been tested by others.
• done the feature was tested by multiple people and found to be finished.

Replacement Capsule Jump

coded This module is mostly coded, but has frame rate issues for some players and is not as exciting to fly as we wanted. More play testing is needed to make sure we have caught all the bugs. Then the jump simulations parameters need to be tuned up slightly.

The capsule jump replaces the standard games system to system jump feature. The purpose was to replace the rather dull cargo pod hauling with a more exciting tunnel racing experience. Another purpose was to create hidden and high difficulty jumps so that scout, smuggler, and miner players would have areas to explore.

Each route from lpoint to lpoint has a difficulty value attached to it. That difficulty value represents the instability of the route. There are 5 levels of stability.

• Stable
• Weak
• Unstable
• Dangerous
• Deadly

Standard commercial shipping will only cross the Stable routes. These routes are on all navigation computers and everyone knows where they are and how they connect to one another.

If an lpoint has a Stable Route, then it will be visible in Navigation Comp. If an lpoint has only Weak or worse routes, then it will be hidden on the map and the player will need to find it using the Lpoint Scanner GUI feature. Once an lpoint has been found, it will always be visible in the Navigation GUI. The navigation GUI will display the known routes out from an Lpoint.

There are 5 levels of active sensors. The basic sensors can only detect Stable jump routes. Each level of sensor upgrade allows the player to see the weaker jump routes. The destination of the weaker jump routes is never shown until the player completes one jump.

If a player has the sensors to see the less stable routes, he can attempt the jump. There are two levels of capsule drive, Commercial and Military. A commercial drive can only cross Stable routes without damage. Any levels above Stable will cause a percent damage to the ships hull Deadly almost always destroys ships with commercial drives. Military drives can cross Unstable level routes and below with no damage.

All the standard game jump routes between system are removed. There is no system to system jump routes using the standard game capsule jump. The new jump system is the only way to travel from system to system.

Navigation Tab Menu

The player begins a jump by pressing the TAB key when near an Lpoint. A conversation menu with Lori the navigator appears. If the player ship has good enough sensors to detect the routes away from this lpoint then a menu item for that route is displayed. If the player has never taken the jump route before, and the route is not a stable (commercial) route, then the destination system will be displayed as "Unknown". The player can select a route or cancel. If the player selects a route, then Lorie "plots a course".

Once a route is selected, a task is started that causes the Lpoint to blink on and off. It also watches the player ship. If the player ship moves to within 500m while traveling greater than 100m/s then the player will jump. If the player leaves the area, the task will exit and the player will need to plot the course again.

The player will fail to jump, if the player lacks the fuel to jump, or any wingmen lack the fuel to jump. This is to prevent accidentally leaving a wingman behind.

Fuel usage is deducted from all ships at the start of jump. If the player fails to jump correctly, the fuel is still used up.

Jump Simulation

MS_Mod_Main/jump_controls.ini

A special star system called "capsule space" was created to house the jump simulation. The system is empty except for the center. By placing the player in this special system, all ships in the prior system are properly culled.

The player ship and all player wingmen are placed in the capsule space system at the moment of jump. The player wingmen are placed a long ways away from the player and the ships are disabled so they stop moving.

The player is moved into a special capsule jump ship. This ship has properties setup for flying in capsule space. The players capsule drive determines the exact ship that is selected. Better capsule drives put the player into capsule ships with better properties. The players old ship is disabled until the player finishes flying the simulation.

Tunnel Building

The race tracks are assembled from modular tunnel pieces. There is one track for each difficulty level. The layout of the tracks is determined by MS_Mod_Main/jump_controls.ini

[Stable]
time=100
;time=70
velocity=1000
section[0]="ini:/sims/ships/jumptube_entrance"
section[1]="ini:/sims/ships/jumptube_straight"
section[2]="ini:/sims/ships/jumptube_straight"
section[3]="ini:/sims/ships/jumptube_straight"
section[4]="ini:/sims/ships/jumptube_exit"

Each jump tube section can have objects placed at specific locations inside of it to act as obstacles or decoration. One current issue is that moving objects are found to have a large impact on frame rates.

[Lights]
speed=50
model[0]="ini:/sims/ships/bubble"
location[0]=(808.118 705 -1416.499)
model[1]="ini:/sims/ships/bubble"
location[1]=(526.0281 -4.721048 -4803.496)
model[2]="ini:/sims/ships/bubble"
location[2]=(425.432 -1232.138 3415.47)

Racing

The player capsule ship is placed at the start location with an initial velocity. A countdown timer representing the fading energy of the players jump capsule is started.

The player must travel through the jump tunnels and reach the end of the race course before the timer expires.

The player ship is invulnerable, but if it suffers more than 50% damage in a collision, the race is ended as a failure.

Exiting Jump

Once the simulation ends, the player is placed back in their normal ship. The normal ship is moved out of the capsule space system and placed depending on how well the player did.

If the player flew the whole course, the player ship exits from the destination lpoint normally with no damage.

If the player few half the course and then crashed or ran out of time, they are placed at the destination, but with damage. Damage is calculated based on the difference between the ships capsule drive and the difficulty of the route.

If the player failed to fly half the course before crashing or running out of time, the player is placed 1000km from the start Lpoint, and is damaged.

If the player has wingmen, the wingmen will exit into space at the same location as the player. If the player sustained damage, the wingmen will also be damaged.

Geography and File Changes

source/windows/jump_cluster/jump_cluster.cpp (a visual studio project exists here to build the application). source/windows/geog/geog.cpp (a visual studio project) source/windows/readmap/readmap.cpp (visual studio project)

The Middle States cluster is generated from a large spread sheet file using a custom written program named save_type.exe.

A new version of save_type.exe called jump_cluster.exe has been written. This new version does not write lpoint links into the standard geography. Instead it puts in them into the system_name.ini files where only our new jump system can find them. These files already exist to hold critical station information.

A new syntax has been defined for specifying lpoint routes in the spread sheet. It is:

Lpoint, name, planet, moon, # of links, destination system, destination lpoint, jump difficulty, period of stability, period offset.

[this pattern repeats for each route out of the lpoint]

The difficulty of jump is any number from 1 to 5.

Period and offset are specified in the file but not used.

It should be noted that all routes are specified one way. You must specify a second route back, if you want a two way link. This allows one way jumps. Or jumps that have different difficulty levels each way.

james >> 3-Oct-07 Jon can you include references to where these files reside within the repo?

Lpoint Finder

tELpointFind.pog

If an Lpoint has no Stable routes then it will not show up on the standard Navigation charts. The player will need to find these routes himself.

This task is done using the Lpoint Scanner GUI. The scanner uses astronomical data to predict the possible locations of lpoints. Each moon can support 1 lpoint. The player selects a moon, and the GUI places a waypoint at the possible search location.

The player then flys to the location and scans for an Lpoint. If the Lpoint exists, it will be entered into the players navigation charts for future use.

Systems with dozens of moons could provide hours of searching, even without attempting any of the jump routes.

Design Note: Why do this GUI rather than put in an Lpoint for every moon? The reason is resources. The lpoints are much like stations. They always exist and must always be tracked, searched, and generate traffic, ect. It is much easier on the system to only support the few lpoints that really exist than to put in dozens. So instead this GUI allows the best of both worlds. The player gets to explore every nook, and the game uses resources efficiently.

Jump Menu

tEJump.pog

The jump menu is used to start a new jump. It displays the routes that can be seen by the player and the destination of routes that are already known.

Jump Capsules

The player ship is replaced with a jump capsule that represents the player ship. There needs to be one jump capsule for each level of capsule drive (so a minimum of two).

Capsule drives

The standard EoC game has two kinds of capsule drives, commercial and military. This mod recognizes which one is mounted on each jumping ship and calculates damage accordingly. Using the standard capsule drives means that we don’t have to make any changes to the game at all. We just need to provide places for the player to purchase the better drive.

Sensors

The standard EoC game has 5 kinds of active sensors. This mod will recognize which kind is mounted on the player ship and turn that into a detection level from 1 to 5. This matches the stability levels of the jump routes. Using the standard sensors means that we don’t have to make any changes to the game. We just need to provide places for the player to purchase the better sensors.

Fuel Handling

Another major feature of the mod will be real fuel usage by player ships and wingmen. Right now the game just charges credits for each capsule jump. This release will require ships to refuel. All player ships will use fuel for daily upkeep and capsule jumping. A ship that runs out of fuel will stop moving.

Player ships can refuel at stations using a new "pog object" tanker. The player uses the ship to ship communication system to hire the tanker to refuel his ships.

Also supported is a new tanker class of wingman. The tanker can refuel other player ships. And the tanker can drain fuel from fuel cargo pods.

These features work together with the capsule jump features to make exploration of deep space (far from any fueling station) a more interesting and challenging task than any prior space simulation. I think people will enjoy it.

Fuel Capacity and Usage

Ship INI files have a new value attached for the amount of fuel they can carry.

Fuel is used by capsule jumps and daily fuel usage (maneuvering jets consume a fair amount of reaction mass). Both of these values will also be placed into the ships INI file. Default values based on class will be used if the values are missing.

Capsule jump fuel usage is charged when a ship attempts capsule jump. If there is not enough fuel, the ship fails to jump.

Daily fuel usage is charged at end of day at the same time as upkeep fees are paid.

If a ship runs out of fuel, it halts and then cannot move. A message is sent to the player announcing the condition. If fuel is transferred to the ship, it will restart its reactor and become a normal wingman again. Upkeep will still be charged on ships without fuel.

Refueling

Ships can be refueled by tanker ships that are found around waystations, ship yards, police bases, pirate bases, and navy depots.

Using the comm channel you can hire the tanker ship to refuel one of your ships or your whole fleet. Fees are charged based on the amount of fuel transferred. If you don’t have enough money, fueling will stop.

Fuel Tanker Wingmen

A fuel tanker wingman can be hired. The tanker has specialized pumps and other equipment needed to refuel other ships while floating in space. Tanker wingmen typically have very large fuel tanks. Any ship with the “tanker=1” value in its ship template file can refuel other ships. This allows any type of ship to be a tender (such as a fleet carrier or large freighter).

The fuel tanker wingman will accept commands to refuel other ships in the player fleet. The fuel tanker commands will be “refuel targeted wingman”, “refuel targeted ship” and “refuel all wingmen” (A mission might be to rescue a ship with ruptured fuel tanks).

The fuel tanker wingman will withhold a minimum fuel of 2 capsule jumps worth in its tanks (to keep from accidentally disabling itself).

The fuel tanker wingman refuels at stations like any other ship. (it just holds a very large amount of fuel).

A fuel tanker wingman can pull fuel out of fuel cargo pods. A command “draw fuel” with a fuel cargo pod as a target will cause the wingman to refuel from the pod. The pod will convert to an “Empty” when fueling is done. Standard ships lack the specialized pumps needed to do this operation. It also works on ship wrecks (ships that have a special wreck marker).

Fuel tanker wingmen are especially useful on combat raids into enemy territory and long duration scout missions. Scout class freighters are equipped as tankers to allow them to haul extra fuel pods, which they can use to extend the number of jumps they can perform.

News Periodicals

The idea is to create some static prewritten HTML news articles that are sent to the player once a week, or once a month. These would simulate weekly news papers or magazines. For the first time, the player will have a solid feeling of time passing. What it means to be a long haul freighter pilot who spends months in capsule space. (Two 15 jump runs will pass a whole month of game time).

These Periodicals are how we will communicate the current state of events in the cluster to our players. They will not change with player actions or trigger off of events. These will start very simple.

We need to invent some periodicals, and their political orientation, and general coverage.

Ideas to spark off other ideas "Cluster Geographic" that does in depth reports on cultures and history of the cluster. "Military Historian" that reports on major conflicts of the past. The periodical "Long Hauler" that caters toward system to system freight haulers.

What do we want to say? Who do we want to say it? Can we entice our player to move around the cluster? This feature is based around the already coded NewsNet software (written years back, but never used, until now).

NewsNet will be enhanced with a “Release Day” feature. This allows the news writer to specify the game day that a news item is released to the player. A whole year of news can be specified in advance.

We need someone to take the lead on this feature. Gather ideas for periodicals and scour the background documents for story ideas.

I think we should have the news start 1 year back, and work up the current state of the cluster. Essentially, if a player plays this next release and reads all the news, then they should know the current state of events. Then if we spring changes on them in a future release they can say “yep, I knew that war was going to happen. I saw that coming.” Because of these small staged releases, we essentially get to write a little prolog for a future novel.

Asteroid Mining

This feature allows the player to own a station. The first station is an asteroid. It will have several docking points.

The player can hire mining rigs. These mining rigs can be used to harvest resources from the asteroid station The rigs have no LDS or Capsule drive. They must be towed into position and then ordered to dock to the asteroid. One rig can dock to each docking point on the asteroid.

As long as the rig remains docked, and the player is paying upkeep and fuel to the rig, the rig will produce pods of ore. These pods are stored in the “station” inventory that is part of the trade system. When the player wants to sell the pods, he uses the trade screen to purchase the pods out.

Mining rigs are hired near processing stations.

Mining Stations

These asteroids replace the standard mining stations. Or to say it better, they become the standard mining stations.

These asteroids are placed using the save_type program. The mines are placed into the cluster just like every other kind of station.

Every mining station entry in save_type will have two extra parameters added, the number of docking ports, and the richness level of the asteroid. The richness level determines how many pods of ore per day are produced by a mining rig And the number of docking ports determines how many mining rigs an asteroid will support.

(Implementation issue: the asteroid model will have the max number of docking ports. Extras will be turned off in code and be unable to be used by the player).

Mines can be of any mine type: Common ore, water, organic, etc.

A new type of mine needs to be designed that produces ship fuel. This type of mine can be used by clever players to fuel their own fleet when they are in distant systems.

Models

There needs to be one new asteroid to replace each type of mining station. Here is the list of mines that need replacement.

• ept_WaterMine = 2,

• ept_OrganicsMine = 3,

• ept_InorganicsMine = 4,

• ept_BiomassMine = 5,

• ept_CommonMetalsMine = 6,

• ept_RareMetalsMine = 7,

• ept_ExoticMetalsMine = 8,

• ept_RadioactivesMine = 9,

• ept_FusionableGasesMine = 10,

These replacement asteroids should be at least 500 meters in diameter and up to 100km in diameter.

Each model should support 3 docking ports. These need to be subsims/dockports/universal_ports to allow ships to dock. The dock ports should be mounted flush to the asteroid surface. A mining rig will dock with the dock port and it should look like it landed and attached to the asteroid surface.

Economy Impact

This is the first time the player will be able to directly impact the economy. The player will be able to create and destroy mines, and thus shift the economics of the cluster.

The player is only allowed 9 wingmen, so the total impact will be minor. However, it will still exist.

The economy will notice the added mines, and recalculate pricing. The player could tip the balance in a critical system to cause the whole cluster to shift pricing. (it would be fun to set this up, but not tell anyone).

One of the main reasons for including the mining station features in this release is to learn how they impact the economy. We might need to make major changes in the traffic release to compensate. We will not know until we try it.

Cluster Design

The cluster will need to have the mines redesigned. Mines will produce less ore (they are smaller) but there should be many more mines.

The richest mines should be in the more dangerous or even unexplored areas.

Prospecting and Claiming

Prospecting is the act of finding an asteroid, and then having a science team analyze the asteroid for economic potential. Once the asteroid has been analyzed, it is claimed by the player.

Unless we implement some kind of long range sensors, the player must be able to see the asteroids on the navigation comp.

Science team wingmen are used to analyze asteroids. The player hires Science teams near science bases. These teams do not have capsule drives or lds and must be towed to an asteroid base. They will dock onto the asteroid and begin to study it.

The science teams take several days of time to complete their work. The longer they study, the more docking ports are opened (until a maximum of 3 is reached).

The science team must be protected during their time (remember the Iwar1 mission to this effect).

Claims can be jumped by the player. If another faction is already operating a mine, the player can steal it. This is done by destroying all the mining rigs attached to a mine. The mine will become Empty when the last rig is destroyed. The player can then use a science team to claim the mine.

If a player undocks all his mining rigs, the asteroid stops adding to the economy.

Removing Station Features

These tiny mining stations do not have all the features of larger stations.

There is no LSDI field (if we can find a way to remove it).

New Non Player Ships

Player Wingmen

There are three new types of wingmen supported in this release.

The Mining Rig

The Science Team

The Tanker Ship

These wingmen have been discussed in other features.

Wingman AI

tsWingman.pog

The player wingmen AI was upgraded to have a POG state machine task. This means that the wingmen can execute complex commands, such as pod loading or multiple ship refuel commands. The AI is smart enough to move from one step of a task to the next step without needing a new command.

The player wingman save game system was modified to save the ships order state.

Wingman Commands

tsWingComm.pog

The wingman command menu interface was updated to support new commands for tankers and miners.

Loadout GUI

tsLoadoutGui.pog

A new loadout system was designed to replace the player base and hanger.

The file MS_Mod_Ships/cargo_hardpoints.ini is modified to add new weapons or mountpoints to the loadout system.

No weapon INI or mountpoint INI files need to be modified to use the loadout.

Weapons that are included should NOT have avatars associated with them. Instead, the avatars should be part of the ship model and the avatar should represent the mountpoint. So for instance, if a ship supports a missile launcher, then the avatar for a missile launcher should be placed at the null location of the mountpoint. It is not essential that the model have a proper avatar, the loadout code works in any case, but it does look nicer.

The new design requires a few simple entries in ship INI files to allow the use of loadout. The ships need to have location values attached to each of the nulls so the loadout code knows where to place systems when they are changed.

All ships have a nulls listed in the ship INI file like this:

null[5]=drive_location

The loadout requires that two new entries are added for each null entry:

null_position[5]=(50,20,0)

null_orientation[5]=(0,180,0)

These values are taken from the ships *.lws file. The position values are (x, y, z) position from the ships center in meters (center is setup as part of the ships *.lws file). The orientation values are (roll, pitch, yaw) in degrees.

Weapons often have an orientation component as well that should be taken into account (they often fire 90 degrees from mountpoint orientation).

Loadout uses weapons purchased via the standard trade GUI and placed into the player inventory. This is a phantom inventory that can be accessed by the player at all times.

Loadout Ships

The ships in the game needed to be modified to allow loadout to change weapons and place new ones.

Several ships were modified and can be found in Ms_Mod_Ships/sims/ships/player. These include storm_petrel_new.ini, fast_attack_new.ini, tug_new.ini, heavy_corvette_new.ini.

Loadout Save

tsShipSave.pog

The fleet save game system was modified to remember ship damage, current loadout, and weapon ammunition.

Loadout Not Done

MS_Mod_Ships/cargo_hardpoints.ini Rearm cost is not balanced (cost per missile)

Ship repairs are not implemented.

Player Start GUI

coded tStartGui.pog

A new player start GUI will allow the player to select from a list of starting locations and starting equipment.

Needed The final starting setups need to be picked. Right now the setups are designed for testing features.

Save Game GUI

tSaveGui.pog tested The save game screen was extended to allow editing on the save game names.

Library GUI

tEReferenceGUI.pog coded The reference GUI was rewritten to remove a Torn Stars crashing bug.

Needed Are help files updated to support the current careers? The tutorial will need updating to match a new player start.

Email News GUI

tShipMail.pog tNewsNet.pog tested

The old Epic Email and News screens were ported over and brought into the game. These screens were used to implement the News reading feature. And mining ships email the player when they are out of fuel.

Fleet Status GUI

tEFleetGui.pog tested The fleet status screen was rewritten. It now shows fuel and hit point status of all player ships. And it shows the ships location. The screen lists any cargo that is docked to a ship, so the player can quickly see what cargo his ships are carrying (handy after a break from playing or after a wingman is lost).

Navigation GUI

tEpicLFPlus.pog tested The navigation GUI screen was improved in many ways.

• It suggests a next station for cargo sale.
• It gives known locations of fences, weapon sellers, fuel sellers and others the player needs to supply.
• It lets the player find the player owned asteroids (handy for setting waypoints).
• It supports a favorites feature for building trade routes.

The navigation gui will need verification if there are changes to the placement of objects in the game.

Lpoint Scanner GUI

tELpointFind.pog done This gui allows a player to place a waypoint in orbit around a moon where an lpoint might be located. The waypoint allows the player to navigate to this location and then scan for an lpoint.

Reputation GUI

tEpicFacGui.pog tested

Rest Day GUI

coded

Allows the player to advance one day of game time. Helpful when waiting for a science ship to complete scanning or mining rigs to drill up some ore.

Quit Game GUI

tExitGui.pog done The quit game is how the player exits the game now that the Escape menu was removed to eliminate a crashing bug in Torn Stars.

Game Options GUI

tOptionsGui.pog done The game options allow the player to set some preferences during play. The options allow turning off the asteroid fields either for frame rate reasons or a possible crash. The options also allow turning off the new autosave feature.

Cargo Purchase GUI

tETradeBuy.pog done Placeholder to allow edits on current status. The cargo handling features were updated and some small GUI fixes done as part of the Torn Stars bug removing effort.

Cargo Sell GUI

tETradeSell.pog done Placeholder to allow edits on current status.

Mining Claim Sell GUI

tClaimGui.pog coded This feature allowed the player to sell discovered asteroid stations to megacorporations. The feature should be removed from the game, because right now it gives the player the power to expand mega corporations (and thus fleets and operations) and that was not intended. Instead this feature should wait until mining fleet operations are coded.

Player Base Screen Removed

tested The player base and hanger was removed from the game. It was a constant source of bugs. A new loadout GUI was created to replace it. This screen causes bugs for two main reasons. The first is that it creates a totally different player ship via loadout than the standard game save. This ship becomes a special case for save and restore. Second, it allows the player to save inside the base, where the standard save scripts cannot run. This means that save and restore can result in odd effects depending on if the save was done in the player base or outside in space. Rather than fight the constant permutations of these bugs, it was easier to eliminate the whole base.

Autosave

tEPlayerWatch.pog done A new autosave feature was added that saves the game as the player approaches a station. The autosave is meant to work around a station approach crash. It also allows a player who flys to an unexpectdly hostile station to back up and try a different approach. The autosave requires the player move away from a station, then it saves when the player approaches the next station. This prevents overwriting the save when the game is restored. Hostile fleet operations prowl the systems now. They can be very lethal and unexpected. Approaching a station should be done with caution.

Crew Speaking

The player crew now responds to some commands so that the player does not feel alone on the ship. When the autopilot is used, Az will respond. When the capsule jump is selected, Lori will respond.

It was intended that in the long run, other crew would speak, such as Smith alerting the player to critical systems damage. Along these lines we were also thinking of moving the lpoint scanner functions completely over to Lori

Cargo Ships

tPcCargoShip.pog tested

The standard traffic scripts have been removed.

A new cargo ship script was written to pick up and drop off cargo so that pirate players have targets they can attack.

The cargo script uses cargo out of the Torn Stars economy.

Ship Stats Rebalanced

A huge amount of stuff I am not sure how to document.