Archer

The idea isn't to flip the ship exactly 180 degrees, the idea is to align the ship retrograde so the main engines can be used to slow down. Suppose you build up speed in some direction, cut thrust and turn to get a better look at an asteroid as you drift past it. Now your prograde vector is misaligned with your thrust axis. If you try to perform a 180 degree flip now you won't stop, you'll just change course. In this instance you might need to rotate a total of 94 degrees to stop. Coding this would require some way to reference the ship's velocity vector relative to its current orientation. Otherwise the script will have no way of knowing which way to turn your ship. As for relative velocity indicators these would still be necessary if the target is moving. Maybe you want to dock with a friendly ship without asking them to come to a complete stop first, maybe you want to board a derelict ship that lost power while it was moving, maybe you want to breach a hostile ship. Either way having some indication of the relative velocity would be pretty helpful. That might not be the case. Remember that scripting is not strictly necessary to make a ship flyable; once you assemble the parts and designate a forward direction the game automatically figures out which engines it has to fire to move or turn in a given direction. If Lua can access this same control system then it shouldn't be all that difficult; just have the script be something to the effect of "Turn towards retrograde vector." With the appropriate thrusters and gyros already mapped to manual controls the script can just trigger that same turn command. Stopping at the right time might be more difficult but it is certainly possible; again bringing out Kerbal Space Program note the stability assist which can keep a craft pointed in a certain direction* without having to be redesigned for every vehicle. *Unless of course your craft is either off balance, aerodynamically unstable or trying to turn too far from prograde in the atmosphere but that's either poor design or challenge mode.

When it comes to stopping a ship there are a few things I would like to see. Note that I'm assuming Newtonian mechanics similar to Space Engineers but hopefully with a somewhat higher speed limit. (Orbital mechanics would be nice too but that would be... difficult, to put it mildly) Prograde/retrograde flight indicators. I want to be able to quickly tell at a glance which direction my ship is traveling relative to my current orientation. Sometimes it's hard to tell in SE, this makes flying without dampeners difficult. Automatic flip and burn function. This would allow me to stack all of my main engines on the back of my craft rather than having to place fairly powerful engines in all directions. When I want to stop I just hit this function, the ship automatically aligns to retrograde and my main engines fire until I come to a complete stop. This design is difficult in SE even with dampeners. Alternately if Lua can reference these vectors then it probably wouldn't be difficult to script it ourselves. Speed matching aids. Docking with a moving ship is really difficult in SE and tends to result in disaster. Sometimes it seems easier to dock in Kerbal Space Program (where nothing is stationary) than to dock with a moving ship in Space Engineers. It would help if I could either see some kind of on-screen indication of my prograde vector compared with the target's prograde vector or just an automatic speed matching function, similar to SE's dampeners but matching a target's speed instead of dropping my speed to zero. Inertial gravity. I mentioned this one once or twice before, it goes along with what Twerkmotor was saying where the crew experiences G forces when you push your engines: Use that inertia to simulate gravity. Build a ship like a tower with a rocket motor on the bottom, dial the rocket motor to 9.81 m/s^2 and fire it up. Everyone on board experiences the same effects as Earth sea level gravity with "up" being the direction of acceleration and "down" being towards the engines. If DU uses the Star Citizen approach where each ship grid becomes a sort of mini-map with player coordinates defined relative to it instead of the world then this shouldn't be too difficult, just track the ship's acceleration and use that to place a corresponding gravity vector. If you do have an artificial gravity generator aligned to the thrust axis then it could be configured to automatically adjust its output accordingly; if the ship burns at half a G then AG supplies the other half G, if your ship burns at 2 Gs the AG supplies 1 G in the opposite direction and if your ship burns at 12 Gs the AG redlines at 3 or 4 Gs reverse in a desperate attempt to keep everyone from blacking out. Naturally a bigger generator or multiple generators could be used to compensate for greater accelerations but that grav gen mass and power could have been used for more weapons. Of course if you have three axis translation capability without the artificial gravity then things can get... interesting.

