MalReynolds

I was originally referring to cost to build, not buy "They're made in an Assembly Line L and require more resources than the industry units which actually produce something."

I believe it's only 1 output, just like all the other industry units.

I think radar detection and lock time should also depend on the averaged cross section over time with range factored in. e.g. Imagine that each ship within the max range of a radar is given a score based on their cross section, distance, whether they're thrusting (per engine), braking (per brake), or firing guns (per gun). If the ship score is below the first threshold, they are not visible on radar at all. If it exceeds that first threshold, then they are detected, and the can be targeted for a lock. The amount of time a lock takes, depends on how many points below a second higher threshold the ship is, the further below this threshold the longer the lock takes. Once at, or over this threshold the lock takes a flat amount of time (perhaps based on the size of the radar), being well over the threshold might make the lock take less time (optional). The lock time would be dynamic, as the ship score increases the lock time drops in real-time. If a ship is being locked, but drops below the first threshold then the lock fails. This would allow some stealth gameplay and would allow for skilled pilots (well timed thrust/braking) and well designed ships (smaller cross-section, fewer engines/brakes etc). Radar quality (via talents) could be introduced to reduce the thresholds, making a radar more effective. Talents or variants of engines/brakes/guns could reduce the score these elements add to the ship score.

If they did this for anything over 100-200m in height, that would work quite well I think.

I agree that we want more salvage/scavenge as a gameplay mechanic and that it needs to be more interesting than the current state of affairs. However.. the game still has a number of bugs, frame rate issues, slow load-in issues, and other things which can result in an "undeserved" crash. Until these are resolved, at least to the point where they are very infrequent, then I don't think we can expand the salvage/scavenge mechanic. However, once we reach that point... Sanctuary should not allow salvage of anything that hasn't been intentionally abandoned - or abandoned due to the player cancelling their account. If a player goes idle, their tile etc remains theirs indefinitely. If they crash, they are the only one who can repair it. I don't think we need "special case" rules for salvage inside or outside the safe zone - however as you read the ideas below you will see that simply by being a safe zone these "special" rules will fall out of the general rules outlined below. I think constructs (static or dynamic) on a claimed tile should not be salvageable. However.. in the future when we have ground warfare a claimed tile should transition between claimed (original owner) -> contested (all) -> claimed (new owner) and salvage rights would be with the owner, or free-for-all once the tile is contested. So, as you attack the defenders can salvage/repair and you cannot until you do sufficient damage to reach contested, then they, you, and any other vultures/crows on the edges of the contest can salvage, until you take full control - at which point everything that remains is yours. On unclaimed tiles there should be a grace period of 1-3 hours during which no salvage is possible. After this, it's free-for-all. This makes your first long distance slow-boat trip to a new planet a risk, and exciting, and gives salvagers a reason to hang out on these destinations just waiting for fresh meat. During the 15 minute claim timer the tile would be considered claimed for the purposes of this rule - so taking a TCU with you means that if you survive the crash you can claim the (probably rubbish) tile to secure your ship. I would like to see new radar indicators for "wrecked" constructs which have exceeded this 1-3 hour grace period, so we can scout for them, write lua to help, etc etc. I think that if a player has been idle from the game for too long, their assets should be calculated and their account credited with this quanta - then their in game tiles and constructs left in game but "abandoned". This will provide a steady supply of things to salvage.

