PipeLine Overload

[Dreugui]

So, I was trying this mod, and when I put pipeline in BP to speed up the setup. each time I put a BP it recalculate ALL the pipeline it conects to ! and so after 2-3 Bp connected, the FPS drops and the game lagg heavily. is there somthing to avoid the heavy load off recalcul ? EDIT: so it's not only the pipe, it's all that is linked. I suppose that's what use the mods to autolink with BP. problem so, if I put like 4-5 BP to quickly my game crach :/

[PeteCondliffe]

I haven't even tried this mod yet but seems something that really should be in the core game. A workaround could be to design your blueprint with a join in the pipe in the middle. That way when it joins its only joining from center to center on each blueprint placed.

[Epp-code]

Hi Dreugui, thanks for the report. Is the problem that the game temporarily drops framerate or that it drops and stays low? It would not totally surprise me to hear that it stays low for pipelines/fluids because I had to experiment to get those to work and there could definitely be gaps in the logic that only get exposed at scale, so I will go look into it today.

But I would be very surprised if you see sustained lag from building anything non-fluid, as the mod leaves the other types of connections linked the way the game would naturally link them (at least, as far as I've been able to tell). It really shouldn't have any lasting performance impact. I've built very large, over-sized rail blueprints with the mod and I do a see a temporary dip in FPS but it seems to be primarily related to the blueprint itself building, not the linking part, as it returns to normal after all the animations. The linking may cause an extra hitch on the single frame that the blueprint is set down but any lag after that, I'd expect to be normal game lag.

[Dreugui]

The main problem come from the fact that each time I add a BP, it regenerate ALL the belt linked to it, and since I have a really long belt, it makes the game crach if I put ANY more BP. but I found a work around. if insted of puting the BP a the "begining" of the belt you put it at the "end". it dosent regenerat the full belt and there is no problem. but I it's really anoying. precision : The drops of FPS is because of the heavy load of calcule that is generated by the regeneration of the belt. Yes it lags when you put a BP normaly but with the mods it agravate the things like A LOT

[Epp-code]

So when you say "crash", does the game actually quit and present a crash dialog (in which case, please share the stack trace)? Or do you mean it lags a lot and takes a while to recover?

How many belts do you have in your blueprint that are being attached to other long belts? And how long are those belts? If you manually build them one at a time without any blueprints, do they lag as they get really long? I am just simulating adding a belt like I see the game add a belt when you snap and manually place it - the game itself decides when it has to regenerate the full belt. The biggest difference with the mod is I do it for all belts in the blueprint at the same time. So if it's just one belt, I wouldn't expect any significant performance difference from what the base game does and I'd like to understand if that's the case.

[Dreugui]

I only put like 3 BP Fatal error: [File:C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\D3D12RHI\Private\D3D12Util.cpp] [Line: 903] Interfaces.CopyCommandList->Close() failed at C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\D3D12RHI\Private\D3D12CommandList.cpp:284 with error E_INVALIDARG

0x00007ffc60c76c06 FactoryGameSteam-D3D12RHI-Win64-Shipping.dll!D3D12RHI::VerifyD3D12Result() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\D3D12RHI\Private\D3D12Util.cpp:903] 0x00007ffc60be68b7 FactoryGameSteam-D3D12RHI-Win64-Shipping.dll!FD3D12ContextCommon::CloseCommandList() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\D3D12RHI\Private\D3D12CommandContext.cpp:326] 0x00007ffc60be675c FactoryGameSteam-D3D12RHI-Win64-Shipping.dll!FD3D12CommandContext::CloseCommandList() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\D3D12RHI\Private\D3D12CommandContext.cpp:340] 0x00007ffc60c01ea5 FactoryGameSteam-D3D12RHI-Win64-Shipping.dll!FD3D12ContextCommon::SignalSyncPoint() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\D3D12RHI\Private\D3D12CommandContext.cpp:225] 0x00007ffc60c17674 FactoryGameSteam-D3D12RHI-Win64-Shipping.dll!TRHILambdaCommand<FRHICommandListBase,FD3D12DynamicRHI::RHIWriteGPUFence_TopOfPipe'::2':: >::ExecuteAndDestruct() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\RHI\Public\RHICommandList.h:471] 0x00007ffcae006b8a FactoryGameSteam-RHI-Win64-Shipping.dll!FRHICommandListBase::Execute() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\RHI\Private\RHICommandList.cpp:457] 0x00007ffcae000688 FactoryGameSteam-RHI-Win64-Shipping.dll!FRHICommandListImmediate::QueueAsyncCommandListSubmit'::50'::::operator()() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\RHI\Private\RHICommandList.cpp:668] 0x00007ffcae006b8a FactoryGameSteam-RHI-Win64-Shipping.dll!FRHICommandListBase::Execute() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\RHI\Private\RHICommandList.cpp:457] 0x00007ffcae0005bd FactoryGameSteam-RHI-Win64-Shipping.dll!FRHICommandListImmediate::ExecuteAndReset'::18'::::operator()() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\RHI\Private\RHICommandList.cpp:773] 0x00007ffcae007a7b FactoryGameSteam-RHI-Win64-Shipping.dll!TGraphTask<TFunctionGraphTaskImpl<void __cdecl(void),0> >::ExecuteTask() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\Core\Public\Async\TaskGraphInterfaces.h:1266] 0x00007ffc6b87ec9e FactoryGameSteam-Core-Win64-Shipping.dll!FNamedTaskThread::ProcessTasksUntilQuit() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\Core\Private\Async\TaskGraph.cpp:648] 0x00007ffc6d88f04f FactoryGameSteam-RenderCore-Win64-Shipping.dll!FRHIThread::Run() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\RenderCore\Private\RenderingThread.cpp:329] 0x00007ffc6bb05b2e FactoryGameSteam-Core-Win64-Shipping.dll!FRunnableThreadWin::Run() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\Core\Private\Windows\WindowsRunnableThread.cpp:149] 0x00007ffc6bb01df1 FactoryGameSteam-Core-Win64-Shipping.dll!FRunnableThreadWin::GuardedRun() [C:\BuildAgent\work\b731a33f2a691e17\UE4\Engine\Source\Runtime\Core\Private\Windows\WindowsRunnableThread.cpp:79] 0x00007ffcf0cfdbe7 KERNEL32.DLL!UnknownFunction []

