EyeDeck
Active Member
- Messages
- 123
This is the first I'm hearing of anything like that. USS doesn't really do anything that the workshop daily update function doesn't do, so I don't see why objects stored in the workbench would make any difference.
the Sim Settlements forums!
Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
Resolved Swapped Settlement Plans
- Thread starter Bcomninellis
- Start date
BubbaGump2k
New Member
- Messages
- 7
i think ive run into this problem too...upon getting to Country Crossing i picked a leader and a plan but it never did the thing where it zooms out and shows things being built...instead I stood still and it happened all around me...since then the CPD reads as The Castle and it reset the progress i had on the real Castle and in attempt to fix the problem i selected self destruct for Country Crossing but only half the stuff got removed and now when I try to fast travel to The Castle it brings me to Country Crossing lol...im gonna try some of the solutions in this post and hope for the best
- Messages
- 5,184
@BubbaGump2k Try scrapping any fast travel mats at either settlement. I wonder if somehow the fast travel mat became attached to the wrong settlement.
BubbaGump2k
New Member
- Messages
- 7
well I felt like everything I tried just made things worse so I uninstalled everything...mods and the game lol...I'm gonna start fresh again someday...just out of curiosity is there a limit on how many settlements I should be building up at once? specifically with the rotc auto building stuff?
thanks for all your hardwork though @kinggath
thanks for all your hardwork though @kinggath
Last edited:
- Messages
- 5,184
Theoretically, there is no limit. I would highly recommend setting City Upgrades to manual though. It's pretty unlikely that multiple cities would upgrade at the same time on Auto, but if they did, it would probably be hell on your system.
BubbaGump2k
New Member
- Messages
- 7
I'm wondering if that was the problem I had like 10 places set up to build on their own and I think I did have auto upgrades on...I'm not very smart so there was some settings I didn't know how to set lol oh well
BubbaGump2k
New Member
- Messages
- 7
no i never had any crashing...just that problem that ruined The Castle and Country Crossing :D
but its cool I hadn't played since 2016, came back specifically cause I heard how cool this Sims Settlements stuff was...i probably just messed up a setting somewhere
- Messages
- 1,678
Here's a thread where Kinggath talks about the effects:
https://www.simsettlements.com/site...end-or-low-end-pc-enough-to-run-ss-rotc.4738/
EyeDeck
Active Member
- Messages
- 123
I assume you're referring to
The reason that surplus generation is limited, I suspect, is partially a balance thing, where Bethesda didn't really want you to generate practically infinite resources (and thus infinite money once you take them to a vendor), so the surplus cap thing at least makes you work for it a bit... I think they could've achieved that in a better way, though, since masses of farms and water purifiers totally destroy the game economy either way. The other is probably because they realized that uncapped resources cause the attack system to trigger too frequently, and in typical Bethesda fashion they couldn't be bothered to rewrite the appropriate scripts to work more sanely, so stuck a band-aid on it.
I hold that there's absolutely no reason why USS would ever cause crashes as a result of spawned items. It's on the script-heavy side, however, and by way of how it functions it can potentially cause a thread to simultaneously spawn for every settlement you have, if you time a really long sleep or fast travel just right, and that might destabilize the game engine. It won't cause any pseudo-corrupty crashes where a settlement just has too many item types or whatever and will crash when you get near it, because by nature of the design it can only spawn, like, a few dozen different unique item types, and none of these items are scripted.
Also, I'm going to open a UFO4P report about the shipment thing tomorrow, since I'm too tired to do it now
Per Bethesda's usual methods, they "fixed" the bug in the stupidest way possible, and introduced an even worse bug in the process. I can think of a few ways to make this work as intended without just commenting out this feature, and this will also clear up any problems arising from shipments in workbenches, since they just won't be able to go into workbenches (as originally intended).
This is completely untrue; when we're talking about unscripted items (which is basically everything that isn't a quest item or a shipment), there is practically no functional difference between having 1 of a particular thing in your workbench, or 50,000. Shipments are an exception, because they have a (completely nonfunctional) script attached to them, which makes the game treat each shipment as a different "stack". Ergo, having 50,000 shipments is equivalent to having 50,000 individual item types, while having 50,000 corn, provided those items had no special data attached (ownership etc), would internally be stored as just one item type.
The reason that surplus generation is limited, I suspect, is partially a balance thing, where Bethesda didn't really want you to generate practically infinite resources (and thus infinite money once you take them to a vendor), so the surplus cap thing at least makes you work for it a bit... I think they could've achieved that in a better way, though, since masses of farms and water purifiers totally destroy the game economy either way. The other is probably because they realized that uncapped resources cause the attack system to trigger too frequently, and in typical Bethesda fashion they couldn't be bothered to rewrite the appropriate scripts to work more sanely, so stuck a band-aid on it.
I hold that there's absolutely no reason why USS would ever cause crashes as a result of spawned items. It's on the script-heavy side, however, and by way of how it functions it can potentially cause a thread to simultaneously spawn for every settlement you have, if you time a really long sleep or fast travel just right, and that might destabilize the game engine. It won't cause any pseudo-corrupty crashes where a settlement just has too many item types or whatever and will crash when you get near it, because by nature of the design it can only spawn, like, a few dozen different unique item types, and none of these items are scripted.
Also, I'm going to open a UFO4P report about the shipment thing tomorrow, since I'm too tired to do it now
Code:
;/
BUG 89856: Removing exploit for getting ulimited scrap
Event OnContainerChanged(ObjectReference akNewContainer, ObjectReference akOldContainer)
; When shipments are dropped in a workbench, do stuff
if ( akNewContainer.HasKeyword(pWorkbench_General) )
akNewContainer.AddItem(ScrapMisc, nAmount) ; Add some scrap components
akNewContainer.RemoveItem(pShipment)
endif
EndEvent
/;
Last edited:
- Messages
- 1,678
Then the question arises on how having many scripted objects in the workbench could impact game play? - inducing stuttering, slowdowns and eventual crashing.
Not having those items in the bench means no problems.
You're right, it doesn't make any sense but nonetheless, this is testable and repeatable behavior and I suspect it's been the root cause of more than a few issues.
This isn't limited to shipments.
I'd like to get @kinggath to weigh in here on this because he's both done more research on it and has been in closer contact with the testers that found the issue and made a dent in figuring out the root cause.
Not having those items in the bench means no problems.
You're right, it doesn't make any sense but nonetheless, this is testable and repeatable behavior and I suspect it's been the root cause of more than a few issues.
This isn't limited to shipments.
I'd like to get @kinggath to weigh in here on this because he's both done more research on it and has been in closer contact with the testers that found the issue and made a dent in figuring out the root cause.
EyeDeck
Active Member
- Messages
- 123
It depends on how many items stacks it takes before the game engine can't effectively handle it. I'll reiterate that any item with a script attached will never stack inside of a container, which is the source of the problem. It makes perfect sense why this happens, long lists take more time to process than short lists, and take up more memory etc.
This is limited to shipments, unless you have lots of other scripted items, or items with hidden metadata that might stack weird. It is completely unfounded to say that a totally inert item, like a piece of food or bit of normal scrap or whatever has any more impact when you have 1 item or 1 million items in a container, there is no difference between these two cases in memory other than a stack size variable being different.
This is easy to test yourself; select a container in the console and spam this command a bunch until you have millions of components:
additem 248aaf 1000
For good measure, spawn in millions of crops too, e.g. enter:
help "crops" 4 flst
(to find Sim Settlement's crop list), then enter
additem xx004f31 32000 (adjusting xx with whatever Sim Settlement's load order ID is)
Spam that a hundred times too. You'll notice that there is absolutely no performance impact from doing this. Try the same thing with shipments, however, and you'll probably crash your game.
There are some exceptions to this, for example if you pick up some ammo with ownership data on it saying it belongs to some faction or another, this ammo will form a different stack in a container from the rest of your unowned ammo. So, you might have a stack of 20,000 totally normal fusion cells, and a second stack of 400 fusion cells which were originally stolen from the Brotherhood, but the inventory interface abstracts this away so you can't readily tell. Other "hidden" stacks would include persistent references, moddable items where object mod data might be stored in a different order internally (like, the sights are in the mod data list after the muzzle brake on one item and reversed on the other or whatever, but all the mods are the same so it looks like it stacks), items that had extra keyword data added to them by a script, and probably some other things I don't know about or can't think of.
This also means that if you spawn in 1,000,000 items in exactly the same way, and they're the same base item type, the base item does not have an associated script, and they aren't coming from a leveled list that might be adding metadata to the item, they will all go into the same stack, and cannot cause performance issues. This applies to, for example, any item spawned by the vanilla surplus system, or by my mod, Uncapped Settlement Surplus.
I will note that the game can have issues when stack sizes exceed 32768, because Bethesda can't seem to decide if item stacks should behave as signed shorts, unsigned shorts or unsigned ints. From experience, it seems that the console uses signed shorts, the inventory interface and most Papyrus functions (the native C++ code, anyway) use unsigned shorts, and containers use unsigned ints. For example, if you try moving exactly 65537 items in one go using the container interface or Papyrus's RemoveItem function, it'll cause a variable overflow and only 1 item will be moved, the other 65536 items being voided. This is an unrelated issue, however, and not one that can cause crashes.
On the topic of the last paragraph, I realize that there are some functions in my Logistics Station mod I'm going to need to rewrite slightly to take this into account, since some of the current functions (currently) can potentially cause item loss when you have very large item stacks. That's easy to do, but I hadn't ever considered it before.
Update: Here's my UFO4P report about the ShipmentScript issue, in case anyone is curious. That should keep the most common source of this issue from cropping up, provided that my proposed fix is integrated, and users have UFO4P.
This is limited to shipments, unless you have lots of other scripted items, or items with hidden metadata that might stack weird. It is completely unfounded to say that a totally inert item, like a piece of food or bit of normal scrap or whatever has any more impact when you have 1 item or 1 million items in a container, there is no difference between these two cases in memory other than a stack size variable being different.
This is easy to test yourself; select a container in the console and spam this command a bunch until you have millions of components:
additem 248aaf 1000
For good measure, spawn in millions of crops too, e.g. enter:
help "crops" 4 flst
(to find Sim Settlement's crop list), then enter
additem xx004f31 32000 (adjusting xx with whatever Sim Settlement's load order ID is)
Spam that a hundred times too. You'll notice that there is absolutely no performance impact from doing this. Try the same thing with shipments, however, and you'll probably crash your game.
There are some exceptions to this, for example if you pick up some ammo with ownership data on it saying it belongs to some faction or another, this ammo will form a different stack in a container from the rest of your unowned ammo. So, you might have a stack of 20,000 totally normal fusion cells, and a second stack of 400 fusion cells which were originally stolen from the Brotherhood, but the inventory interface abstracts this away so you can't readily tell. Other "hidden" stacks would include persistent references, moddable items where object mod data might be stored in a different order internally (like, the sights are in the mod data list after the muzzle brake on one item and reversed on the other or whatever, but all the mods are the same so it looks like it stacks), items that had extra keyword data added to them by a script, and probably some other things I don't know about or can't think of.
This also means that if you spawn in 1,000,000 items in exactly the same way, and they're the same base item type, the base item does not have an associated script, and they aren't coming from a leveled list that might be adding metadata to the item, they will all go into the same stack, and cannot cause performance issues. This applies to, for example, any item spawned by the vanilla surplus system, or by my mod, Uncapped Settlement Surplus.
I will note that the game can have issues when stack sizes exceed 32768, because Bethesda can't seem to decide if item stacks should behave as signed shorts, unsigned shorts or unsigned ints. From experience, it seems that the console uses signed shorts, the inventory interface and most Papyrus functions (the native C++ code, anyway) use unsigned shorts, and containers use unsigned ints. For example, if you try moving exactly 65537 items in one go using the container interface or Papyrus's RemoveItem function, it'll cause a variable overflow and only 1 item will be moved, the other 65536 items being voided. This is an unrelated issue, however, and not one that can cause crashes.
On the topic of the last paragraph, I realize that there are some functions in my Logistics Station mod I'm going to need to rewrite slightly to take this into account, since some of the current functions (currently) can potentially cause item loss when you have very large item stacks. That's easy to do, but I hadn't ever considered it before.
Update: Here's my UFO4P report about the ShipmentScript issue, in case anyone is curious. That should keep the most common source of this issue from cropping up, provided that my proposed fix is integrated, and users have UFO4P.
Last edited:
- Messages
- 5,184
The issue I was referring to is with non-component junk. If you add a ton of 246EE7 (the list of companion chatter junk items) to a container, you'll first find that your game locks up for several minutes, if not crashes outright.
Doing so to the workbench will make entering and exiting workshop mode almost certainly crash your game.
Doing so to the workbench will make entering and exiting workshop mode almost certainly crash your game.
- Messages
- 1,403
Well... I can tell you one thing from experience.
You dump a million (non scripted) items in to the workshop workbench it will cause issues. It's not how they stack, or whatever it's called. It's how the engine deals with them when accessing them in the "workbench". Key here is "workshop workbench"
You can do the same thing to any other "container" and not have issues. Why? My non coding guess.. the engine isn't trying to breakdown all that junk to "use" for building materials.
You dump a million (non scripted) items in to the workshop workbench it will cause issues. It's not how they stack, or whatever it's called. It's how the engine deals with them when accessing them in the "workbench". Key here is "workshop workbench"
You can do the same thing to any other "container" and not have issues. Why? My non coding guess.. the engine isn't trying to breakdown all that junk to "use" for building materials.
EyeDeck
Active Member
- Messages
- 123
There's something special about those specific items, in that case. There's likely some script listening for container change events for items in that form list, which is the cause of the freeze and possible crash when the game tries to spawn thousands of Papyrus threads at once. It's also possible that at least one of the items in that form list have an attached script, but I'll admit that I can't find any if that's the case.
To prove this, look at this:
http://idek.chir.uno/fo4/Fallout 4 Screenshot 2018.03.21 - 13.13.04.01.png
I made a copy of every single non-scripted misc item in the game and added them all to a form list, then added 32000x that form list to a workbench via the console like 50 times. Result? Almost no performace impact. Crafting menus and entering/exiting workshop mode are a little slow (maybe a quarter of a second hitches here and there), but it's still fully playable, and also exactly what I would expect to happen when a workshop has 1700ish unique item stacks in it. Additionally, if you try only adding that form list exactly once, and not over 1 million times, performance is exactly the same.
http://idek.chir.uno/fo4/testjunklist.esp
I welcome you to try this yourself, type "help itemtest 4 flst" to get the form ID and try adding it to a workbench with the console. I stand by what I said that raw item count does not make a difference, stacks are what's important here. The reason why shipments are slow, in particular, is that each item count constitutes a separate stack, which will contribute lag.
To prove this, look at this:
http://idek.chir.uno/fo4/Fallout 4 Screenshot 2018.03.21 - 13.13.04.01.png
I made a copy of every single non-scripted misc item in the game and added them all to a form list, then added 32000x that form list to a workbench via the console like 50 times. Result? Almost no performace impact. Crafting menus and entering/exiting workshop mode are a little slow (maybe a quarter of a second hitches here and there), but it's still fully playable, and also exactly what I would expect to happen when a workshop has 1700ish unique item stacks in it. Additionally, if you try only adding that form list exactly once, and not over 1 million times, performance is exactly the same.
http://idek.chir.uno/fo4/testjunklist.esp
I welcome you to try this yourself, type "help itemtest 4 flst" to get the form ID and try adding it to a workbench with the console. I stand by what I said that raw item count does not make a difference, stacks are what's important here. The reason why shipments are slow, in particular, is that each item count constitutes a separate stack, which will contribute lag.
Last edited:
- Messages
- 5,184
Before posting this, I double-checked my old findings and added 32000 of 246EE7 to several workbenches, waited for the initial load to be over and then entered and exited workshop mode. Each time the game crashed after several minutes.
I've done a lot of testing myself on this and concluded that junk items which can be broken into components are a problem when added in excess to the workbench. Even after the threads have completed and the workbench is loaded with those items - the game will take 10 to 15 seconds to enter workshop mode and often crash the game. Verified this on three different PCs of various power, each with virtually no mods installed.
My conclusion was that the method Bethesda used to determine how many of each item can be built in workshop mode is poorly written.
I've done a lot of testing myself on this and concluded that junk items which can be broken into components are a problem when added in excess to the workbench. Even after the threads have completed and the workbench is loaded with those items - the game will take 10 to 15 seconds to enter workshop mode and often crash the game. Verified this on three different PCs of various power, each with virtually no mods installed.
My conclusion was that the method Bethesda used to determine how many of each item can be built in workshop mode is poorly written.
EyeDeck
Active Member
- Messages
- 123
Can you explain why I'm having zero issues trying the same thing with copied versions of the exact same items, plus like 1000 unrelated items? There's some computational "baggage" here, I agree, but my previous test points to it not having anything to do with the component tally code, and instead there being something else at play here that's causing the problem.
- Messages
- 5,184
I really can't tell you - there are tons of instances where different hardware can have vastly different results, especially in Bethesda games, for no obvious reason. For example, on my office computer, I can run all of Sim Settlements features without issue. On my gaming PC, which has a substantially better processor and video card, it crashes if I have Cinematic Mode turned on - even when I have the graphic settings identical.
All of the computers I have available to me are able to reproduce this problem. woodfuzzy is the one who originally brought this to my attention, so he has obviously been able to verify it.
All of the computers I have available to me are able to reproduce this problem. woodfuzzy is the one who originally brought this to my attention, so he has obviously been able to verify it.
EyeDeck
Active Member
- Messages
- 123
The thing is, I get issues when I try adding the 246ee7 formlist too, however the "fresh" form IDs I created to see what would happen do not cause issues, even with literally hundreds of millions of items that have components in the same workshop container.
Edit: I found the scripted item in the 264ee7 form list, as I suspected. It's PowerRelayCoil, formID 91fde, at index 283. Remove it from the form list and you can add 246ee7 as many times as you like with no issues. Refer back to my statements about shipments and container item stacks, except with this item it's much worse because the script it runs is extremely heavy when compared to the shipments (which have a script that does literally nothing).
Image link: http://idek.chir.uno/fo4/Fallout 4 Screenshot 2018.03.21 - 14.29.35.53.jpg
Edit: I found the scripted item in the 264ee7 form list, as I suspected. It's PowerRelayCoil, formID 91fde, at index 283. Remove it from the form list and you can add 246ee7 as many times as you like with no issues. Refer back to my statements about shipments and container item stacks, except with this item it's much worse because the script it runs is extremely heavy when compared to the shipments (which have a script that does literally nothing).
Image link: http://idek.chir.uno/fo4/Fallout 4 Screenshot 2018.03.21 - 14.29.35.53.jpg
Last edited:
- Messages
- 5,184
This original issue came up when we were testing Industrial Revolution. Since I introduced a means of manually generating resources, I was concerned that the junk cap might have been put in for technical reasons. I brought the idea up with the testers to try overloading the workbench with items to see what would happen - as soon as I mentioned it, woodfuzzy explained that there would definitely be problems and showed me what appeared to be a vanilla issue.
So the first time I ever saw this wasn't with 246ee7, that was just what I happened to choose today to verify, as I knew it had a good assortment of component junk items. Given how slowly IR buildings generate resources, and how high you actually had to push your resource counts up before it became an issue - I decided not to worry about it at the time.
I haven't looked at how your logistics mod is handling all of this sort of thing, but I'm assuming it must be moving a lot of items into the workshop - did someone suggest your mod was a cause of crashing?
This is most likely a non-issue for many folks, but it's worth knowing about for the rare person that is struggling with un-explainable crashing. If this turns out to be the cause, it's an easy fix. We had someone recently that this turned out to be the case (or at least appeared to be) https://www.simsettlements.com/site...end-pc-enough-to-run-ss-rotc.4738/#post-36538
I wish this stuff was more consistent, as a coder, it seems completely illogical that results could vary this much. It's especially infuriating when I can't replicate a problem (my white whale is the scrap crash). Makes it near impossible to explain, much less try and fix these things.
So the first time I ever saw this wasn't with 246ee7, that was just what I happened to choose today to verify, as I knew it had a good assortment of component junk items. Given how slowly IR buildings generate resources, and how high you actually had to push your resource counts up before it became an issue - I decided not to worry about it at the time.
I haven't looked at how your logistics mod is handling all of this sort of thing, but I'm assuming it must be moving a lot of items into the workshop - did someone suggest your mod was a cause of crashing?
This is most likely a non-issue for many folks, but it's worth knowing about for the rare person that is struggling with un-explainable crashing. If this turns out to be the cause, it's an easy fix. We had someone recently that this turned out to be the case (or at least appeared to be) https://www.simsettlements.com/site...end-pc-enough-to-run-ss-rotc.4738/#post-36538
I wish this stuff was more consistent, as a coder, it seems completely illogical that results could vary this much. It's especially infuriating when I can't replicate a problem (my white whale is the scrap crash). Makes it near impossible to explain, much less try and fix these things.