- Please fasten your seatbelts, this will be a long one as it joins few older Bay PRs into one.
1. Ports https://github.com/Baystation12/Baystation12/pull/12626
- SMES units may now be damaged and destroyed. Charged SMES units fail quite violently. Damage can be fixed by welding tool.
- PSUs completely refactored, ghetto variant no longer exists.
- Cell rack PSUs now can be considered a hybrid between large battery charger and a SMES. They actually use the cells to store power (so you can hot-swap the cells to get more juice simply via the UI without deconstructing the whole machine), but in comparison to SMES have poor throughput and capacity in general (cells are simply too small). They are also somewhat limited in configuration options (lacks the precision electronics of a SMES). Better matter bin lets you put in more cells, up to 9.
- Cell rack PSU also has a mode that allows charge-balancing all inserted batteries (moves energy around so each battery has the same charge %)
2. Ports https://github.com/Baystation12/Baystation12/pull/11977
- SMES units now have full load balancing capability, getting rid of that annoying "One SMES charges at full, other SMES gets nothing" problem. If insufficient power is available on input, all inputting SMESes will now charge at same percentage. If more SMESes power a single output, they will all output equal percentage of their setting.
- This appears to have a pleasant side effect of fixing the issue where SMESes could starve APCs of energy. SMESes are ALWAYS last to input power on a powernet.
- This also appears to have fixed weird values displayed in SMES output/input load readings in the UI. By weird values i mostly mean inputs/outputs actually higher than the SMES is set to have.
3. Ports https://github.com/Baystation12/Baystation12/pull/18137
- SMES units (and subtypes, therefore effectively also PSUs from previous entry) can now have more than one terminal. This effectively allows a setup where two (or more) sources feed a single SMES, which then feeds the output. SMESes can not exceed input setting even with multiple terminals.
- Typical example of use in practice would be SMES that runs something important (for example an AI, telecomms, pick whatever you want). It could have one input from the power grid, and second input from a PACMAN generator set up nearby as a backup. Before the generator would have to be wired into main grid, therefore main grid would siphon off power from it. Now the generator can be separate and dedicated for whatever use you want.
Separates the 'count and assess everything' stuff to it's own datum, called the metric datum, which I plan to add on to in the future to make counting and metrics easier.
Makes decision process a bit more weight-based, will probably continue tweaking later.
Makes the admin debug UI have links to change settings easily.
Adds replacement for grid check event, which works similar to the old one, but is now based on a physical machine in the game world, that Engineering can hack to make the event end faster, if so desired. Note that the machine is not mapped in, and won't be mapped in until the event system is ready for launch.
Adds grid_check variables to SMESes and APCs to make them stop doing work without draining the battery.
Grid checks in the new system are caused by a "power spike" which originates from the engine and will cause bad things, should no grid checker machine be connected to the power-net. These power spikes occur when the GM decides that a grid check is a good event to have.
The grid checker can be built and deconstructed using the standard machine construction methods.
- Fixes issues caused when makepowernets() was somehow called.
- Substations (or read, breakerboxes) work properly now. Tested.
- Powernets no longer decide to randomly stop working when stuff is being modified.
- Mostly temporary fix until next devmerge which will (hopefully) add /tg/ powernet code.
power_change() now defaults to using the machines power_channel
Moved the remaining machinery power defines into the proper files
Added code for a basic Antimatter Engine.
It is currently made up of a control unit and several shield objects.
The shield objects must have a patch through other shield objects or be directly touching the control unit. If they are unable to find one they will be del’d.
The control unit needs to be given an antimatter containment jar for fuel before it will properly startup.
A core is created when a shield object detects it has shields/control unit surrounding it.
You can safely inject double the number of cores worth of fuel.
Getting blown up, getting hit by the blob, getting hit with high force items, getting shot, being fed too much fuel will all end up lowering the stability of the reactor parts and once the stability gets to 0 it will either break or, if currently processing some fuel, explode.
I’ve tested the parts several times and nothing seemed to go wrong, the sprites suck but that is to be expected.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@3881 316c924e-a436-60f5-8080-3fe189b3f50e
