Clearly you think realism should belong in a sci-fi game lol. Please explain to me how the Hangar Doors work then As their frames are certainly not big enough to hide those huge panels that open up. Same with the shutters and ramps, each segment, and thickness of each stacked together will not fit in the frames provided. And given how our current 'doors' in the game 'float outside the frame', then by that logic, an iris door could simply do the same. Thenyou can easily look at Stargate and how they somehow managed that 'magical iris' across the event horizon, yet the frame for all that mechanical work is seemingly thin and tucked neatly away. You are short sighted if you cannot see how it would work in-game in sci-fi to give the feature and illusion of an iris door without the bulk of all the 'needless realism nonsense'.
IDK: The frames seem pretty thick and wide to me. And each segment seems almost as thin as sheet metal viewing Shutters and Ramps from the edge. Even if it's not a perfect fit, the suspension of disbelief for most players is big enough to accommodate a small discrepancy. At least there is a (at least somewhat) reasonable attempt to explain how they work. As for Hangar Doors: First, it depends on how one places and uses them. If they are placed vertically such that there is a tall wall above them or horizontally such that there is a wide wall adjacent to them, it could look like and be reasoned that the doors are stored within. (Myself, I usually use Hangar Doors in a base that I build entirely underground, making it easy to imagine the door sliding into the ground.) Secondly, it could be imagined that, despite how they appear, Hangar Doors function more like a Shutter Door or conventional garage door in that they either roll up inside the frame or are hidden in the ceiling or perpendicular wall. Though, I would certainly agree that the believably of the Hangar Door could be improved by changing the model. Regardless, Shutter Doors, Ramps and even Hangar Doors seem far more believable to me than an iris door with a super thin ring that opens a hole nearly as big as the largest dimension. The latter would severely break my suspension of disbelief. Works of fiction that strictly belong in the sci-fi genre should at least appear to want to belong within the realms of hypothetical scientific possibility (even if it is extremely speculative or playing very fast and loose with science), if not actual theory or reality. At the minimum, it should have the trappings of science. Hence, it is referred to as "science fiction." The degree to which a work of fiction swings towards either scientific knowledge and theory or wild speculation and/or imagination depends on how much the creator(s) want to aim towards either "hard sci-fi" or "soft sci-fi". Any work of fiction set in a reality that flagrantly and/or frequently defies scientific laws to a silly degree likely belongs in a different genre entirely. Usually, such belongs in either the fantasy, cartoon, comedy, horror, paranormal or supernatural genres, even if it is set in a modern or futuristic world. That, or it is sci-fi in which the character(s) come from a reality similar to our own, but are exposed to a different universe, dimension or reality where known science does not always apply. Yes, there is such a thing as mixing genres. But then, Empyrion does not have any implementation of ESPer powers, spells or magic-powered devices, nor does it have zombies or vampires, nor is it cell-shaded to give a cartoon effect. Granted, there are what some may consider loopholes. For instance, a lot of weirdness in sci-fi can be explained by a fictional material trope like Unobtainium. But there is nothing in science that says a new material could not be discovered that has unexpected, weird or even bizarre properties. Indeed, this has happened many times in history and is almost certain to happen gain. Though, writers do often take sci-fi tropes to extremes. IRL, nanotechnology is pretty amazing and clearly has a lot of potential for the future. But sci-fi tends to skirt with fantasy when abusing the nanomachines trope to entertain. Yes, this is just a game. And, yes, there is a limit to how far realism should be taken, especially where game balance is concerned. But consistency and suspension of disbelief should be considered, especially if game balance would not be impacted. That's a logical fallacy. As the idiom goes, "Two wrongs do not make a right." Even if there is no reasonable explanation for how Hangar Doors work, that does not excuse adding new devices that seem quite illogical on how they could work. Again, two wrongs do not make a right. Fiction can be judged good or bad based on various criteria, including plot holes or otherwise having something that does not seem to make sense or seem reasonable. Fans can easily overlook little things. We can still love a book, movie or game despite it's failings. However, that a majority of fans can overlook a nitpick does not dismiss the validity of the nitpick. Fans who love a work for all that it does right can dismiss a lot of flaws. Even so, there is a certain limit or threshold to suspension of disbelief. This threshold varies from person to person. But there are some plot holes and some breaks from reality that are so egregious that a majority of fans or readers are unable to ignore it or wrap their brains around it. Yes, a work can have numerous flaws and still be good or even great. But the work as a whole had better be good enough to make up for them. Having lots of plot holes is usually taken as bad writing. Similarly, nonsensical stuff or severe breaks from physics in a work that is supposedly sci-fi is usually frowned upon - unless it is clearly intentional and done for an effect. If a creator wants to ignore all the 'needless realism nonsense', then - to make it believable and sell well - they should probably fit it into a different genre like fantasy or supernatural. But if a creator thinks that they can completely throw realism out the window in something portrayed or claimed as pure "sci-fi", then they don't know the genre very well. And I rather doubt many fans of the genre would approve. Depending on how thin one demands the outer ring of an iris-type door to be, it might also work by way of some futuristic liquid metal technology or nano-tech. But then, such a high technology door would probably look quite different from a stereotypical iris door. It might also work with a biological iris-type door. But I don't think that's what we're talking about.
Motion Sensing Lights Lights that have built in motion sensor zones to turn them on/off when a player (and optionally NPC) is within range.
1. Could we have a chaff turret or launcher, to disrupt enemy guided missiles 2. Radar for CV-especially in space flying around trying to find things is a pain space is really big need something to help find stuff-this would include player ships. Make radar T1 to T3 so improvement to range and detail. Also radar on means you are sending a signal to be found and hit with homing missiles. 3. Health Armour mod-when u have one in your armour it will heal you x amount of times when health gets low eventually it runs out maybe make them by combining all 3 health kits-replaces a mod spot in armour. 4. weapon module AI- allows for an increase in weapon range, damage, rate of fire T1 to T3 can only be found much like epic weapons, Weapon module would be a computer station like block you put in your CV. 5. Performance Module AI- allows for better fuel consumption, higher speed limit and greater thrust (carry more weight) T1 to T3 can only be found or bought . is a computer station like block. 6. Science station with sensor block-provides science points that can be sold to merchants-sensor will pick up space anomalies, map areas, record stuff in space-the science station will record this and make a data disc )data storage) that you can sell at merchants for big bucks. Science station might also develop some tech for (experience) for player. 7. Genetic manipulation bay-make some rare expensive material only found in POI's of great difficulty, when added to the genetic manipulator it changes your player character-various options added hit points, stamina, food amount, jump, run speed, carrying capacity, night vision and so on. the gene material would be rare and worth a lot to merchants. player would enter the gene bay and some cool visual thing would happen-this could create some specialization in players character. 8. Player turret -a turret the player can just drop anywhere-including in a poi would provide additional firepower for the player-machine gun or rocket launcher-requires ammo and energy packs.
Is that a... press to turn on, press again to turn off when held down is on, otherwise off when pressed it is on for two-seconds and then is off ... button? I ask because existing code would support an on/off button, but perhaps not the other two.
I was thinking a momentary pushbutton, so either it's on only when held down or it's on for a second or fraction of a second then shuts off. So 00000 press 1111 release 00000. Same sort of behavior as the laser tripwire but as a button. This is what's missing for using the RS latch and the Toggle signal handling mode. Basically with this you could have several pushbuttons connected to an OR gate, then have that output to a door or light or something that is set to Toggle rather than Follow. Any one of the buttons would then toggle the door open and closed, and you wouldn't have the lack-of-synchronization problem with levers.
My sugestions are those: 1- A serie of block shapes that allow the player to build small, medium, large or very large circular/spheroid structures, like simple spheres, discs or even ovaloid shapes. Currently the only spheres you can do in the game are in the 2x2 shapes to form small spheres/circles but when you try to make something larger it dont work. My idea calls for block shapes that allow for structures up 64x64 in size so it would be necessary a new basic type of block. Instead of cubes you would have sphere blocks and all possible shapes associated with spheres in the shapes pallete 2- The ability to manually control turrets mounted on CVs from the main cockpit It would be nice to be able to select/control any of the turrets mounted on a CV from the main cockpit in the same way as you can control bases turrets manually so that you could aim a specific turret while the rest is firing on other targets. Select a turret in the action bar and simple press a buttom and your perspective will jump from turret to turret in that selection, allowing you to control that turret both in 1st or 3rd mode view. 3- The ability to "lock" targets for turrets to fire upon. This would allow for a fast way to instruct your turrets to focus on a given target instead of the currently random way the turrets aim targets. Targets in this idea (for simplicity sake) would be limited to drones, turrets, engines and mounted weapons. This could work in conjunction with my previews sugestion by jumping on a turret, locking a target while using it and returning to cockpit view. The turret would fire on that target until its destroied or the target destroied. 4- Long Range Sensors for CVs and SVs Those devices would allow for CVs to detect POIs/Stations, asteroids, drones and players up to a long range (5-10km). It would alse make it more simple to explore vast locations like asteroid fields and etc 5- Allow capacitors to be "charged" by generators The main idea here is to allow bases that have a very large power output but low consumption to stockpile that excess energy into capacitors. That way if a base/CV get its generator destroied or if the fuel run out, the capacitors would kick in and provide "Emergency Power" to the base or CV. It could mean the difference between been defeated or being able to escape a losing battle (no generator no power and no way to warp out of danger's way currently) or the difference from losing your base or being able to defend it. 6- New mounted weapons for CVs that work on planets Currently all CVs mounted weapons (ie those that the player control directly from the cockpit) only works in space. While I understand that this is a balance issue since those weapons have very long range/damage output if compared to the turrets that can be deployded on planets it also leaves the player without options to defend itself directly since he will be relaying entirelly on turrets that he cannot control manually. My idea calls for one of two things: A) The creation of new weapons that can work on planets. or B) The adjustment of range/damage of the current weapons so that inside a planet they have different stats so that the balance can be maintained. Me I prefer the first option since its simple. You could call these new weapons the "Light" versions of CVs mounted weapons.
I'd love to have the 'two' parts of the long slope stairs as separate block choices as well. Both in standard and texture-able variants. I'm tired of using the two standard block shapes (slope top and slope bottom) with a generic texture to try and do a short steps from half block to full or full to half block.
This is the frustration I am currently finding and the example you have given is exactly why. When docked would like cargo bays and their ramps to remain open/extended but be closed manually when needed from inside or outside the ship. I have been thinking of the same solution - i.e. a PUSH button - something that sends an input once when used that doesn't require resetting to send the signal again. If the current SWITCH had a reset delay added (e.g. when enabled the switch will always return to the off position after a few seconds) then logic circuits could be used to create this effect.
You might be interested in the proposal I made a while back: https://empyriononline.com/threads/sensor-system-proposal.36353/
I only have one small suggestion: Please implement the block that is missing here. I'm always missing it in every Building. There is the upper and the lower part of it, but not the whole block.
We need a 1x1x1 dedicated Fuel Processor which can create: Promethium Pellets, Fuel Pack (Promethium), Large Fuel Pack (Promethium), Hydrogen Bottle, Fusion Cell, Elemental Pentaxid, and Pentaxid (Refined). It seems like a waste having a full 2x2x2 constructor dedicated to fuel production, and the Small Constructor cannot create higher end fuels. This would be beneficial, especially if it processes fuel faster than an advanced constructor (possibly at the expense of more energy usage.)
I'd suggest a 1x1x2 (a tall unit, for the pipes and tanks to go)... but yeah, I'm all for more devices that have specialty use.
Suggestion: Redesign and simplify the artificial gravity system. The artificial gravity systems that are utilized in CV/BAs have some design flaws which make them both clunky and difficult to work with. There exists no "show gravity range" option, which means that oftentimes multiple gravity fields (sometimes from two different sources, one of which may be in motion) intersect with unpredictable and dangerous results. A suggestion I saw in this thread was to simplify gravity generators by having them operate similar to power generators; i.e. giving power (or in this case, gravity) to every block attached to the vehicle/base. Another suggestion I observed was to have smaller gravity generators or "slim line" generators. These two systems could easily overlap, perhaps using a similar device size/graphical design to the WiFi devices currently in-game. Much like the oxygen system, which requires a specific amount to "fill" the space, and thus, requires a minimum number of block spaces devoted to that purpose (eg. to fill your base you require 4000 oxygen, which requires 2 block spaces (either 2 small or 1 large O2 tank)), the gravity system could be implemented in such a way to require a similar calculation, based on the vessel's mass. This could also encourage the use of lighter materials, rather than the heaviest material throughout the ship, as the required number of gravity generators would be lower. The SOI for the gravity generators would then be the ship and all of its blocks. This would eliminate conflicting fields of gravity between one or more objects whose gravity fields may not line up or whose fields overlap causing high-gravity. In cases of vehicles docked to the BA/CV, the vehicle would adopt the parent entity's gravity, though the gravity generator(s) would have to generate enough gravity to give gravity to the mass of the parent entity + the docked vehicle. This change would add several layers of depth to the system, while at the same time making it more functionally easy to implement. It would necessitate consideration of a vehicle/base's construction materials. Having the gravity generators consume a high amount of power would necessitate either a design intended to minimize the number required (i.e. lighter materials), or larger designs to facilitate the increased number of generators required to power them. Furthermore it would satisfy the request to have gravity generators that are not 2x2 blocks available, while implementing them in a common-sense, intuitive method, resulting in a better overall implementation of gravity in the game.
I propose an external device to be mounted on the outside of a base. Each device would be small, perhaps 1x1. It would have a certain amount of hitpoints and, under specific circumstances, would launch a single drone. The drone it would launch would not be for combat. The only time it would (automatically) launch is if it detects either a dead body or a downed drone or transport in the vicinity, with a maximum range of, say, 200-300 meters or so. It would seek out each drone or corpse and attempt to loot them, storing the loot within it's limited carry capacity, and return to the launch device. Obviously, if there is too much loot for it to carry in one trip, it would need to unload and make another trip. Once the drone lands back inside the launch device, it would connect with the base and unload loot to a specified container. Specifically, the player would first have to configure this device by pressing "F" and then selecting a container through the logistics system, much like what we must do to use a base constructor, Deconstructor, Food Processor or Furnace. And until the player configures this device by selecting a container (or forgets to do this), it will not launch a drone. Ideally, we'd be able to place more than one such device to launch more than one drone simultaneously. Otherwise, I suspect that devs would have to (finally) extend the 2 or 3 minutes timer on downed drones, transports and dead bodies before they de-spawn because that would probably happen before one drone could loot them all. BTW: The devs would not necessarily have to create a new 3D model for such a drone. They could probably reuse the 3D model for the drone players launch when we press [F5].
-Just had an idea about separated docking blocks. Main reason for this idea is to allow allied factions ships to dock. And as difficulty setting maybe if own ships require such extra docking blocks or not, just like the spawn platform thing. Also i could imagine that such docking blocks might be usefull if team-npc's for sv piloting will be added. (I assume it would be much easier to spawn a copy outside the ship and make the docked ship invisible, instead of having it navigate out of the hangar) -Also a neutral/enemy setting for factions and origins would be nice and open up a lot possibilities to create mp-scenarios. -And another thing i would really need is something like a debug rep-bay that is not locked to the limit (also as tool for scenarios).
1. Auto Farming Device. This would sit in a base (base only probably, but possibly CV too) and automatically harvest crops on grow plots within a short range. To avoid it being overpowered, it could have a range of just one block (including diagonals) and consume a reasonable amount of power, around 5-10 units. It would output to a container or fridge. 2. Auto Miner T4. Instead of a terrain placeable, this would be a base-mounted block. Probably 2x2x5 in size. It would need a direct line of sight to the ground to work. It would harvest faster than a T3 auto miner, use lots of power from the base instead of from its own inventory, and output to a container on the base. You could use this with a couple of furnaces to make automatic refinery bases. It would be rather useless with "auto miner depletion" turned on, though. 3. Water Purifier T2. Like the Auto Miner T4, it is a base block rather than a placeable, probably a 1x1x2 size. Needs to be placed with its bottom face in the water and with no block directly below it. Outputs to a container. 4. I like this idea, but I would modify it a bit. It would be cool also/instead to be able to launch your own F5 drone from this device, especially if mounted to a CV/HV/SV. I would limit it to 1 per vessel so you can simply press F5 when piloting or passenger-ing and your drone pops out of the block, rather than above your head. Used this way, the range of the drone should increase up to the range of that vessel's wifi network. It would be a very very useful way to loot drones and bodies without leaving your ship, and it would give a passenger something to do even while the vessel is moving. 5. Not a new block, but add a signal output to pilot/passenger chairs that is on when someone is seated in the chair. 6. Not a new block, but make clicking on deco consoles open the P menu.
A long time ago I suggested a 1x1x1 or 1x1x2 self-contained farming block. Call it hydroponic biosphere, or something. Anyways, you supply the crop and it supplies the light, O2, nutrients, and so forth in a manner that would be survivable if the CV lost its own atmosphere. The trade-off is that it would take more power than the existing grow-plots. Anyways, you could add your auto-farming feature to that and the harvest could be transferred to some pre-configured storage destination. Then the device could start another growth cycle.
