Shipbuilding improvements - Miniturize view from FTD

[ChaosRifle]

I think adding a keybind to the editor (and only editor) to allow a 'blown up'/'miniturized' view would be very useful for placement of cables, wires, or just getting your bearings of where the explosive bits of your ship are through that pannel next to your cockpit.

The system from From the Depths when you press 'P' by default, where all items shrink in size at their origin point, but the origin points dont move to shrink the scale of the ship, just the individual items. Retaining their origin point.
The result is many small parts floating side by side. A single picture doesnt really do this feature justice, you need to see video because the paralax of camera motion gives you the depth perception you need to use it, and it helps further to control the camera yourself to get a sense of your surroundings. I have 1763 hours in FTD at the time of writing, and half my time in the editor is done with this view mode enabled.

I put this forward because I see many people struggling to jam their camera view in the editor into just the right spot to get a cable down. With origin points not moving but attachment points scaling with their respective models, wiring/cabling can be made much more enjoyable in the editor.



Implementation /may/ be relatively easy, I would immagine attachment nodes are relative to an origin point of an object, so scaling attachment points shouldnt be much of a headache. The largest issue I can speculate on may be that origin points of items may be in 'strange' locations right now, like one corner of a beam, rather than perfectly central to a blocks mass, which would cause some things to appear shifted in this view, and not wholely indicitive of its true position. The fix for this is to change origin points for items, but would need a translation layer for old ship blueprints to work in the new system without things now appearing shifted. All future items added would then use a centralized origin point to make this view look decent, but should not need maintaining. With that said, even if this is an issue, the only purpose is to get pesky cables and pipes down, and to see if this wall is going to explode when the thing on the other side gets shot, so perfectly aligned parts is less of an issue. FTD is grid based, so it used blocks XYZ grid coordinates to solve this. Longer items look a bit weird but you quicky get used to it. Of course there could be unforseen issue that I have not thought of in this features implementation, due to how StarBase is different from a traditional voxel grid game.

 

[XenoCow]

As this game doesn't follow a grid and pipes and cables can be placed onto any geometry, how could you place them between the gaps of the shrunken objects? It is necessary to know the exact position of the object geometry to correctly place pipes and cables since they cannot be free floating for more than a couple segments without falling apart the moment the ship moves.

I've had to squeeze the camera into some tight spaces too. However, I have been trying to move to designs where I could make repairs later on outside of the editor. This building philosophy may not be the most space efficient, but it allows for repair and less fiddly-ness while designing.

 

[ChaosRifle]

As you mentioned, you place on other geomety. Their coordinates are relative to other things, so they place at say, x3y2z7 on the block, and when unshrunk, those coordinates remain. The pipes AFAIK are saved as a point to point, with tiny segments to be breakable between them.

 

[XenoCow]

What about the pipes/cables between two objects or in free space? Would they seem to stretch the gaps between the shrunken objects?

 

[ChaosRifle]

I am not aware of free-floating pipes or wires, and for two objects thats what allows this to work. I threw together a quick 2d diagram to help, where red is object 1, blue is object 2, green is pipe, and black is wire. The idea being that as I mentioned, my understanding is that the game saves coordinates of your placements end points(where the player clicked). In doing so, this allows a user to connect to a shrunk item, and when unshrunk, the coordinates would then be translated by a quick script to get the correct position. As we can see, the wires would attach normally to the shrunk items, giving better view around parts like from the depths, but when unshunk, the points get translated based on the things they were attached to. Obviously, I-beams and whatnot would also shrink, allowing connection like that too. The diagram is simplified with only two objects floating next to eachother in the unshrunk (top) image.

If you can freefloat wires (a freefloating endpoint), I guess it would work the same as now, but be a bit more tedius to use if you want the wires visible, because obviously the thing you are fleefloating it in is all shrunk. If the feature was a keybind you could toggle it to get an idea I guess, not sure how to make that more intuitive without alpha access myself. My understanding is the cables 'segment' themselves to an optimal distance so for example, a 1km apart pair of endpoints being shot doesnt loose the whole cable, it makes a small 10cm section vanish instead. That segmentation AFAIK works by overall length of your placed section, breaking it up dynamically after. That system should remain unaffected by this though.

 