This post is about the experience of crafting using industry in the early game. I am fully aware that as you build resources these concerns decrease, but .. this still leaves us with a less than ideal early game experience - which is the issue I want to address. So, early game, you're building things in your nanocrafter and you're starting your industry... You build the parts for the Assembly Line S (skipping the XS as it's useless initially), then you build the parts and Assembly Line M, then you build the parts and a Smelter, Refiner, Electronics, Metalwork, 3D Printer, and containers galore. The progression here is fine, the issue is that because you have to use the nanocrafter to produce the parts required (typically into a linked container as input to the assemblies), and because you have to manually alter the recipe each time, you're essentially tied to your base, for long periods of time, doing "nothing". Sure, you could be building the base .. but.. typically you've used all your starting honeycomb and don't want to make more, yet, as it would slow down your industry creation. Sure, you could run off and mine.. but then your nanocrafter queue will put the current output in the wrong place (because you leave the linked container range) and then it will stall (as all the inputs are in the linked container, now out of range). So.. instead, you sit with your thumb up your .. doing "nothing". This is a "not much fun" gameplay loop which I would like to see improved. I think the solution is to add queues to industry units. What I mean by this is that we ought to be able to queue a "make X of Y" request, just as we can in the nanocrafter. I am not suggesting we queue "make infinite" or "maintain X, and Y, and Z" or anything like that. So, industry units can either be processing a queue of make X of Y OR doing one of those other things, not both. So, lets start by listing and attempting to refute the common objections to this: 1) this would make large factories redundant If you can build everything with 1 electronics, why have more? Because one electronics can only do 1 thing at a time. So, if you want to produce something with 5 ingredients, you would have to wait for one electronics to produce all the input, one ingredient at a time, and your "factory" (of 2 units) would be super slow and inefficient. Given this, you still need large factories, especially once you reach the scale where you want to "maintain" a range of input ingredients to keep your factory production constant and efficient. Queues have to be queued manually, so they're not appropriate for a fully automated factory. In short, queues won't change how large factories operate, so they will still exist just as they do today. 2) this would reduce the "value" / "cost" of items in the game, and "ruin" the market. If things are too easy to build, who would buy items from the market. Yes, this will make it easier for new players to build the smallest, cheapest, T1 elements in the game. But, doing so will still take them quite some time (see point #1 above) even if they have a few industry units, so they might prefer to buy these items some of the time. For higher tier items, with more ingredients and longer build times for those ingredients and the item itself.. those players are going to have an ever better reason to buy the items instead of making them. Another way to look at this; even late game players might prefer to simply buy, in bulk, lower tier items. If crafting these is easier for new players, then they may even be selling on the market. This is actually a net positive for the market, even if the price per unit is lower, there will be more items being bought and sold. In short, queues may have an effect on the low end of the market (positive and negative), but very little effect on T2 and above. 3) Any other objections? If you have any, please let me know, keeping in mind the points made in response to objections #1 and #2 above (as I can think of some potential objections which these points refute). This is not just my complaint I am not the only person who has issue with this gameplay loop. I recently watched this video where they express the same concerns about crafting speed and having to sit round doing "nothing".

Yeah. In fact, as a programmer myself it seems likely that TUs and Industry are coded in fundamentally the exact same way. Take X units of A, produce Y units of B, in time T. In the case of a TU, A and B are the same resource, and X and Y are 1. So, rather than create more code to do something different, simply lowering the cost is the pragmatic solution.

I think we need a better interface for managing links. As it stands it can be very tricky to pick out the links for a specific industry, or to a specific container. Perhaps a button like 'u' which highlights them would help. But, also, a screen where we can see all the industry and containers (a rectangle for each), click one (to focus it), and see all the links (and available sockets) in and out with the ability to delete and change these links (by clicking an X, or dragging the other industry/container rectangles onto the focused one, or similar. The goal here is to get a better overview, so we can more easily manage the links to resolve issues like running out of sockets on a container with resources you need.

They're made in an Assembly Line L and require more resources than the industry units which actually produce something. They only allow one item type to be moved at a time. They can pull from multiple containers/hubs, and place into one. My biggest issue with industry is running out of sockets on containers. For example, the container with my basic connectors has no more output sockets and I want to connect another electronics to it. So.. I could create another container, and electronics, and then connect to that. Or, I could use a transfer unit to spread the output from the first (which is keeping up with demand just fine) to two containers. The former solution is a lot cheaper than the latter.. but it irks me because it's less efficient in terms of space and optimised production. If transfer units were cheaper, it would be ok. If transfer units could handle multiple resources, it would be ok. But, as it stands, it's just plain annoying. I realise that if reached the point where I needed 2 electronics producing basic connectors full time it would cease to be a problem, .. for basic connectors. But the same issue will simply happen again for something further down the chain. For me, the fun here is building a well oiled machine and to do that I need a bit more flexibility with things like this.

Yes. I would like to be able to swap a core for another, increasing the build area. Even if this was only limited to increasing size (at first, or ever) it would still be a great help, especially to new players.