Here are a few details that I would like to see as options but seem to be rare in scifi games: Transparent visors. Too many games make facial customization irrelevant as soon as you put on a helmet. Pockets. Whether you're an engineer, a soldier, an explorer or a miner you're going to need a place to store some gear to keep at the ready but this is something I very rarely see in scifi armor/outfit designs. The nanoformer backpack is nice for bulk storage but I would still want to keep some duct tape, a leatherman and some spare ammo where I can get to them real quick without using my backpack. Safety tether harness. Even if safety tethers aren't actually used in the game it would be nice to at least imply their existence in the universe with a line attach point and leg harness. It would also come in handy for grappling hooks, rock climbing and re-creating that tether trick Holden pulled with Naomi in The Expanse. Emergency O2 hose and attachment point. It could be interesting as a functional piece, just in case you or your buddy has a problem with an O2 supply. (You did bring a buddy on that EVA... right?) If not functional it would still be nice to see as a cosmetic detail. Custom decals. Ideally I would like to display two of them, one to represent my organization and one for me. Of course I would also slap both logos on my constructs. Name tag. Any organization that has lots of people working in space will probably want to put fairly large name tags on their suits.

Let's have this thing as one of the jetpack options. Good for vertical takeoff, hovering and precise movements, basically what you want when working on the outside of a tall construct.

Depending on what the game's physics will allow you might be able to get away with a visible ingame mechanism to determine winners rather than relying entirely on an effectively invisible RNG script. That way the machine can't be made to cheat by lying about its probabilities. There is still some trust involved to ensure that the machine pays out when it says it will but if it refuses a legit payout then players will call it out pretty quick and probably nuke it from orbit. Examples: Build a giant roulette wheel. Allow the player to either push a button to release the ball or hit the ball directly to disrupt any possibility of rigging the wheel with precision design. Capture some wild animal and let it wander around in a field divided into grid spaces. The winning space is the one the animal happens to be standing on when the timer runs out. Make sure the cage is sufficiently isolated to prevent players from influencing where the animal travels. Alternately use the crowd of onlookers to help randomize its route depending on what the animal actually responds to.

Obviously not a voxel build but here's a spaceplane concept I came up with not too long ago, my latest attempt to combine a bunch of different functions into a single, streamlined propulsion system: One of these days I'll have to add some details and learn to texture.

I wouldn't be too quick to call wireless energy transfer overpowered as long as you integrated it right. This was mentioned in another thread but one concept that has gone under some real world experimentation is directional power transmission, where a transmitter fires a narrow microwave beam and a receiver antenna converts the microwaves back into useful energy. For game purposes this would mean you attach a directional transmitter to the power plant and a receiver (which doesn't necessarily have to be directional) to wherever you want the power delivered. This would let you use a carrier's giant fusion reactor to power the engines and weapons on a small fighter or set up a beam-powered infrastructure to make it cheaper to move people and cargo around in an area you control. Also, energy conduits still come into play here. On the source side you need to connect the power plant to the transmitter and on the receiving side you need to connect the receiver to whatever systems are being powered. Plus it also represents some efficiency losses due to the conversion to microwaves and back plus beam attenuation. On the topic of Tesla's experiment... it probably wouldn't have worked as intended. While he did successfully transfer power over short distances there doesn't seem to be any indication that he made it work over long distances. Also any signal which is powerful enough to deliver useful amounts of energy risks inducing a current where you don't want it, not just in the receiver antenna. A facility or vehicle which is actually designed to receive power from a directional transmitter can take special precautions but you can't guarantee that these precautions would be taken by every device and structure within a tower's range. I imagine any attempt to actually build a power transmitter capable of supplying a community would likely result in a whole lot of electrical fires. There might be some applications for an omni-directional power transmitter but replacing a city power grid is probably not one of them.