[XenoCow]

My understanding is the cables 'segment' themselves to an optimal distance

I may not understand your wording. pipes/cables place set length segments along the path that you define by the start and end point. Any segment can be deleted and the rest remain much like you said.

With the shrunk model, how can you tell if two parts are touching or not? Cabling can only span small gaps.

 

[ChaosRifle]

Any segment can be deleted and the rest remain much like you said.

Was just covering bases as to what I did know about for pipes/wires. Does this include in the editor or just as in terms of damage, because in combat damage was my knowledge. In code the system would save coordinates as if you never shrunk the model, but the renderer would display them as such. Shouldnt cause issues if implemented correctly.

With the shrunk model, how can you tell if two parts are touching or not? Cabling can only span small gaps.

You really cant definitively other than learning the gaps made by parts when shrunk (at least in FTD, this is rather quick to learn, I know starbase is more freeform, so it would take longer to get a natural sense of this) or toggling the view mode off and on. That is the shortfall of it. I would wager to make it more intuitive you would make the pipe/cable tinted a redish hue when stretched too far, or alter transparency to indicate its too far of a gap. Thankfully distance away from an object is spherical and with some sort of visual feedback of where the gap becomes too far that should be easier to grasp.

 

[XenoCow]

Does this include in the editor or just as in terms of damage, because in combat damage was my knowledge.

In terms of the editor and in terms of editing outside the editor with tools. I don't know for certain, but I suspect that destroyed cables/pipes break at the segment ends too.

I would wager to make it more intuitive you would make the pipe/cable tinted a redish hue when stretched too far, or alter transparency to indicate its too far of a gap.

There is already something very much like this. When you click the first point, a white line then extends from that point to the cursor. This line turns red if a wire cannot be placed. It sounds like players would have to do a lot of probing around to figure out possible connection points.

 

[BadNation]

A feature like this wouldn't be too hard to implement would it? From what iv seen in the ship editor it does look quite tedious as of now but still fun.

 

[ChaosRifle]

A feature like this wouldn't be too hard to implement would it? From what iv seen in the ship editor it does look quite tedious as of now but still fun.

As long as models 'origin point' is its center or always a known point (front top left always) that can be translated for(without hardcoding values for every single part, thats a lot of work now, and in the future) when shrunk, it may (I cant stress this enough, I dont want to get peoples hopes up) be relatively easy to do.

Entirely down to how they did things on the back end. They would have to write translation math for some things, namely wires and pipes, but the rest I can't speculate on. A few days work at the absolute minimum as best case scenario(as if this was already planned internally), but it could just not be realistically feasable without a refactor, if things were handled in a way not conducive to this.

Definately a question for a FrozenByte programmer. Maaaaybe someone in the Closed Alpha could look at the save files (if locally stored) and see 'well enough' how things are saved and make an informed guess (maybe/no, you wouldnt get a definative yes/no from this). My guess is likey a bit of time, otherwise a solution like this would already be announced/acknowledged publically by FrozenByte.

 

[BadNation]

As long as models 'origin point' is its center or always a known point (front top left always) that can be translated for(without hardcoding values for every single part, thats a lot of work now, and in the future) when shrunk, it may (I cant stress this enough, I dont want to get peoples hopes up) be relatively easy to do.

Entirely down to how they did things on the back end. They would have to write translation math for some things, namely wires and pipes, but the rest I can't speculate on. A few days work at the absolute minimum as best case scenario(as if this was already planned internally), but it could just not be realistically feasable without a refactor, if things were handled in a way not conducive to this.

Definately a question for a FrozenByte programmer. Maaaaybe someone in the Closed Alpha could look at the save files (if locally stored) and see 'well enough' how things are saved and make an informed guess (maybe/no, you wouldnt get a definative yes/no from this). My guess is likey a bit of time, otherwise a solution like this would already be announced/acknowledged publically by FrozenByte.

Wow thanks for the response it's broadened my knowledge a bit