10/17/2019

*For displaying a preview of the placement and orientation of a block to the player, perhaps have the game place a ghost of the block to be placed, and remove the ghost when the player looks away from the target spot. Orientation can be displayed in the same way, by deleting and replacing the ghost with the newly selected orientation.

***FEATURE LIST FOR EDITOR***

-Load block files exported from voxel software
-Allow saving and loading ships
-Placement and deletion of blocks
-Rotation of blocks using home keys, and/or mousewheel (mod key to rotate one axis, no mod key for the other?)
-Mirroring?


***ISSUES***
-For placing blocks, .ply models don't seem to include the internal occluded voxels, only external voxels are counted.



IDEAS for the future

-Some way to designate voxels in a block as being vital to the  functioning of the block, if any of the vital voxels are destroyed, the block stops working until repaired. So a door would continue to function with a hole blasted through the middle, and a motor would work if it's just missing a couple casing voxels.

-Being able to designate voxels as being usable? Use the button on a locker to open it, then use the suit to take it, or the rack to put a suit back.

-Tanks should count as a complex object, and complex objects (anything with logic), should have input and output variables or booleans. A tank should be able to have it's dry mass and wet mass output, total internal volume, contents, internal pressure if warranted (gas), etc.

-A thruster could have a throttle multiplier variable, an on-off boolean (depending on how I want thrusters to work)

-One idea for thrusters is to have them automatically burn any propellant that reaches it with pressure greater than 0. Then the thrusters are controlled by the pressure in the propellant lines, which is controlled by pumps and fully adjustable solenoid valves for each thruster group.
	As an example, you have a propellant tank with an internal pressure that has been reached by running that gas through a compressor from the source (electrolysis block or fuel transfer line), and a primary solenoid valve between the tank and the whole prop line network. You set up a program to execute when a button is pressed on your instrument panel. The program will make your ship dodge to the left. When starting up your ship, you flip a switch (or button, or whatever) to toggle the primary fuel valve open. Your prop lines fill with pressurized hydrogen and reach equilibrium.
	When the button to run the program is pressed, the valves controlling the right side translational thruster blocks open, and pressurized hydrogen slams into the thruster feeds; the thrusters immediately burn the hydrogen and impart some amount of velocity. After one second, those valves shut, and the thrusters stop firing. Five seconds later, the same process repeats for the inverted side of the ship, cancelling out that earlier velocity.
	It also allows for normal controls from a seat; you just set things up so that the valves switch from 0 to 1 (closed, open; or is that the other way around?) when you hit the corresponding key. So I hit "A" and the two thruster  blocks on the right fully open instantly giving me a full thrust burn in that direction. When I let go, the valves shut. You can very easily have a throttle controlled by a slider in your cockpit that set a multiplier or limit on the valve input. So you hit "A" and instead of opening all the way, they only open 0.5
The question I'm thinking of now is, "Do we include a basic/beginner/brainlet/default mode control scheme for the flightseat that provides balanced control based on the center of mass for your ship (corneroids didn't have this, if you ship wasn't balanced, and your thrusters weren't placed right, you'd spin) So it should weaken thrusters as needed to get a balanced thrust, for the newbies or lazy.
With that control method and some laser range finders, I think you could pretty easily make a program to orbit target. Probably PID to control distance, and a ship rotation speed to keep centered



***MINING***

-For Asteroids, it would be nice if they could just be generated on the voxel level instead of premade asteroid blocks. Having a set of natural voxels for astroids adjacent to the normal refined voxels, and generating an asteroid with those then lining the voxel based asteroid up with the 32^3 grid would make astroids feel a lot more natural. And since we can mine and cut away voxels, we could easily cut holes for structural supports and build an elevated dock, then burrow into the asteroid for internal facilities.
	That runs into mining. I'm not exactly 100% on Dirkson's mining torch/laser thing. I like the more physical mining of spengies, and mining with a torch doesn't seem as realistic. Maybe a blasting laser for a ship, sending high energy pulse trains to blow apart the rock and metal for collecting. We can have chunks fly off to be automatically collect by the player. Having to look at and grab every rock in spengies sucks. Just have a whitelist/blacklist in your inventory settings so you can set to ignore rock and only suck up iron chunks and voxels. This also easily leads into using a magnetic system to capture ore, with an inventory access that sucks in voxels/chunks. It also adds the option of copying some of those NASA in situ ideas like having a "cloth" balloon to wrap around the asteroid and pull it in. Big grinder blocks could work too, then you just have to get the grinder block to have forward velocity and impact a small enough chunk of voxels to capture and grind them into your ship's cargo hold. That would let you make swinging arms, or manually fly out, have a buddy on the ship manning the mining laser shoot a large asteroid to blow chunks off while you grab the large ones magnetically, or with some kind of tool and fly them into the grinder. Just a small Space OSHA violation.



