SS Crash on dismantling emissive beams
Game crash on dismantling any emissive beam from SS.
Game version: 1.1.1 Stable
Mod version: Latest (As of 19-06)
125 Replies
It has been attached to this message.
-# Responding to
Crash found in FactoryGame.log
triggered by @I'm just KenIt's a known issue
This is possibly a shader cache issue, could you please verify your game files and make sure your video card drivers are up to date.
>steamverify
@Acxd {Alphabet Soup} could you unmark this as solved please
It's not marked as solved, yet
Sorry, I saw the green check, nm
Sure will do after work later today.
@r125r11 also for you buddy, see above advise 🙂
Apologies about the mark, since it was mentioned to be a known issue, I gave it a mark to not overflow the 'help' forum or repeat the same issues.
I just tried this (on Epic version) and the game still crashes
>rhiborked
There are a few things to try if your RHI is causing crashes.
1) Try switching your RHI. If you're using DX11 or DX12, switch to the other. If you're using Vulkan, try DX12 before DX11
2) Try verifying your game files.
3) Update/reinstall your graphics drivers
4) Try disabling hierarchal Z-buffer occlusion in the game's graphics settings.
5) Try tuning your graphics card's clock down, especially if has been overclocked (by you or the vendor)
For more info, run one of the following bot commands by sending it as a chat message:
>dx11
>dx12
>vulkan
>verifyepic
>verifysteam
updating to 1.1.43 did resolve in SP, @I'm just Ken can you update server and test later today?
Can update when I'm at home, don't have access to SMM at work.
Can confirm that -dx11 (on my system, AMD, Mesa, Linux) does alleviate all beam-related crashes. 1.1.43 did not fix the crashes. I had crashes with both painted metal beams and emissive beams, but with -dx11, no more crashes. Only minimal FPS drop, so I think I'll stick to it.
Didnt have the time to check over the weekend, updating client & server to 1.1.44 now to test
Client (only) crash when dismantling a blueprints that include emissive beams & solo beam dismantling on a server.
Below log is when dismantling a blueprint
It has been attached to this message.
-# Responding to
Crash found in FactoryGame.log
triggered by @I'm just KenDismanling blueprints & the beams solo, works fine when loaded into SP
With up-to-date nvidia drivers, same crash
Game settings on DX11 works fine
What about in Vulkan? Is that available on AMD?
idk I dont run AMD, my friend @r125r11 is swapping to Vulkan
Vulkan crashes
Hmm, well the only option seems to be to use DX11, but the beams wont illuminate the world in that mode. I have never gotten it to crash using DX12 so I can't reproduce it. My current assumption is that it is a video card / driver version / old shader cache / game bug with instances and nanite problem that I probably could not fix myself. I've been through the parts and verfied the only thing different from regular beams and mine is that the mesh has nanite enabled.
running on AMD Ryzen 9 platform with NVidia GPU
Hmmm, we can try what happens with a p2p server, isntead of dedicated server
I loaded the game in SP, I opened up a MP session. (without dedicated server)
@r125r11 joined my session, I've deleted a blueprint which includes the emissive beams and 'his' game client crashed, mine is still working fine.
We've had something silimair recently regarding the gantries from the 'Modular Stations', but I can't say it's the same issue or related
Baba and I also ran a test re this on both your emissive beams and mine on dedi and couldn't replicate the crash. I was curious as my beams are so similar if we could get it to crash on one and not the other, or both, but we couldn't replicate the crash at all, using DX12, both with up to date drivers and bios. One NViidia one AMD
So you have emissive beams with nanite enabled and they dont crash at all?
Yes! Haven't had any crash reports on my emissive beams & neither Baba or I have been able to get them to crash under extensive testing
And you helped me with both my emissive material, and with reenabling nanite post 1.1, so my beams should be very similar to yours, albeit smaller
how many custom data floats did you allocate in the abstractdataobject?

Also 20

