[Feedback][7.00 b1] Scrap deliveries are still horribly inefficient

[Maelstrome26]

There are still major issues with scrap deliveries, still making the stations near unusable unless you're out of sector. I have observed the following issues with scrap deliveries in general, and they really need to be addressed:

• Manticore turn rates with Scrap Cubes are horrendouslyslow. This makes the entire process much much slower, and they need to be given an increase in turn rate. Even in SETA, it takes literal minutes just for a ship to do a 180 degree turn.
• Once a processor has received a cube, it's dock is blocked until it has used up the entire scrap. This therefore means ships are waiting around for a free dock. This behavior needs to be disabled, so scrap can be loaded all the time, buffering up for processing. Otherwise, scrap processors are forever stalling due to the various pathing issues.
• Ships are waiting around in sub optimal areas. See this image https://i.imgur.com/55z5ZNY.jpeg, where ships are positioning themselves in a weird place, having to do a lot of maneuvers in order to deliver their cubes. Due to the turn rates being extremely slow, this whole process takes a long time.

Suggestions for improvement:

• Improve the Manicore's turn rate when towing cubes / scrap. This overall will vastly improve the issues.
• Similarly when docking with a carrier, make the Manitcore's queue up to a dock in a line above it. This will improve waiting times and remove the issues of having to turn to deliver, potentially being underneath the dock
• Add a internal storage buffer where docks are unblocked. At the moment, the docks are only opened when there is no scrap in the processor (seemingly), adding a buffer would remove the pain significantly.

Here's a video highlighting the issues: https://www.youtube.com/watch?v=myh1XHPQ2ec

Here's a savegame as well with the setup as in the video: https://drive.proton.me/urls/TKJYQD1054#rXBUpP0KsJZ6

[LameFox]

Once a processor has received a cube, it's dock is blocked until it has used up the entire scrap.

I have often wondered what the point of that is. Assuming it's intentional anyway. My station manager sets the same buy amount for raw scrap as for scrap metal, but the most that can ever get in at one time is 1000 when a cube is delivered. Does that imply it's just wasting a bunch of my solid space that could otherwise go to scrap metal?

[Maelstrome26]

It doesn't seem to use Solid storage for the Raw Scrap, it is stored within the processor as an invisible internal buffer. Only the Scrap Metal uses the Solid storage, to my knowledge.

[Vectorial1024]

• Manticore turn rates with Scrap Cubes are horrendouslyslow. This makes the entire process much much slower, and they need to be given an increase in turn rate. Even in SETA, it takes literal minutes just for a ship to do a 180 degree turn.

The technical explanation is that the mass drag of both the tug and the scrap is very high. It is up to EgoSoft to decide whether the ships and the scraps should get a lower drag, so that the max flight speed is better and turn rates are improved.

Once a processor has received a cube, it's dock is blocked until it has used up the entire scrap. This therefore means ships are waiting around for a free dock. This behavior needs to be disabled, so scrap can be loaded all the time, buffering up for processing. Otherwise, scrap processors are forever stalling due to the various pathing issues.