***PIPES, FLUID, GASSES, and PRESSURE***

-Any blocks that can contain a fluid/gas (fluid from now on), will have a few traits, one of which is safe working pressure. If that pressure is exceeded, the block will fail, venting it's liquid. A pipe should check its neigboring fluid inventories for a pressure differential regularly. If a pipe contains a greater pressure than an adjacent pipe/tank/inventory, it will equalize pressures with it's neighbor. Fluid vessels (pipes, etc.) should also
regularly check the difference in temperature between their connected surfaces, themselves, and their contents, equalizing temperature at a rate based on conductivity of the materials. Excessively hot fluids will weaken and
melt their vessels.
	The rate in pressure changes should be tracked by some variable called 'flow' which can be detected by flow sensors in a pipeline (or integrated into a tank/thruster/consumer?). It might be easier code wise to require a sensor on the far ends of a network of pipes to compare their pressures. I don't know how fast fluids should transfer, more realistically it should be based on pressure difference (or is it just a matter of speed of sound stuff? I'm not well read enough on fluid dynamics tbh), but that's probably too resource intensive. Someone else can handle figuring out the most performant way to calculate things like that, and what the engine can handle. The main point is that some level of semi-realistic fluid simulation should be occuring in the pipes, but not on the level of voxels, just data. No pipes with windows for you. For aesthetics and visual cueing, a pipe with contents than bursts or is suddenly exposed should vent out colored voxels depending on the fluid type. Just for looks.
	The whole pipe simulation thing sort of rams into the need for basic atmospheric simulation ala spengies. Just on the block level would be preferable, but then you run into the issue of doors and the like, or a hole in a block leading out to space, since we can have destruction on the voxel level. Just saying that any damaged block between a pressurized area and a not pressurized area lets fluids through seems really hacky, and not very pleasing.
	In the mean time, when we reach the point of having pipes and thrusters, I think we probably ought to just treat the rest of the universe as vacuum, while any fluid that leaves a pipe is considered lost. At least, that's how I think it should be, unless simulating pressurized rooms and ships is something that is easily sequed into, or naturally fits together with the pipes simulation. I don't know how the actual code writing process would work out there.


(I tried, but I don't think these are anywhere close to correct np)
-100cm radius spherical tank containing 9.3t of Hydrogen at 50MPa
-100cm radius spherical tank containing 148t of Methane at 50MPa



***MISC***

I've thought about how we should handle power generation and the like. You may know that I'm one of the people who was ultra triggered and is still disgusted with the Stormworks power mechanics. Let's just take inspiration from someone who already gave it some thought http://mcro.org/issues/view_issue/11939
I want to make sure we never violate thermodynamics or conservation of mass
for free build mode we'll need symmetry, very preferable able to set arbitrary fields, and up to all three axis
even or odd field placement
(between blocks or intersecting)
I also want to skip the fucking around with fake numbers and just jump right to keeping things accounted for when it comes to dV and fuel units
with the voxels, we can just use real numbers for stuff. Like a tank's internal empty volume in voxels is exactly how many liters of capacity it has. One voxel is 3.125cm^3
real numbers for liquid and gas density, with gas tanks being able to have a pressure number that matches density. So you could pressurize a tank using a pump, and the tank would get heavier
the real numbers should also be exposed to the player; I hate bullshit like "small" "medium" or "large", relative descriptors with no player facing data. It makes things feel fake. Our batteries and tanks should have a size descriptor, and an exact volume/volatage/watt value, mass, and a voxel composition list(slightly hidden, maybe requiring an additional click? idk)
The 'survival' mode build menu should have a spot to tell you how many of the block you can build based on your inventories, like "12.4" (maybe rounded to the single block?)
I'd like to be able to see ship mass, dimensions, and volume (don't know the best way to do that one; just volume of solid voxels, number of blocks placed, or some way of accounting for internal empty space? that stuff can wait)

[5:57 PM]
Munashe:
	another annoyance from playing stormworks today; the simple sliding door only has an ON=OPEN/OFF=CLOSED logic, no data output about the door's state. I know they could do it, I remember other doors having multiple state outputs
	just triggered cause couldn't figure out how to get my airlock with two of those doors to wait until one is closed before opening the other
	so any future stuff of ours should have accessible state outputs, like a number 0.0-1.0 open/closed output/input, and an open closed output, plenty of input potential
	and I'm leaning towards avoiding the chunky logic blocks of SW, and just having a single computer core/mainframe block that can have some huge amount of logic. Maybe we skip the whole simple logic operators thing and just straight to ingame lua shell