Do you have mesh asigned to the inherited colored mesh proxy, or did you null it?
Yes, still have a mesh assigned to it

I've tried both, and Arch said they should be nulled, so idk
Hmmmm I am reluctant to mess with mine because they're working fine as they are and I don't want to inadvertently break things, but Arch is the authority here so idk either
na, if yours are working dont touch em
I've just updated my Git to include the changes made for 1.1 if you want to look more through my beams & see how they might diverge from yours if that'll give you more clues/help at all
https://github.com/Muppet-Burrito/Muppet-Burrito-Mods
GitHub
GitHub - Muppet-Burrito/Muppet-Burrito-Mods: Collection of Muppet B...
Collection of Muppet Burrito's Mods. Contribute to Muppet-Burrito/Muppet-Burrito-Mods development by creating an account on GitHub.
You've helped me so much, if there's anything at all I can do to help you I'm more than happy to
Thanks, I'll look through it when I get home
Sweet, hope it helps!
Just ignore Build_BeamEmis_41, it's not currently in use in the mod, I just grabbed it yesterday to test updating it for 1.1 and being lightweight for Baba as it's one of their emissive beams and I offered to help them get that mod updated to 1.1 🙂
@D4rk feel free to tag me if you want me to test something, I'm here for the next couple of hours
I went through Lights+ and compared my parts to yours. I don't see anything different on the mesh or the builder
I didn’t think there would be much if anything different bc you helped me with getting mine to work & with getting them updated for 1.1. But, it’s even more a puzzle now you’ve confirmed that, as to why yours are crashing some users sometimes & try as we might we couldn’t get mine to crash
Pardon my inexperience and lack of knowledge on modding, but just "what if" D4rk were to copy your emissive beams and add it to his mod and see how this works?
Doesn't need to be an 'official' update, just for testing purposes.
The fact that yours work fine (alegedly) but from SS mod doesn't, make me think that there is some differences that might not be visible at first glance? (Unless I'm misunderstanding something completely)
Also, love the name 😂
I just realized, we started seeing similair crashes with 'modular stations' on the last experimental update (before 1.1 release) where they did some last - minute changes to the build gun.
Both on 'selecting the hologram' and 'removing' a structure
Main difference with the emissive beam crashes, is that the client only crashes on dismantling, placing it is not a problem at all.
Server remains fine and upon rejoining the server after a client crash it has been removed succesfully.
Makes me wonder that the meshes and lights are fine as it would otherwise crash on placing them??
But then again, pardon my inexperience and lack of knowledge on modding.
Same issue here though: The crashes occur ONLY on dismantling. Not placing.
As with them, forcing DX11 worked for me. Worth a shot at least
Yes, correct. DX11 solves the issue, if you're willing to give up Nanite and proper illumination.
Another workaround (that works on Linux, via Proton, cannot test other) that works for DX12 is to mark the beam for dismantling, move away some 50 meters or so (you have to be far enough away that you CANNOT see any light spread from the beam), look away from the beam (preferably the sky) and dismantle.
So far, this has worked in about 50-75% of cases for me. I still crash sometimes, and I think that might be due to me being too close to the beam still.
But that's worth investigating.
DX11 is too much a hit on performance for me.
I switch back and forth, if I need to use the emissive beams alot I swap to DX11, otherwise it's DX12 for me.
I'm sorry I'm just seeing this now, but absolutely if it'll help I'm more than happy for D4rk to copy my emissive beams, he helped me get mine working properly in the first place!
I've testing this in my dedicated server, and I can't make it crash. I built and dismantled hundreds of beams from SS and it worked every time in DX11/DX12/Vulkan. I don't know what the problem is but not being able to reproduce it is making it very hard to fix. 😢
Some people have reported that verifying game files and updating GPU drivers did fix the problem, but not for others.
That might be why I'm not able to replicate the crash either on your beams or mine, dedi or local MP... none of them crash for Baba or me either, and that always makes for the hardest bugs to solve
But, I updated my CPU and GPU drivers and bios when my CPU fan died month or so ago, so maybe that could explain why I can't replicate the bug on my end at all either
Out of curiosity, are there any known conflicts between the below mods that we used/ installed?:
Also D4rk, my drivers are fully updates, game has been verified, but the client crash persists.
@The Toblin & @Solanum out of curiosity, are there any mods among the list below that you also use?
All mods are updated to their most recent versions.
Modular stations
Dynamic train routes
All pure nodes
Modular load balancers
SnapOn
Infinite Nudge
Fluid Extras
Glass fluid Buffer
Unicode extended
Honk back
Infinite Zoop
Flashlight settings
Upside down foundations more
Mod update notifier
Alphabet sorted Stations
Structural solutions
Universal Soft Clearance
Allow identical Buildables
No Z Fighting
Modular Load Balancer Alternates
Progressive D Depot Size
Daisy chain everything
universal swatch slots
Digby tool
HoverPack Configurator
Uninterrupted Train Belts/Pipes
Might be a long shot here, but might it be that the software that you used to make the emitting beams, are installed along with certain drivers that make this compatible and thus preventing the crashes?
I am using, from that list:
- Structural Solutions (duh)
- Dynamic Train Routes
- Infinite Nudge
- Infinite Zoop
- Mod Update Notifier
- No Z Fighting
That's about it. Have those been confirmed to be conflicting with anything here?
Not that we know of, I doubt it, but couldn't hurt to check I guess.
I am absolutely not excluding mod conflicts. In fact, when I get home, I'm gonna try a fresh install with just Structural Solutions and check. If then the crash goes away, I'll start checking individual mods. (RIP my evening, but I wanna help)
Issue is, when I play in Singleplayer with all the mods, or just SS, it works fine, no crashed in DX12.
The problem happens as soon as I dismantle a beam on the server.
That makes it even more painful to test, but I'm still going to.
Because I don't want D4rk to be ripping his hair out if the fault isn't his XD
Well, I don't want him tearing out his hair at all, but you catch my drift.
Yeah ... Setting up the server with only SS is a bit of an issue as it would mean a complete wipe ... and then hope everything works fine on adding in the save again 😂
Well, that's usually not a problem with profiles. But I'll do it. I've already had savegames switched around, so it shouldn't be a problem for me. I run my dediserver on local LAN anyway, so I have direct access.
I'll see what I can figure out.
Well, if it helps with your testing the only mods off that shared list I didn't have when testing my beams & SS on the dedi server here are:
- Dynamic Train Routes
- Mod Update Notifier
- No Z Fighting
And since I couldn't force the crash to happen chances are if there's a mod conflict you'll find it there 🙂
And that sounded disjointed and unhinged. Sorry, kinda busy IRL now, so thoughts are jumbled.
Summary:
I'll test my dedicated server with JUST SS and check. If it runs fine, I'll start adding mods, one by one, until I find the culprit.
I'll get back to this thread when I have results.
And you don't have crashes, correct? Just to make sure.
Splendid. That simplifies things.
I already suspect no z-fighting, but I also suspected infininudge and similar mods that mess with placeables, but we'll see.
Good luck, I'm leaning towards it possibly being a conflict with no z fighting myself, it seems the most likely mod to be interfering with the lightweight system, with beams and foundations all being lightweights now
The red herring in the mix is that it works with DX11 and blames nanite in the crash logs...but again, we'll see
In previous game versions beams didn't have to be lightweigts, which could explain why previous versions didn't have the crash... though the red herrings indeed being the DX 11 workaround & nanite in the logs
That is however where my speculation stops, because I have 0 experience with the inner workings of Unreal Engine 5. Anyway, gotta get back to work. I should have some results in about 5-10 hours, depending on how kind life is to me 😛
Are you on Windows-Windows (server-client), Muppet? Just to have that variable of platform as well, since I'm on Linux-Linux.
Which adds the complexity of Proton translation
Yep, running windows-windows here, which could be why we couldn't force the crash on either PC
I'm using 'Indifferent broccoli'
Client? Windows?
Okay, so initial testing:
Absolutely NO mods active, except for SS results:
- Original savegame: Still crashes immediately on deconstruction
- FRESH save: No problems. No crashes.
With "No z-fighting":
Same results
So that's...interesting. I'm now firing up a server with a fresh save, but all the mods I had before, just to see what happens
Results:
- Fresh server savegame
- ALL mods I used before (not just the potential culprits)
No crashes. (I do notice that emissive beams are not emissive immediately on loading in, you have to go to the mods menu and select Structural Solutions ONCE, and then they "pop" on)
Note: The above is only for building new beams. (So new beams will not be emissive until the menu has been visited)
So...What I suspect here is that something was wrong, either with this mod, or some other mod, and it has been fixed, but whatever is causing the crash remains in the save file.
Since I cannot get new saves to crash, no matter what I do, I suspect our old saves are just "borked" with emissive beams, but the mod itself is now fine and can't be blamed.
I dunno if you're interested in getting a save @D4rk to continue delving into this, but as far as I'm concerned, this is no longer your problem.
Ok, so sometimes when there are ‘ghost’ issues from things that have been patched & fixed but linger in saves, sometimes loading that save into SCIM and then downloading from there with no changes made is enough to fix those ghost issues
It might be worth a try to see if the save/s are salvageable
That's an idea. Thankfully, the issue isn't terrible to work around, but I'll definitely test that one.
Makes sense to me yeah, I'll keep this thread open for now until d4rk makes a decision on it.
Ty for helping out bro
It's pretty cool you guys did all those tests to figure out solutions, I appreciate it. ❤️ 🤘
I would still like to figure out the actual problem though. 😅
Yeah, If you want to DM your save, I'll load it up and see if it crashes for me.
Do you want mine as well?
I can try to make it work by disabling everything except for structural solutions?
Can also send you the smm profile if you want
You can DM me the save and I'll test it.
I'll do it after dinner (approx 2 hours)
No rush, I can't test today anyway, it would be tomorrow
No problem, I respect your agenda
Just for the record: The SCIM method was unsuccessful for me. That doesn't mean it won't work for someone else tho.
Didn't try it yet, also, gave me save and SMM profile to D4rk as well
I wasn't able to get either of your saves to crash in SP or local MP. I haven't tried it on dedi yet, but I'm guessing the result will be the same.
I can give you the IP of our dedicated server if that helps?
Thanks, I have a private test server
Are there any files I can pull from the server of your mod that might help you to analyze it?
No, I only needed the save. 😎
Alright, if you need anything, here to help 🙂
@D4rk Out of curiosity, are you using Nvidia drivers? and if so, are you also using the studio drivers? 🤔 (Aside from game ready drivers)
I'm not sure, I install whatever GeForce tells me to
That's one nice overpriced DELL u got there 😛
Hmmm... that's funny ... So I installed the Nvidia studio drivers, reverified my game files ... hopped in the server, place a 1m emissive beam, dismantled it and ... no crash.
went back to main menu & rejoined the server, I placed it again, dismantled it and ... crash.
Rebooted, rejoined server, placed & dismantlled ... no crash.
Placed a 2nd one without going back to main menu and ... crash.
I don't know anymore man 😂
Yeah, it must be some sort of hardware/driver/shader cache/hash collision issue. I think If there was a problem with the parts if would be much more consistent.
Doubt this will help, but it's a shot
Hi,
I had this issue for some days now, i just joined this server and you fixed the issue !
for Me just using Dx11 fixed it
Thank you for the help !
Ive been having the same problem running on my gportal dedicated server. Will try DX11 now and see if it crashes me again
You just mentioned the name of a hosting provider (gportal) that either does NOT support or has incomplete support for modded Satisfactory dedicated servers! Check the list here to learn more. https://docs.ficsit.app/satisfactory-modding/latest/ForUsers/DedicatedServerSetup.html#UnsupportedHosting
-# Rule logic: https://regex101.com/r/rKL6oV/
-# Responding to
unsupporteddedicatedserverhost
triggered by @UbruxJust FYI @Ubrux @Kazu , running on DX11 is a temporary fix, it also disables Lumen and reduces performance to a degree.
e.g. on our server we've build production plants for all bauxite & all caterium processing and turn our games on high-end machines into a slideshow on dx11.
Mod works fine on DX12, just dismantling causes all clients (running on dx12) in the server to crash, placing them is no problem.
We swap back and forth between DX11 when we need to work a lot with emissive beams that requires corrections. (which are in our blueprints for rails.)
I did just that, thank you! Dismantled the beams I had up and switched back to dx12. No crashes since.
@The Toblin I forgot to ask, in the other thread you mentioned that uploading/ downloading the save in SCIM might solve the issue, did you do any testing on it?
I did. I uploaded mine to SCIM, then re-downloaded it and loaded it up in my linux dedicated server, and I still experience crashes when removing emissive beams on my client, using DX12. (Like I said before though, it's only the client that crashes. The server survives and the beam is correctly removed)
So for me, SCIM did not fix it. I have given my save to d4rk so he could experiment, but my save does not crash on his server, so it's really obscure what the error is.
I do not get crashes with the new version on a NEW save. It's just my old one that already had the crashes. That one continues to crash no matter what.
Yeah I gave our save to D4rk as well to experiment, including the SMM profile.
Looks like old data is lingering in the saves and causing a conflict like you mentioned.
Time will tell 🙂
@D4rk here, is my contribution to the thread... On server I can delete Emissive beams without crashing if they are IN a BP designer?? Does that help? Some flag changes on them inside a BP designer?
Hmm, that is at least a new clue. Being inside a designer doesn't change much on the builder and doesn't change which dismantle effect is used.
throwing in my two cents - when loading a game and deleting a beam immediatly, it doesn't crash. If I then place or delete a beam, and i save the game again, and then delete another (or the same), it doesn't crash. I sometimes can delete 2 or 3 between crashes, but if I save afterward, I haven't had a crash yet after saving.
p.s. The crash also happens (sometimes) when I do clear a BP (not dimantle) that has an emissive in the bp designer.
server or solo?
Solo, i dont have a server to test with
That’s very strange indeed, I’ve never had any of the SS beams, Baba’s beams or my beams crash on solo, or on windows server, we’ve only been able to reproduce the crash here on Linux servers for the clients
immediatly after loading a game, i tried deleting about 15 bp i've placed with emissive beams (the 0.5m), tried from inside and outside the bp, looking and not looking at the beam, no crash. maybe it's related to the time that a game is running?
i deleted now a single beam, and immediate crash, after about an hour of game time.
Just to experiment, Muppet, @Mr. Fun loaded up your Lights +. And, as others have said your emissives do NOT cause a crash on delete.. so odd…
Well.. Actually not true.. I placed one of your emissives and let it sit a while, then deleted it, then it crashed.. It was a different Emissive though.. so let me experiment a bit.. Perhaps it has something to do with an incongruence with client/server, so an immediate delete doesnt crash it bc server hasnt saved it yet.. ??
Thank you for your continued tests, this is one of the more puzzling bugs so all of your assistance getting to the bottom of things is hugely appreciated! And this is a rather interesting lead, thank you!
Its slightly funny, because like I was saying this is a new 1.1 world/build on our server, and when I am planning out a build I place ALOT of (mostly blueprinted) stuff around to sorta sketch out an idea.. So I have tons of emissives to delete (thank God mostly in large BPs).... So I have a new way of closing the game when I am done, I just pick one of those darn things that need deleting and, Voila! Desktop! lol
It's a super strange one, but you've all given us some clues and Baba and I finally have access to a Linux server to test things so we are on the case!
There's definitely something there about how long the beams have been built for, and our best guess so far is that now all of the beams have been migrated to being lightweights the game is struggling to turn beams with lumen/nanite enabled back from lightweights to regular buildables on dismantling
But, now that most of our emissive beams are crashing on dedi with Linux, too, and we have a Linux server to test on, we can at least reliably replicate the crashes most of the time, and we have lots of clues from y'all and your testing, as well
@Baba_booie{Crazy BP Workarounds} and I are on the case, and while it's taking us a while to get to the bottom of things I can assure you that we will get to the bottom of what's going on and figure out how to fix it as soon as we can, there isn't a puzzle or bug we've not been able to solve yet, especially when we put our heads together!
I'll keep y'all updated as soon as we've more answers and a permanent fix!
Muppet, you are my hero! Amazing! Thank you guys so much for your work on this!!
I mean look a this build.. Scary to think that each one of those glowy beams if deleted means a client crash!

@Baba_booie{Crazy BP Workarounds} is the one who deserves credit for finding the workaround, though it does have the unfortunate side-effect of disabling lumen for the mods. Hopefully once CSS get back from holidays they'll be able to give us the missing pieces we need for a more permanent fix that also allows the lumen to shine!
But, for now we have a hotfix that won't crash the beams on Linux Dedi, thank you Baba! :hypers: :peepoClap:
Muppet, any thoughts on when SS may get the same fix? Or alternatively, can you add way larger emissives to Lights + ?? 🙂
dam it still seems to be crashing even after the hotfix. let me know if i can provide any other detals
Hmm which emissive beams were still crashing, are those my beams, Baba's beams or the SS beams?
I don't know if SS will get the same patch because it's such a drastic fix (it means disabling lumen for our entire project), but I could make some larger beams as long as they're not the same as the SS ones.
I could do some larger rectangle beams if that would help, maybe a .5m x 1m, 1m x 2m, & 2m x 4m, that way they're still different enough to the SS beams that I'd feel ok about it
We're all still hoping that CSS will pop in after they all return from break to tell us the 'one simple thing' that will actually allow stable dismantling of lightweight buildables with lumen for clients on linux servers post 1.1, because having to disable lumen for the whole project is far less than ideal
It was the SS emissives
Ahh, I don't think those ones had the patch applied, and I don't know if D4rk is planning on it due to it being such a drastic work-around
Ahh good to know. Sounds like disabling lumen temporarily will allow me to delete em
Hopefully, that or switching to DX11 should do it 🤞
Another small bit of info is that Andre’s “more beams” emissives don’t cause a crash.
I think that's because, at least the last time I checked, his beams aren't lightweights
So, they count towards the UObject amount, but don't crash on Linux servers
Deleting those beams I discovered a detail that may be of use, still on the the SS beams, but maybe still relevant - it only crashes on emissisve beams that were put in place via blueprint, it did not crash on deleting originals. if that makes sense
Lumen disabled
Hi D4rk, it's been a while.
I never mentioned this, but our crash occurred from deleting emissive beams that are placed via a blueprint.
@r125r11 Do you remember if the crash happens on removing beams that were placed manually?
Yes, the crashes happened regardless of the type of placement.
I don’t think it has anything to do with them coming from BP or manual creation…. It does matter how long the beam has existed on the server. If you make one and immediately delete it doesn’t crash. I think @Muppet Burrito said they had figured out that it has something to do with the game trying to convert the beams to lightweight objects….
Yeah my best guess at this point is that it’s something going wrong when the game tries to convert the beams back from lightweight objects to normal buildables for deletion, but only for clients on Linux servers.
Which is why sometimes if the beam is deleted immediately it might not crash. But, it would be great to know from CSS what’s actually causing it & what setting we need to apply to actually fix it, as the vanilla game has lightweight buildables with emissives you can delete fine without crashing so clearly there’s something else we need to do to make it work properly that we don’t know about