This isn't really how it works. Large objects are indeed subject to greater stresses than small objects when in orbit, but the effects are backwards. Any object in orbit around a larger object experiences a certain amount of tidal stress. Essentially this is the difference in the force of gravity on the near side of the object relative to the force on the far side of the object. Given a fixed diameter object, such as a moon, the difference between the near and far sides is much greater in a low orbit than it is in a high orbit. If we increase the diameter of this moon then we also increase this difference. Earth's moon, for example, experiences enough tidal stress at a relatively high orbit to keep one side facing our planet at all times and create a bulge on the near side.If the Moon were brought closer to Earth then the tidal forces would increase, the bulge would be exaggerated and we could start seeing seismic activity on the Moon (as well as Earth). If it were brought too close then those tidal forces would rip it apart and, instead of a single moon, we would have rings. The distance at which this happens is called the Roche limit. The stress isn't related to "entering" the gravitational field or how high the object is when it "starts," what matters is the object's distance relative to the Roche limit at any given time. On the opposite end we have small objects, such as spacecraft, satellites, most asteroids, meteors, etc. These objects are so small that the tidal forces they experience are negligible even at extremely low orbits. If someone were to try to launch a huge object at us, such as Ceres, then it might break up during its approach (though the effects would still be devastating, intact or otherwise). If, on the other hand, someone picked one of the small asteroids then it would likely remain intact right up until it hit the atmosphere. Actually redirecting the object towards the planet is the real challenge; in addition to the high energy requirements this kind of attack would probably result in a tug of war between attackers and defenders trying to redirect a specific asteroid months or years in advance of the actual impact. As for game purposes things get a bit more difficult. I highly doubt this game will have anything resembling orbital mechanics and it sounds like we won't normally have collision damage. It is possible that the devs could code a special exemption to have objects which fall from space and hit the ground at sufficient velocity to explode, though it would be a lot of extra work on their end to code both this system and a method to push asteroids around. On the other hand bombarding a planet with conventional weapons could be made as simple as pointing your guns directly at the target and firing. This wouldn't work with orbital mechanics (unless you use lasers or particle beams) but it might work in DU's physics with the main concern being game balance. EDIT: One thing I should also mention, if someone does manage to throw an object at a planet that is large enough for the Roche limit to actually be a factor then it probably doesn't matter whether it breaks up before impact or not. Either way you can pretty reliably count on wiping out all life on the surface.

It sounds like the devs are already leaning towards a piping system for energy. I imagine if the performance hit from piping energy around isn't too much trouble then the performance hit for piping oxygen around shouldn't be too bad either. The real problem comes from checking a given construct for enclosed volumes. Any time I run a script in Blender to calculate the volume of a mesh it always takes some time to run. My case is probably a little more extreme than DU since I can model at any resolution I want in Blender but I also am not trying to run volume checks on thousands of ships at once. The best solution I can think of is to program the game to run a sort of simulation whenever a construct is built, modified or damaged and use that model to pre-define pressurized volumes within the ship. Each volume is defined in a coordinate system relative to the ship rather than the world. It would also define which doors connect two pressure volumes and which doors connect a pressurized area to space. That way you can cycle your airlock without having to re-run the whole simulation, just trigger the relevant volume to pressurize or depressurize. If you cycle the airlock incorrectly (AKA open both doors at once) then the game can quickly detect that the interior volume has an open door connected to the currently depressurized airlock volume. Any time the ship is modified or damaged the simulation can check which volumes, if any, the change intersects with and re-run the simulation of just the relevant volumes to check for leaks. To make sure there isn't too much stress when a ship is getting bombarded or built the game could limit each construct to one pressure check every few seconds. It might result in some weird delays at times, where half the room is blown open and you get five seconds to stare into space before anything happens to you, but I think this would be worth it if it means getting a pressurization system in the game. Of course I still don't know what it actually takes to identify a fully enclosed volume in a voxel game, particularly if people have to be annoying and build some kind of really weird interior geometry. The game might need a contingency for edge cases where it either ignores an overly complicated geometry or just gives up and declares a ship unfit for habitation if a pressure check takes too long.

The main tradeoff for a low profile model would be elevation. Positive elevation can be helped if the rear portion of the gun is allowed to drop in to a recess in the hull when aiming high. Negative elevation can't really be helped without having a higher profile. Tanks have to deal with this tradeoff; a higher profile design gives better negative elevation so they are better able to fire while hiding the hull behind a shallow hill while a lower profile design presents a smaller target while mobile. In either case the turret can have full 360 degree horizontal rotation* regardless of height as long as there aren't any other structures on the ship that block a firing direction. *Sometimes internal mechanisms have trouble dealing with full 360 degree rotation, such as cables or ammo conveyors, but these issues aren't related to turret profile and probably won't show up ingame.

Resources aside if some aliens are or were present at some point they might have left probes located in the Oort clouds of some systems to observe the inner planets without interfering with any native populations. Their original functions could include scientific curiosity, threat assessment and first contact consideration. If a monitored civilization does develop space flight then the creators of these probes might want to take a closer look to determine whether to invite them to their interstellar alliance, blockade the system and destroy any attempts at building spacecraft or wipe the civilization out entirely. For our purposes we might be able to salvage some advanced technology from the probes. We could also follow their transmissions to other alien facilities. Of course those facilities might not always be entirely abandoned and messing with those probes might just attract their attention.

