Boarding Ramp suggestion: I really like the look and function of the boarding ramp, however, I've noticed a drawback which is limiting of my designs. The current boarding ramps on a ship tend not to allow enough room to load HVs that are anything but small and really short in height. My suggestion, add some versions of the boarding ramps that not only open downward to lower the ramp but also telescope to extend the boarding ramp. If this could be done to add an extra block or two of height clearance for HVs that would help a lot. If this doesn't allow enough clearance it would be good to have some variations of the hanger doors designed to look like they are purpose built to function with the ramp.
A boarding ramp that is a vertical lift would be phenomenal. X x Y x Z - ie, 3x3x3 - three blocks wide, three blocks deep, and three blocks high, so it descends 3 blocks straight down and lifts straight back up. A lift that is the reverse as well would also be great - and X by Y hole that lifts up Z blocks, so we can have both upper and lower access for vehicles. --- Some other blocks that would be great, and should be fairly easy to create: 1. Portcullis - Metal bar "door" that lifts upwards (or if flipped over, lowers downward). 2. Metal Bar Walls (modified railing that is 1 block tall, rather than 1/4 block tall) 3. "Hazard" blocks - Hot, Cold, Radioactive blocks for creating hazard regions. Should be able to be toggled on/off. 4. Gates for Railings 5. Stairs with Handrails (Left, Right and Both Sides) - would save both valuable space and time instead of having to waste a block space attaching railings. 6. Dedicated Armor Blocks with Specific Damage Resistance" This is a trickier item, but would be well worth it. These would be non-air-tight half-blocks, designed to fit flush over existing blocks. Each would have the HP equivalent of a full-sized block of corresponding shape, but only against specific types of damage. Against other types of damage, they'd have half-block HP. So, for a "Thermal Energy Armor" block, these would have full HP against things like Pulse Laser and Laser fire, half HP against Kinetic and Explosive damage (miniguns, railguns, missiles). This would bring new dynamics to PvP and PvE, by allowing builders to toughen vessels against certain damage types, in certain areas, and require weapons variations to deal with effectively.
@IndigoWyrd I like your ideas too, especially a boarding ramp option that's a lift. The ramp is hard to get enough height, my idea only gains a little for the larger ramps since it only helps to reduce the static ramp width since the large ones take up 2 and 3 blocks height. The lift solves that, tho I still like the idea of a ramp.
Recently dashed out a new "show room" Base. It is "my style" (meaning extremely sparse with a focus on functionality and not much attention to decoration) at this point, though if anyone wants to dress it up or expand it, I'm happy to put it on the workshop. It is presently still way too small to cope with housing even a single instance of every one of my existing BPs, so I do need to expand it still. Given there are now "crew" blocks in the game, this was perhaps my very first effort to build a base that seemed like it was an actual human facility with a commander and staff and not simply "dichebach's secret hideout . . ." I came away with a realization of what I think is likely to be one of the single most . . . beneficial undertakings Eleon could consider given that continually expanding blocks is clearly a longstanding labor of love. I'll phrase it as simply as I can, but then I'll be more accurate and specific (and if no one can comprehend what I'm describing, I'll jump in the game and offer some screen shots). Give us all (or at least many) of the decoration blocks as "Decoration+Wall" blocks. Let us say for example, you are building a hall way with an XO Quarters on one side and a Galley on the other. You want the hall way to be one block wide, doors that open into the quarters, and the arrangement of things like food processors, fridges, desks, lights, decorations and the like to also look like they make sense, i.e., ideally to be able to have items pressed up against walls if necessary. The fact that a wall block (even the thin variety) takes up a whole block creates an interesting set of constraints which--for me, at my fairly introductory level of experience with the builder tools--lead to unrealistic constructs. Having all the decorator and LCD blocks exist in a second form which allowed them to be placed as PART of a wall block would largely solve this.
Your pain... I feel it. I rarely use thin blocks in base construction because of the A Block is A Block principle. The few times I use thins are typically when I need to create air vents.
I've been away from the game for six month plus, and even up to that point my period of major engagement was years ago. So, I'm not entirely sure what state the modding tools are in. With that said, I think that one dimension to project scope that might be very beneficial to the game's community long term would be: enough exposure to the "back end" that modders are able to add new blocks to the game. Especially combining of existing block models to create new ones. The fact that all base and CV blocks are obligatorily 1m x 1m square is, a shortcoming of the game design I've rued from very early on. But I don't imagine that is something that could be addressed in EGS I and might have to wait for EGS II if such a thing ever emerges. Were such a thing to ever emerge, my recommendation (as a C++ programmer, a language which I think could handles the memory mananagement on modern hardware, but I'm not so sure about C#) would be to target 10cm as the "minimum" block size and define all pre-existing blocks in 10cm increments. All that said: assuming that 1m x 1m blocks for CV and BA constructs are all we are going to get with this iteration of the app (EGS I I mean) then even with modding capacity, users could conceivable export models from the game, modify them in Maya or some similar app (perhaps there is a recommended one to work with Unity, I don't recall), merge two blocks into "one" block, et voila! So for example, instead of LCD Display, we might have: LCD on Concrete LCD on Armored Concrete LCD on Steel LCD on Hardened Steel, etc., etc. That is a LOT of modeling and probably would necessitate some texture work too, though my sense is that the params that regulate physics, collision and interaction dynamics might not need to be "modded" much, but perhaps simply adjusted as needed. Given the sheer volume of work that would be involved, and the limited extent to which it would drive sales at this point, I can totally understand how Eleon would not be inclined to commit to this sort of undertaking. Nonetheless, they HAVE shown tremendous perpetuity in creating new and better blocks as players have asked, albeit at a rather slow pace it seems. So perhaps some sort of 'design sharing' scheme similar to what they have followed for introducing player created vehicle and base constructs into defaults for the game could be considered.
Mg-Turrets , gimbal mounted Weapons and Grav-Generator for SV , i like ship's in the size of a YT-Freighter or the mid size Elite Ship's .
Device request: Large generator for HV's and SV's. (I have a build that needs 7 of the current generators so that it will not go over 100%).
A device I would really like to see would be a CV compressor. So that when I land on a planet with an O2 atmosphere I can turn on my compressor and refill my CV's air tanks automatically.
Speaking of... I am of the mindset that says IF you run a generator over 100% of its rated capacity, it should produce excessive heat and radiation AND cause the generator to lose HP until it finally blows out.
That is a great idea! Related ones: 1. Celestial objects (asteroids, comets whatever) which have ice and can be mined for water. 2. A CV mounted device that allows you (when landed on a planet) to drill for water without having to setup a water machine. Make it costly, make it relatively slow, whatever. ADDIT! Oh and 3. End game "maintenance droids" that have a station (no need for an animated model that moves around, just have them "mounted" on the outside or inside of a base). Each one can be assigned a simple scripted task like: (a) If (Fuel_in_Tank <= 35%) {Transfer_Fuel from storage}; (b) After 24 hours harvest all crops and put them in "Raw_Goods_Fridge." These type of things could be handled with much the same code as the switches but change which callouts they can access. My guess is the main reason functionality like this has only very slowly considered by these developers is they have (or had?) this notion that the same set of game rules has to serve both PVP and PVE and they wanted to maintain the player-character involvement for many mundane tasks for the sake of PVP. A philosophy I could not disagree with more. Making a singleplayer experience unnecessarily more tedious for the sake of "multiplayer" is never a good idea.
I have slightly mixed feelings about this . . . but, I support it. I think it would be a great idea if "SVs" and "CVs" differed in their constraints as little as possible, basically allow a player to build an "CV-sized" SV that could perform almost all the roles of a CV except for one or two. I say this mainly because CVs only have 1m blocks, whereas SVs have the smaller ones (half meter or whatever they are . . . or maybe those big blocks are actually close to 2 meters?). The functionalities which are restricted from the two classes has changed substantially over the years, and that is a VERY GOOD thing. I think that a distinction like SV / CV is fine, but as it was originally conceived it was far too restrictive in both directions. It would be interesting to list what all the things the two classes can do at this stage which the other cannot, but I cannot off the top of my head list all of them. One question that I think would be salutary for the developers to ask (well one with several sub-questions): 1. What is an CV "for?" 2. What is an SV "for?" HV and BA seem less questionable. Here is my take on it, and perhaps all that it needs to be sound design. 1. An CV is for building a ship (whether that is an interstellar star ship, an actual space station with some movement capacity, a planet based freight ship, or a planet hopper) with big blocks. Big blocks have more HP and more resistance and are heavier and require more CPU. Thus CVs are just "bigger, tougher" but also more costly ships. 2. An SV is for building a ship (same breadth of types possible) with small blocks. From this standpoint, any "function" a CV should be able to do, an SV should also be able to do.
CV blocks are 2m , HV and SV ~60 cm , they could use the HV Minigun Turret Modell and with high mass costs they can do them to expensive for small SV's , i would like say they can limit it via CPU but at the moment CPU limit only large construcktions , small builds are unefecktet trugh CPU exept of the little space they need .
This one has taken some time to realize how much we could use: A Portable Predator Lure It would be buildable from the Personal Constructor, be a small device, and require Meat as a "power" source, consuming 1 meat per 3 minutes. It's purpose - to attract Predators - Raptors, Spiders, Cave Worms, Otyughs and the like. Why? Aside from the useful materials they provide, they are one of the only ways to raise faction reputation that doesn't generally upset another faction. They could also be used somewhat strategically in PvP, as they could distract opponent turrets, or even opponents.
It would be nice if you could use the fertile grow plots outside but be limited to those plants normally found in that biome. My base is surrounded by those big flower things but when I try to plant one in a plot outside it dies. Seems funny that it grows outside in the wild but dies in a fertile plot
An Add-on function to the Paint and Texture Tool: Terrain Painting It would be so nice to be able to cover up Drone missile blast squares, or doodle in a nice walking path, or gravel parking area, using the Terrain Textures we already have, simply by pointing at the ground and painting them in with the Texture and Color tool.
Job/Contract consoles for use in stations and bases. PASSENGER CONSOLE - Connects to player ship and assigns NPCs to passenger seats as player agrees to take them on board. BOUNTY CONSOLE - List of missions to natural, abandoned, and other un-owned POIs to hunt down targets of interest for kill/capture. FREIGHT CONSOLE - Connects to player ship and fills with cargo to transferred to other location. MERCENARY CONSOLE - Allows player/s to sift through a list of missions targeting military installations and assets.
CV, or Capital Vessel, is something of a Flagship. This is a much larger, space-going craft, suitable for long-term travel across vast distances. It can accommodate nearly all the functionality of a Base, save a few devices, can transport both multiple passengers and vehicles, and can provide long-term support for operations in both space and on a planetary surface. SV, or Small Vessel, is suitable as a combat fighter, scout vessel, or short-range transport. With limited capabilities, it is suitable for use within a system, such as making trips between a planet and moon, or for short jumps to nearby systems, where a CV would be excessive. One would not charter an aircraft carrier for a fishing expedition. HV, or Hover Vessel, is a utility vessel, suited for any number of different functions, including Mining, Repair, Harvesting, Transport, ground-siege, or other support roles. BA, or Base, serves as a primary operations center, has the fewest restrictions and is suited to be a central command and operations center on a planet, or a "full service" space station. When I first started, my Bases tended to be quite large and elaborate. These days, I tend to focus more on my CV, which serves as a mobile base, with my actual BA structures being dedicated largely to storage and refining - ores to ingots, promethium and pentaxid to fuel. The mobility of the CV makes it both defensible, and flexible.
It would be nice if you could fire your gatling gun through the cylinder and square framed blocks. The blocks perfectly frame the gun and help hide it from view, but it is a shame the computer treats them as solid blocks so you cant shoot through the holes in them.
