Devblog 13th June 2017

It’s with a heavy heart that we announce, Auburn is leaving the Schine team for new opportunities. He completed his project here and we are extremely proud of his work. We are currently working on its integration into the universe update coming later on.

​

What are we working on right now?

We are currently completely reworking the advanced build mode and other GUI functionality to work with a planned GUI scaling update in the future.

Advanced Build Mode

We’d like to go in-depth for one specific build tool that we are going to add. The Fill Tool.

The fill tool is one of the tools we are most excited about. It fulfils quite a few purposes that the community has been asking for and will help you update your ships in the future power update.

Once you engage the tool, it uses the camera position to determine where the fill area starts. When the user confirms the fill location, the game will use the highlighted block type to flood fill up to a number of blocks set by the user.

Each click on “fill” will then add a set amount of blocks (maximum amount per step determined by the server). It will keep track of the blocks already placed so it will reach even into the farthest ends of your ship. Alternatively, it can be used to make some cool spherical shapes on your ships.

The great thing about this tool is it isn’t only for filling empty blocks. It can also be used to fill over existing blocks. One way this will be useful as a “Paint” tool. You can select which block type to replace when filling. The default is the “Empty” type and it would work like described before as a normal fill tool. But you can also select “Grey Hull”, which would replace groups of touching grey hull blocks on your ship. It, of course, would replace special shapes like wedges or slabs with the right shape of the replacement type if possible (grey hull wedge -> red hull wedge with the same orientation).

Another tool we’re working on is the Line Tool. We will implement this in two stages. The first stage will be a simple version. Just like in “Create Docking” you will be able to select two points on the grid (the free point selection is something we will also add for other build tools). The helper will make a line between those points which can be used as a reference or to restrict building/removing just like any of the other build helpers.

Additional stages will add line thickness and additional line segments that can also be set to splines, which then would enable you to make curves.

​

Cargo Transfer

In our discussions about build mode item handling, we also remembered the inconvenient cargo handling that players have to go through, in case they want bidirectional cargo transfer between a station and a ship. The current system is too complicated and also doesn’t allow for item flows down a docking chain. Altering the feature will open a better way to transfer cargo.

The way we will do this is to add two new rail blocks: Rail-Unload and Rail-Load.

The visual difference will make it easy for players to see what the dock is before docking. All connected inventories to your docker block will either be loaded or unloaded to or from the entity you are docked to. These 2 rail blocks will be swappable through logic interaction just like the other ones.

To prevent exploitation, a ship can be set into four modes: “Always Allow Transfer”, “Deny Transfer”, “Always Ask”, and “Only ask for different faction”.

When your ship is set to “Always Ask” (default), whenever you dock to an Unload or Load-Rail, the pilot will get a dialogue asking him to confirm the transfer. If there is nobody to get the dialogue, the transfer will not start. Of course, the transfer can at all times be manually triggered on/off via a ship’s hotbar, and the mode can always be changed in the ship menu.​

As for the next dev build, we should be able to release one at the end of this week, followed shortly after by a pre-release the next week.

Auburn , your work on asteroids and future content is much appreciated. Godspeed with your new opportunities! =)

Would it be possible to have a fill tool mode that treats the filler like a fluid being affected by gravity from a defined direction? This would allow players to fill artificial lakes, rivers, floors, etc very easily.

I assume that these new Rail Load and Unload blocks for cargo between entities will respect things like the "Change cargo to Auto-pull" rules, etc? And does this mean mining drones have gotten more tedious, as we then have to set each drone to be "Only ask for different faction"?

This makes it easier on the 1 hand to handle drone racks of miners, just set all their rails to be Unload, rather than the VERY tedious notion of adding each rail they sit on to the cargo pull (and then it not working in the end sometimes). But harder with respect to the above issue.

This does also mean its a little easier to make drop points for any ship cargo without having to link it (IE< make a number of docks Offload ion the Homebase to allow for offloading from things that may not just be fully set-up miners). Potentially smoothing out how AI works.