Another tool that could be very helpful is radial symmetry. Initially I assumed this wouldn't be practical in a voxel game but after seeing the tools they have in place I think it's doable. This could give us a lot of interesting design options and make it easier to break the mold of the "flying brick" style most voxel games favor. Plus it would allow me to build a proper cylindrical tail-landing rocket.

Now I'm imagining a Jaeger armed with an appropriately scaled up Lancer assault rifle. I don't care how impractical it is, someone has to build this. Anyway I think player-created codes are already kept in check by limitations of the specific elements. Space Engineers has a similar mechanic in place, allowing players to run scripts in C# from the programmable block. However, scripts can only be used to instruct elements to do things that they are normally capable of doing and, as far as I know, functional elements are all pre-made, not player-made. To extend the Space Engineers example I can build a small craft which contains a missile launcher. I have at least three ways to instruct that missile launcher to fire. Method 1: Attach a cockpit, take a seat, set the launcher as my active weapon and click my fire button. Method 2: Attach a button somewhere on the ship, set that button's command to fire a missile and push the button. Method 3: Attach a programmable block, write an instruction in the script which commands the launcher to fire under some circumstances, maybe in response to a hostile walking in range of a sensor. With the right scripts and sensors I can set up a fully automated attack drone. However, the missile launcher recognizes a specific command to fire; it does not recognize any instruction to bypass its normal functionality, such as "immediately refill ammo" or "fire 200 missiles at once in every direction." If I tried to write a script in that programmable block to do this the game wouldn't understand what my block is trying to tell it and the launcher will take no action. Presumably DU's player scripts will work the same way, only able to reference sensors that the player has access to and only able to instruct elements to perform actions that they could otherwise.

I'm not sure where the "realistic" tech focus is coming from, a lot of things I've seen in gameplay videos and dev blogs seem to contradict that. Artificial gravity is pretty much confirmed, the deck orientation of the large spacecraft we've seen indicates that the crew can ignore inertial effects and the sample small craft they show in videos behaves nothing like a plausible aircraft or spacecraft. It can take off vertically with no appropriately oriented propulsion system, it maneuvers almost like an aircraft once in space and it completely disregards orbital mechanics. They do have some elements of hard scifi in general (I was particularly impressed by their reason for abandoning Earth; other stories like to use asteroids or climate change, problems with much easier solutions than an interstellar evacuation, but there isn't much you can do about an incoming neutron star and it is indeed something you could see coming centuries in advance) but overall the devs do not seem to be particularly focused on sticking to plausible technology. My version of shields is no more or less plausible than Star Trek shields. I might have defined the shield's behavior and properties more clearly than Star Trek but the actual mechanism for producing the shield is still entirely fictional. Another thing, this version doesn't have a specific flicker rate or "frequency" for a saboteur to identify and steal. The shield only flickers on in response to an incoming projectile, not at some fixed rate. If you throw a single shot at it then it will flicker on once, if you throw 20 rounds per second it will flicker at 20 Hz and if you fire a three second laser burst at it then it will turn on and stay on continuously for three seconds (all assuming it has enough energy of course). This sort of system could be interesting, though personally I would rank particle beams well above lasers in terms of tech level and potential effects while placing kinetic weapons in their place. I would also suggest using plasma as a short range weapon, kinetic weapons ranging across the scale depending on their muzzle velocity and laser range scaling based on their primary mirror diameter. Of course the last point assumes that this game's laser design is remotely plausible.

For that I was thinking a weaker version of the shield with a longer range than the proper shield boundary. My thinking was that any impact on the shield would be transmitted to the generator. This weaker shield wouldn't be powerful enough to actually stop a projectile but it would still generate enough force feedback for the projector to detect a projectile crossing it. When that happens it determines where and when it will strike the main shield and triggers the appropriate section just long enough to stop that projectile. It might be interesting to have to weigh the consequences of various detection shield ranges, with a short range not giving the main shield enough time to react after detection and a long range susceptible to projectiles fired from inside its perimeter, but it would probably be easier to just use this in the lore and assume the detection field is built into the same shield generator assembly. As for lasers force feedback doesn't help much here but the entire hull can be lined with temperature sensors. When a laser strikes the hull the temperature at the point of impact will increase rapidly. The shield will be programmed to trigger accordingly. Depending on how quickly the shield reacts the laser might get anywhere from a few nanoseconds to a few milliseconds on target before the shield triggers and blocks the rest of the burst. For most practical purposes this probably isn't enough time for a laser to do any real damage. Of course if we're talking Star Wars style blasters all bets are off; the perimeter feedback field would probably work just fine.