How complete are your creations before publishing them?

How complete are your ships/stations before you publish them to the workshop?

I find myself spending more time programming cockpits, LCDs, and so forth before releasing a design because I want them to be fully game functional before sharing. But is this just over thinking? I tend to have my toolbar full and put some thought into how the toolbars are laid out. I name every single terminal block with at least a prefix indicating that it belongs to that ship (helpful when managing inventory on docked grids). If I'm using scripts (like Automatic LCDs), all of that is programmed up as well.

But when I'm watching people review workshop items on Youtube, they rarely seem to touch on the toolbar functionalities... but mostly on the ship layout. The toolbars are often very basic and generally empty.

I think I will continue to be retentive on my builds... but how big of a deal is it to you? Do you wipe the toolbars anyways? Curious for the community's thoughts.

 

I struggle with the same thing..

I built this ship, the Vega B. It's SUPER detailed.. lots of scripts like Auto LCD and floor plan, and screens everyhere.. Air locks, auto doors, an elevator, retractable docking connector, auto airlock sensor activated docking bay, gravity drive JRGD, weapons systems, cameras, jump drives, everythings automated, and on and on...

Document any of it?
Do I have a clue what few buttons I made here and there?

Haha... naww. LOL

Here's the ship though

https://steamcommunity.com/sharedfiles/filedetails/?id=1528230162
--- Automerge ---
Somewhere, oh somewhere there's a Red Alert button, and it changes all the interior lights to red, and turns off all exterior and navigational lights, and fires up all the turrets and stuff...
I also used doors as shutters on the windows, and they slam shut too...

Somewhere is a button... Lol. I'm not even sure if I made a button to turn it off

 

YouTube reviews tend to be about looks, and opinions on looks. Then maybe how it handles.

Besides, YouTubers are told to keep it short, so they're just not going to get into details. They probably won't notice how you optimized block names and may not know why you would. Any ship I've ever built would be an hour show at least . I've spent hours on things like that in order to make it as idiot-proof as possible, at least so that someone else might have a fighting chance figuring out how to get stuff to work.

It's a rare reviewer that would appreciate something like that.

 

The bigger followed YouTubers dont always keep things short. Check out some of Captain Jack's lol. I think they dont go over the ins and outs too much because people just really want to see the build and not get into the nitty gritty.

Me personally if I sub to something I want it to be at least 95% complete and when I post something I try to do the same. Over time some of my creations I play around with a bit more and will update the Blueprint on the workshop cause I thought of something else that could be added or something made in a better way.

 

I don't care about the cockpit interface because if you use it as a projected blueprint in survival, the programming is only taken over if you place the cockpit after all the included items are build. Sadly the same goes for timer blocks and so on, so depending on how you build the blueprint, all the work is in vain. Also other people may like anoter layout. What I take care of is the prefix (Thers a nice script for that) and most of the time that there are proper identificable names and logical groups (Automated air locks for example) already set-up correctly.

 

Wait... there is a script for adding prefix or renaming things??
When I recall how long time I spent with tediously renaming hangar doors, lights, etc for creating logical groups ...
Is it this one (result of spontanous search)? https://steamcommunity.com/sharedfiles/filedetails/?id=1751953151&searchtext=prefix

 

The script I use is quite old.
https://steamcommunity.com/sharedfiles/filedetails/?id=391454467
Allows for Prefix, Tags or renaming, numbered or not.

 

So I like cockpit controls if I can figure them out without too much effort. What I really appreciate in a build is automatic doors and airlocks. When I do mine I set them up as iij build them, just easier to figure out which blocks to link.

 

To add a bit more to the sub-conversation: I always try and lay out my toolbars with a bit of logic. My first toolbar is usually related to thruster management and primary flight controls.. i.e. the shit that will crash your ship in a hurry if they get turned off. Then I try to create toolbars for docking, production, battery/power management, etc. That takes a lot of time. Honestly, that's where I often just say F.T.S. and move on to something else as the technical stuff is pretty boring to do.

 