Actually you guys could simplify the load/unload rails into one rail instead of two by use a boolean setting for item flow direction.

Click to expand...

Exactly, instead of "creating" two new blocks, why not improve the current system adding only one? The "Cargo Computer".
It could be designed as follows:
- The "Cargo Computer" can be switched on & off via logic, this will be linked to the main rail dock of the ship (only by player hand and for all of them by default).
- if the "Cargo Computer" is OFF, the game will deny the transfer between entities.
- if the "Cargo Computer" is ON, the game will ask if you want to load or unload (Following the established standards for the "storage blocks" along with the logic signals, on to suction, off to pull)

Exactly, instead of "creating" two new blocks, why not improve the current system adding only one? The "Cargo Computer".
It could be designed as follows:
- The "Cargo Computer" can be switched on & off via logic, this will be linked to the main rail dock of the ship (only by player hand and for all of them by default).
- if the "Cargo Computer" is OFF, the game will deny the transfer between entities.
- if the "Cargo Computer" is ON, the game will ask if you want to load or unload (Following the established standards for the "storage blocks" along with the logic signals, on to suction, off to pull)

Click to expand...

If it uses the "active to inactive" storage rule, it can't pull through chains as the intermediate chest is set to "active" to pull from the top most one, and would therefore disallow itself to be pulled from the entity itself is docked to.

how would docking chains work with the new docker block?
Example: salvage ship with a mining turret. would the mining turret need to be docked to a cargo transfer block?
What about a docking arm on a station? would the docking arm have to be attached to a cargo transfer block?

Also, I'm really liking this Fill tool. So looking forward to using it for painting

Something that would go very nicely with your cargo transfer is cross-entity rail travel, it would make cargo pods awesome. This seems like it will make for an interesting update.

alterintel , that's an interesting question. I would think it would still be on a turret docker to be considered a turret, I doubt the new docker blocks would allow the movement of the turret docker, but would function almost exactly like the original docker. The issue would then be whether the old style transfer rules would still be in place for docking through turrets, or if they plan to do something different like requiring a new style docker linked to the turret docker in question for example.

Edit: I forgot, the docking arm thing wouldn't be an issue really. You could leave the standard docker, and add in a logic system to switch the docker to which ever is needed at the moment. They said it would be logic compatible.

how would docking chains work with the new docker block?
Example: salvage ship with a mining turret. would the mining turret need to be docked to a cargo transfer block?
What about a docking arm on a station? would the docking arm have to be attached to a cargo transfer block?

Also, I'm really liking this Fill tool. So looking forward to using it for painting

Click to expand...

Turret rails will need some special rule to them to allow cargo transfer, hard to say what exactly considering that officially, mining turrets don't exist yet. (I know that you can already make them)

Docking arms would have the load/unload rail where you dock things to, and the docking arm itself would be docked to a load/unload rail.
You can switch between loading and unloading through logic rail switching, although in this case you'll have to include wireless logic.

So, all this stuff is nice, but aside from the much-needed Fill tool (which uses your new convex hull calculations, so that's cool), it looks a lot like fluff that would be great to have, but is hardly essential to the well-being of the game, and I can't imagine that this stuff would be a dependency for anything else coming soon (unless cargo-carrying quests will use the load/unload rails? that'd be interesting)

But speaking of fluff that's hardly essential to the well-being of the game, would it be possible to have the jump-drive effect only render on the convex hull surface of the ship, rather than covering literally all of the blocks the way it does now?

The new ABM features sound very helpful; I'm very much looking forward to those. Since the advanced build mode is being overhauled, all this discussion of linking cargo transfer blocks and storages and computers reminds me of how long it can take to float back and forth on a large entity to do this stuff (even shift feels slow on big stuff)...

Is there any chance of getting a simple "Memory" function in ABM, similar to a calculator?

It would be very convenient on larger projects to have way that we can tell ABM to remember a currently selected block (or more with, more memory positions, would be even better) and be able to call that back as the selected block without floating back over or double-click to warp ABM view back to that block's position.