This feels like a deliberate design decision. Given how OP the Closed Loop production method is, it makes sense to nerf it a bit by introducing randomness to the production process (we do know that the theoretical max rate is 9k scrap per hour). The actual rate being totally off from the max rate due to bugs and coding deficiencies (esp in OOS) is another problem (partially alleviated by mods eg Multi Scrap Processor Fix or Scrap Delivery Coordination), the problem which is supposed to be improved in 7.0. (Disclaimer: haven't witnessed anything yet.)

Similarly when docking with a carrier, make the Manitcore's queue up to a dock in a line above it. This will improve waiting times and remove the issues of having to turn to deliver, potentially being underneath the dock

That is literally what not to do. Tugs must wait "outside" until a processor is available, because there is no way to know which processor will be first available beforehand (at least in v5.0/v6.0). This is like when the trade docks are full, and trading ships must wait "outside" until given a docking permission. Trade ships do not know beforehand which exact trade dock will be first available.

This problem can be alleviated greatly when the tugs have improved maneuverability (EgoSoft decide).

[hr]

Would it be a good idea to adjust the drag values to improve maneuverability of Manticores? Even when we see the delivery behavior improvements in 7.0, it still does not solve the hilarious behavior of a strongly-modded Manticore (with towed scrap) overshooting the station by too much because the deceleration thruster is not enough to deal with the extreme speed of a drag-reduced/mass-reduced Manticore.

[TheDeliveryMan]

• Add a internal storage buffer where docks are unblocked. At the moment, the docks are only opened when there is no scrap in the processor (seemingly), adding a buffer would remove the pain significantly.

Note that one Processor consumes 9k Raw Scrap (9 Scrap Cubes) and 90k Energy Cells per hour to produce 9k Scrap Metal. Your station has two processors, so it can consume at most 18 cubes per hour. You have 7 tugs, each with a scrap cube in tow, waiting at your station. It will take more than 20 minutes to consume those 7 cubes. You have way too many tugs, an internal buffer would only postpone the issue for a while.

Think of a processor as a docking port that unloads ships at a rate of 9k Scrap units per hour. While a ships undocks and the next one docks the unloading has to pause. Add one processor more than you need on paper to feed your recyclers, extra energy is not required. If this rule of thumb works out, then I would consider scrap deliveries efficient.

[TheDeliveryMan]

• Add a internal storage buffer where docks are unblocked. At the moment, the docks are only opened when there is no scrap in the processor (seemingly), adding a buffer would remove the pain significantly.

Note that one Processor consumes 9k Raw Scrap (9 Scrap Cubes) and 90k Energy Cells per hour to produce 9k Scrap Metal. Your station has two processors, so it can consume at most 18 cubes per hour. You have 7 tugs, each with a scrap cube in tow, waiting at your station. It will take more than 20 minutes to consume those 7 cubes. You have way too many tugs, an internal buffer would only postpone the issue for a while.

Think of a processor as a docking port that unloads ships at a rate of 9k Scrap units per hour. While a ships undocks and the next one docks the unloading has to pause. Add one processor more than you need on paper to feed your recyclers, extra energy is not required. If this rule of thumb works out, then I would consider scrap deliveries efficient.

[geldonyetich]

Personally I think that the initial scrap processing should require little energy and turn them into container storage. Move most of the energy cost to the second stage. That way, we could have scrap receiving everywhere and then a secondary step of moving the scrap to the smelters.

[oddgit]

Personally I think that the initial scrap processing should require little energy and turn them into container storage. Move most of the energy cost to the second stage. That way, we could have scrap receiving everywhere and then a secondary step of moving the scrap to the smelters.

I agree, i remember when i was younger i saw a documentary about metal recycling and smelting, they used electricity and would need to run the smelters at off hours because it was such a strain in the power grid. I dont mind the energy usage, the devs could even make it more demanding to make the manticore drop off proces less stupid and frustrating looking. I get that it is to limit the output. I have always found it super frustrating watching a manticore fly around my empty processor that has enough energy cells, but the processor and solid storage is empty, just drop off the scrap and let the processor go, even if they slow the rate of processing down. Real life scrap and recycling places dont do one in one out like a crowded nightclub.

[Scoob]

My scrap deliveries didn't even exist! I set up in Silent Witness XII amid the VERY rich scrap fields. I could only afford three Manticores, but I set them to work. One found a wreck and returned with it, the other two said they couldn't find anything, nor could that first one a second time. I sat there for ages wondering what was going on, then I remembered... this DOESN'T WORK if the player is present. I flew to the next sector and, in moments, my ships are collecting wrecks again.

I had hoped to camp out in this sector, watching things as they happened, but I now remember I simply cannot be present. Shame.

I'll add that Scrap deliveries - now they're working - actually seem SLOWER than in v6.2! My Scrap Processing station - just one module - just takes way too long to process scrap. As it has no "buffer" my three Manticores are sat there idle most of the time. This really needs to change. In a dense scrap field like this, those three Manticores should bring in ample supply, but as they spent most of their time (yes, really) just sat there waiting for the Processor to free up, well, that's a lot of wasted time. To get around this in the past, I added more Scrap Processors, but we know how well (not at all) that works lol.

Hopefully some sort of buffer can be implemented so multiple wrecks can be dropped off in succession, before the queue is full.

[TroubledRabbit]

I mean - without this artificial obstacle this would be completely 'win button', since 'closed loop' introduction any other is not concurrent anymore.

[BlackRain]

I don't think the fact that anyone considers scrapping a "cheat" should matter. This is a single player game, I would much rather the Manticores deliver scrap properly than worry about whether it is cheating if it works the way it should. If I have 8 processing spots, then the manticores should be good at delivering the scrap correctly. If I think it is a cheat, I can just build 1. The player has the power. The way the manticores work now just looks stupid with them constantly just sitting there.

[Koizuki]

I am curious, now that Beta2 with purported fixes to this system have been implemented, whether or not anyone can confirm if these issues still persist, or if everything actually works fine now, especially with regard to stations that have multiple scrap processors?

[Scoob]

I've been closely watching my current scrapping operation, and there are distinct discrepancies.

I teleported to my Scrap Processor (it JUST processes Scrap, it doesn't recycle) and, when I'm there, ALL deliveries are scrap stop. Only when I teleport away again, and wait several minutes, do deliveries start again. This is consistent for me. There are ample Scrap Cubes floating around, provided by a Teuta.

Also, the numbers are off. After the Station stalled, all four Scrap Processors were empty. After teleporting away, I saw the first of three Tugs returning with a Scrap Cube each. First Tug drops off a Scrap Cube (1,000 Scrap value) and one of the processors starts - ~1 minutes count-down. That minute ends, and 450 units of Scrap Metal are added to the output inventory. I check that no ships have collected any Scrap Metal (to deliver to Recycling) in that time and they have not. So, in my game, in this instance 1,000 Raw Scrap = 450 Scrap Metal. Production stats show it as 1:1, i.e. 1,000 Raw Scrap in, 1,000 Scrap metal out. My station is NOT doing that sometimes.

I carefully watched the next cycle too and, once again only 450 Scrap Metal was produced from a 1,000 raw scrap cube. Station stats clearly show:

Product / h:
Scrap Metal 27,000
Resources /h:
Energy Cells 270,000
Raw Scrap 27,000

This is NOT what my station is doing. I'm going to continue watching it over several cycles to see if this remains true.

In summary:

- Deliveries are BETTER, with returning tugs going to distinct Processors reliably. Good.
- Tugs still only return when a Processor is free. This wastes a LOT of time. Really, my Processors are often waiting for scrap.
- Tugs become stuck and don't deliver ANYTHING if I'm in the sector.
- Processed Raw Scraps is only yielding 45% of the Scrap Metal it should be.

[BurnIt!]

There should be a 1:1 relation - are sure what was delivered was a full cube containing 1000 Raw Scrap? A cube may only be partially "filled" sometimes, and if it only contains 450 Raw Scrap then that's all you're going to get.

I also have watched my Manticores happily deliver wrecks and cubes while I'm nearby so I don't see a general problem - do you have a savegame where I can observe these difficulties your tugs seem to be having?

[Scoob]

There should be a 1:1 relation - are sure what was delivered was a full cube containing 1000 Raw Scrap? A cube may only be partially "filled" sometimes, and if it only contains 450 Raw Scrap then that's all you're going to get.

I also have watched my Manticores happily deliver wrecks and cubes while I'm nearby so I don't see a general problem - do you have a savegame where I can observe these difficulties your tugs seem to be having?

I was having some very weird issues in my game, I try to detail in better here. In summary, I'd see a single 1,000 Raw Scrap value Cube delivered. It'll be processed by one Scrap Processor over one minute, then produce 350 Scrap Metal. The Processor would become idle after that. This only happens if all three Scrap Processors are running at a time. If I allow just ONE Manticore to deliver just ONE Scrap Cube, all works exactly as expected. However, with all three working (save in my linked post) things appeared to get out of sync. For example, I'd had all three processors EMPTY and IDLE, before allowing deliveries again. Manticores would start delivering Scrap Cubes, with the Processors starting up staggered, as each Cube was delivered. I'd see the first Scrap Processor start working (1 minute count-down) then become IDLE again after that minute, depositing 450 Scrap Metal into Storage. At that moment, the other two Scrap Processors were still working (they'd not run for a minute yet) so had deposited nothing. As each Scrap Processor finished its 1 minute cycle, they'd each deposit 450 Scrap Metal, then go idle. They'd remain idle until more Scrap Cubes were delivered.

I cannot tell what's going on under the hood, so to speak, but Three Scrap Processors work very differently to a single one, at least they do for me. That 450 output Scrap Metal amount is odd, as that's what I'd expect all three (150 each) to produce each complete cycle. However, one Scrap Processor alone can be seen (in my game) producing that in one minute, while the other two are still processing. Perhaps it's a weird UI thing, with the UI not reflecting things properly and the Storage count not updating correctly. I really don't know. All I know is that it was consistent:

- Three 1,000 value Scrap Cubes delivered - one to each of the three Scrap Processors.
- Each Processor would then run for one minute, producing 450 Scrap metal each after that minute. Going idle immediately after that single, one minute cycle.
- For three scrap cubes delivered, one per processor, each would run for one minute, then go idle (not enough scrap for production)
- A total of 1,350 Scrap Metal would be added to storage after each Processor had finished and was idle again.
- Three full Scrap Cubes - total value 3,000 raw scrap - would be delivered to three scrap processors. Each processor going idle after one minute of running time.

I thought I was going crazy watching this happen in my game. I spent likely a good hour or so watching things, making notes of the numbers - metal in / metal out / number of cycles per cube - then I did isolation tests on ONE processor, allowing just ONE Cube to be delivered. The latter, the isolation test, worked PERFECTLY, all numbers adding up, it taking a full SIX cycles for the single Processor to process one Scrap Cube (with some change, picked up on the next cycle). 150 Scrap metal added per cycle. All perfect. With all three Processors running however, the number simply did not add up. Over time, counting the number of 1,000 Scrap value Cubes delivered vs. the amount of Scrap Metal added to storage, showed that only 45% of the delivered Cube value was turned into Scrap Metal.

In my post, someone was good enough to check my save. However, they didn't observe the same numbers as me. Not sure how long they watched, or if they did the same testing as me, but it did suggest something wrong with my game. Sadly, it'll likely take some time observing to check this, I was watching for at least an hour or so when I noted down the numbers.

Oh, everything does come to a halt when I'm in-sector, all deliveries stop, quite consistently. You can check my save in the linked post, to see if you observe that too.

I've not watched the Station closely in a while. I will check again when Beta 3 is out and I update the game - might update then do a file verify (GoG) just to be sure.

Note: my game is totally vanilla. I did a custom start to remove Highways and start with just a ship, no BP's an other stuff. It's my preferred slightly more difficult start.

[Scoob]

Here's a random one for you...

I have a Scrap Processor with three Scrap Processing Modules. I'd regularly see three Manticores coming in at once, as each became empty. Not long ago, I added a forth Scrap Processor Module, now I only ever see on or two Manticores returning - despite there being a dozen sat there ready with Scrap Cubes in tow - this is with up to three Scrap Processors idle.

So, going from three to four Scrap Processors actually significantly slows down deliveries of scrap. I'm going to remove that extra module and see if things revert.

[Mr.Killer]

I also have watched my Manticores happily deliver wrecks and cubes while I'm nearby so I don't see a general problem - do you have a savegame where I can observe these difficulties your tugs seem to be having?

Then either we do something wrong or you have knowledge of it that makes it work. I have my HQ equipped with a lot, keeping it operational, have 4 tugs running around like headless chicken and RIP tugs are bringing in scrap all the time while mine are over 70 km from station telling me there's nothing to do. Even when, with scrap in it's tow, showing the just detroyed SCA ship close to my station to pick that up, it does nothing.

Improvement needed here. (A savegame where you can toy around)

https://www.dropbox.com/scl/fi/ue2phmfr ... eyo4m&dl=0

So, I took control of one of them lazy b*tches and figure out what's the problem, but I'm afraid it's something I cannot solve on my own, I hope You at Egosoft can.

[Mr.Killer]

Here's a random one for you...

I have a Scrap Processor with three Scrap Processing Modules. I'd regularly see three Manticores coming in at once, as each became empty. Not long ago, I added a forth Scrap Processor Module, now I only ever see on or two Manticores returning - despite there being a dozen sat there ready with Scrap Cubes in tow - this is with up to three Scrap Processors idle.

So, going from three to four Scrap Processors actually significantly slows down deliveries of scrap. I'm going to remove that extra module and see if things revert.

I just have my stations equipped with one module, and doing it myself works better than AI pilot, who is sitting in a spot telling that it has failed to find a spot to deliver, duh! Actually this is a bug and I hope it is solved very soon.

[Scoob]

I just have my stations equipped with one module, and doing it myself works better than AI pilot, who is sitting in a spot telling that it has failed to find a spot to deliver, duh! Actually this is a bug and I hope it is solved very soon.

In v6.20, I stuck with one Scrap Processor per station, but had multiple stations right next to each other in a rich scrap area. Worked about as good as it was possible to have it work. Manticores still idled where they collected the last wreck / scrap cube though, waiting for a free slot, which slowed things down. I'd hoped they'd return right away, then hang out near the Processor for rapid drop-off once a lot was available.

With v7.0 beta, I tried multiple Scrap Processors on one station again, and it really doesn't work well. From spurious values, to 1,000 value Scrap Cube being processed in ONE cycle and only yielding 450 scrap metal. Frequently in idle state, processing nothing despite loads of queued up Manticores. Plus of course the long delay before a manticore will even try to return. All of this I was able to recreate in a save, for me at least, but others don't appear to see quite the same things as me.

[Mr.Killer]

In v6.20, I stuck with one Scrap Processor per station, but had multiple stations right next to each other in a rich scrap area. Worked about as good as it was possible to have it work. Manticores still idled where they collected the last wreck / scrap cube though, waiting for a free slot, which slowed things down. I'd hoped they'd return right away, then hang out near the Processor for rapid drop-off once a lot was available.

With v7.0 beta, I tried multiple Scrap Processors on one station again, and it really doesn't work well. From spurious values, to 1,000 value Scrap Cube being processed in ONE cycle and only yielding 450 scrap metal. Frequently in idle state, processing nothing despite loads of queued up Manticores. Plus of course the long delay before a manticore will even try to return. All of this I was able to recreate in a save, for me at least, but others don't appear to see quite the same things as me.

I think this needs serious attantion by the devs, with a lot of other mechanics-problems. I wonder why things worked fine in version 6 and all of a sudden not in version 7. How, and I try to bend my mind around it, is it possible that additions affect fine working processes so actively, it looks like every good running process is invaded by the other programming, and not a stand-alone process that works on the sideline. Well, I do not know about the programming these days, but from my gw/q/visual basic period in the eighties, I know that today programming is also modular, from top to bottom, with subroutines and all.

I do hope they fix these gremlins very soon...