Crash in runnable thread RHIThread

[Dreugui]

So without the mods I can do things like this, the game lag but its ok

[Dreugui]

When I don't use the mods I do BP like this I have a hole in the midle, put a bunch of BP, then link one by one ALL the belt beetwin all the BP and it take A LOT OF TIME, thats why your mod is like GOLD ! here is my belts, I put a red line beside "one long" belt, on my bridge.

[Epp-code]

Huh, thanks for posting that stack trace. That's so far outside of the code paths I've modified that I have no idea what could be causing that crash. Clearly it's something the mod is doing since it doesn't crash otherwise but I'm at a loss for what or how to investigate it.

Those are some impressive screenshots and it looks like you're pushing everything to the limit. Out of curiosity, are you using a modified blueprint designer to build bigger blueprints? Shouldn't matter for functionality but could be adding extra load when my mod runs.

You might already be doing this but I'd try making smaller blueprints, like maybe just one row of conveyors at a time to see if that helps.

Also, be sure you've updated to the latest version as of last night. I added some bits of optimization so the mod won't try to scan things like foundations to see if they can be linked.

[Dreugui]

No, No, it's a classic BP 5x5 (no OOB). On the screen each "pilar" is ONE BP, on the screen it"s like 10 BP beeing constructed at the same time.

[Dreugui]

And has I said, the problem occur only if I put the BP, at the "back" of the belt. if i put it at the front I can go CRAZY, no crash

[Epp-code]

Got it, that's interesting. Ok, then weirdly have you tried making a bigger BP? If each pillar is one BP, then that's a lot of belt recalculation and linking that has to happen on each click. Behind the scenes, the game has an invisible "super belt" (they call it a conveyor chain actor) that virtually links every connected, individually-built belt segment and (I believe) handles item movement. Every time you connect a new belt, I'm pretty sure (from code comments and some game analysis) that the ENTIRE super-belt is FULLY recalculated. I would have expected they would just add another node in the super belt because what they do now gets WILDLY inefficient as the belt gets super long. Perhaps they actually do the efficient thing in the case that's working for you now, but the fewer total segments you can put in a belt, the faster the rebuilding should go.

[Dreugui]

Fun fact, I learned the existence of OOB for blueprint this morning XD. and no havent tried because it as no prupose, since you cant connecte belt outside the bound, and my biggest problem IS the linking of belt

[Epp-code]

Just cleaning up the ticket. Conclusion: the extreme lag here seems to be a consequence of internal game logic that I can't control, but I'm glad there's a workaround. The crash is a mystery to me and I don't know how to investigate since it's nowhere near the mod code. If anybody comes across this and has any ideas, I'm always open to hearing them.