Now... I don't publish things. But... I can't even imagine doing so without every single aspect of the build being complete. Every block name, every toolbar, every sensor... everything.

I don't consider my builds complete before that's done, even as I don't publish.

 

I try to be as complete as possible with my builds. Furthermore, I will play a survival scenario (usually more than one) to flesh out the weaknesses with the design, including controls, and iterate the design accordingly. Only then will I publish the build, but inevitably I’ll find something later (usually more than one something) that if changed would make the build even better. But “better” is relative since we all have our biases and idiosyncrasies when it comes to designing a ship or station, so what I think may be better may actually be worse in someone else’s opinion.

 

I have six ships that I have been working on since 2014 that are still not complete. There is always something that needs attention, or a mod comes out that changes everything. I have come to the conclusion that none of them will ever be "finished". Therefore, rather than publish ships individually, I publish my current session so that anyone that wants to see what I'm up to (and how good their PC is ) can have at it. My ships aren't finished, but they are all operable and can perform their duties. Once you have them on your machine you are free to modify them to your liking. There's plenty of leeway. I have some naming conventions in use, but I haven't standardized anything so it's not universal. I realize the problems that will cause, and that's why I don't advertise when I publish. Don't want to create any expectations.

 

Everything I do ends up in a survival mode/damage on world for evaluation. I will generally test maximum planetary loads (if applicable), handling, as well as other functionality. At a minimum I want to be able to pass along recommendations to the user regarding maximum cargo mass, etc. I'll even log into someone else's server and build from blueprints to test how reasonable things are to assemble and use in multi-player. If it doesn't work in multi-player or if it's too laborious or costly to build, I generally just move on to another ship.

 

I fully concur and agree with everything that you've said, although I don't test for multiplayer because, alas, I'm not hooked up with any multiplayer server with which to test my designs. Perhaps someday I'll find the right place, i.e., a "place" where killing and destroying is not the main focus.

 

@Spaceman Spiff I had invited you to the server I am on. Is no killing and destroying as the main focus. However I know you are not too fond of mods and we do run several dozen.

Anyway, the invite still stands.

 

Really? Oh, man, I need a glass belly button so I can see while my head's up my ass! Remind me how to connect to your server because my senility is running hot these days.

 

If you have a spare machine, you can turn it into a private multiplayer server. The ping won't be as bad as an external server... but you can still get the full Klang experience. It's great for testing builds in a multi-player environment. If you're designing anything with pistons and rotors to be used in multi-player, I'd definitely test it on a server before releasing it into the clutches of the dark lord.

 

@Spaceman Spiff I will shoot you the details in Steam once I get home from work. It will be late this evening.

 

OK boys, he's not home. Get everything that's not nailed down.

Then get the nails.

 

OK, thanks for the tip. I try very hard, although I truly love things that I can make move in a build utilizing rotors and pistons, to avoid using them on my builds. One exception is my wheeled Blue Crab Miner that uses advanced rotors to tilt the drill arms for more effective planetary mining. Otherwise, I try to avoid those suckers lest my soul be consumed by Dark Lord Klang.
--- Automerge ---

OK, thanks!

 

I generally have a policy of no rotors or pistons. But after a few years I got bored. I need some sort of engineering going on in Space Engineers.

 

I'm getting to learn I really should be more diligent about labeling things as I go. Especially interior lights. Figuring out which one is which, after the fact, is not a great time.

 

When trying to figure out lights and group them there's the classic way of showing them on HUD. But if you're dealing with a lot of little lights in a small area, it can get really confusing as to which lights are where.

Instead of displaying the custom names on the HUD, I'll carry a standard grinder around and grind down every light I want to modify to the point that it shows up red in the terminal menu. I will then search the terminal menu for the keyword "incomplete"... assuming that no other terminal blocks are damaged, it will give me a nice listing of all the blocks I just used the grinder on. I can then display those on the HUD and/or just rename them. Once I've grouped them, renamed them, and adjusted their properties, I can simply weld them back up with the elite welder.

This works well for all terminal blocks and especially for those with no direct player access.

 

I’m absolutely anal about labeling everything in my builds as logically as possible (logical to me, of course!). And all of my small-grid builds have a prefix name (e.g., “BCM” for Blue Crab Miner) to help distinguish them from the station or mothership build.

 

Well, I just give them different colors, or turn them off.

 

I've used all three methods.

 

How do you quickly find them in the terminal menu? If you label as you go, fair enough. But for me, when I'm designing, I'm going to be placing and modifying the placement of most of my blocks during the design phase. So I'm often left with a bunch of generically labeled blocks, such as corner lights and they are typically everywhere... landing lights, running lights, lights in the cargo bay, bridge, living quarters, etc.

 

I've found that it's a good idea to not show anything in the main G menu that you don't plan to access on a regular basis. I've also found that it's a good idea not wait until your build is finished to do that. I build in Creative mode and I often have mirror on. After you've placed 40 corner lights it's harder find out if the light you actually need to control is corner light 5 or corner light 29. If all 40 lights go on and off as a group, they don't need to show up individually in the control panel menu. Any individual item that does need to be in the menu gets a name that shows what grid it belongs to, what it is, and where I can find it, i.e. ckt-ramp-fwd-port.

So, if your menu is clear of generic names, adding 4 pistons will show right up. If those four pistons are on a grid that has power and an antenna, you can access the grids terminal remotely and rename the pistons and set the variables individually or as a group. When you're done, toggle them off the main menu so that when you add more pistons you won't get them mixed up.

It's better when the block you just placed has a terminal. An old trick is to place a control panel on blocks like a rotor (which should have a terminal access built in, in my opinion) and name it immediately so that you can find it later.

Mostly, the sooner you get rid of the generic names, either by changing them or hiding them, the better.

 

So, engineers publish blue prints and artists don't?

I don't use workshop blueprints, I don't even use my own blueprints again beyond the same scenario it was designed in. I use scripts and mods from the workshop but not blue prints.

I may adopt design ideas from other people, something i may see on youtube for example. But i would throw the blocks together myself and not use a blueprint, Creating from scratch every time in survival.

My constructs evolve over time, evolution is not destiny and the creation process never ends. I like things to have the lived in look, bent armour blocks and visibly repaired and rebuilt sections. Change your repair colour every day.

My 'perfect' has to have imperfection.

 

If I didn't know for a fact that I did not write this, I would swear that I did.

It's not that I don't like or admire what's on the workshop. I believe anyone that publishes deserves respect. However, the vast majority of workshop blueprints are pure vanilla for obvious reasons. Therefore most of them share a design philosophy not unlike Keen's own. Or, they resemble something from WWII. Or they are something completely unrelated to Space Engineers in the 21st Century. Keen's lack of block variety makes designing ships a challenge, so long ago I embraced mods. Instead of designing a new ship every other day, I try to make ships and vehicles that are functional and capable and likely. For instance, I've never built and will never have a flying miner for use on planets. That would be impractical. My terrestrial miners either have wheels or feet (or treads if we ever get a good tread mod). My ships either work in space or in atmosphere. I have some spacecraft that can operate in gravity and atmosphere, but they're not comfortable there. They're more like elevators and not much good at terrestrial excursions.

The role, if you will, that I play is that of one of the "winners" of the Second Great Space Race of 2029. We were among the first to mine asteroids and got pretty good at it. We continued to push outward and discovered new worlds. We made a secondary business out of bringing colonists to these new worlds and helping them modify the terrain to suit their purposes. So my design philosophy has been figuring out what sorts of vehicles and equipment would a company like that have, and how they would operate. The "operational" part is what keeps sending me back to the drawing board. That, and new more exciting mods. This is why nothing I have made is "complete" and may never be.