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!

ResourceManager code bugs and potential fixes

Weird, I wonder if there is something about QUST that is different from other objects... If a child script is attached to the same quest as the parent, the properties show as not set in the CK, but they are defined in xEdit. If I put the child script on a new quest the properties are not inherited...
test.jpg
 
When I put the new script on the same quest the properties were not in XEdit, I had to copy them across (then it worked). When I went back into the creation kit, some still weren't filled. I'm just hoping they don't affect it at this point ... :unknw
 
I've been working on this for a few hours, and I'm finding so many problems with the HUD, that I'm focusing there first. If the data isn't displaying correctly, it's going to put us chasing some wild geese. Will post a build once I get those issues resolved and it should help in trying to troubleshoot the remaining issues.

In addition, I can see a strong need for a "Recalculate Everything" tool, so we can force a re-evaluation. Obviously it doesn't help with stored resources, but at least a method of cleaning up and correcting the daily changes would be valuable.

I'm also thinking a "Reset Virtual Resources" tool to just set everything to 0 would be valuable as a kind of nuclear option. Combine that with "Recalculate Everything", and people could wander settlement to settlement getting an opportunity to correct all of the built up calculation errors that may have piled up throughout the save's life.
 
I used some code debugging (read : hacking) to get the actual stored variables rather than reading off the HUD, but I agree there are problems with the HUD (and the info box and potentially the ASAM reports, as I've detailed in another thread).
I think the actual raw resource values might be correct (although skewed heavily if you have run out of storage space and that problem has started), so the actual totals could just be re-evaluated from those.
Once the totals are corrected, rather than resetting to 0, would it work if users changed the scrap category to just scrap, then back to components? Doesn't it then redistribute the scrap into the raw resources using an algorithm that spreads them out? If not, maybe an algorithm to do that could be created rather than, or in addition to, the 0 nuclear option.
 
I believe I found the issues now - in my test settlements for each of the complexity levels, all of the numbers matched up perfectly across multiple in-game days. I have not yet had a chance to test networked settlements, but presumably there will be no issue since the code simply queries each networked settlement for the same data it grabs for an individual settlement and adds it all together.


We had three major problems:

1. The HUD was fetching production numbers twice for plots in multiple places.

2. The plots were not recording their operating costs for the HUD at the Category and Scrap complexities, so the HUD and actual consumption of those costs would only work correctly if playing in Component Complexity, and even then the HUD would get out of sync since the category and scrap levels were not being updated as well.

3. Then we have the worst offender, plot production was being done multiple times. 2 x at the Category level, and 4x at the scrap level - which would lead to massive sync issues and storage filling up 4x faster than it should. For people playing on Category or Component, this effectively meant they could only spend 1/2 and 1/4 their storage worth of resources.

The concern described in this thread about how plots consume independently, and therefore can only consume what is in storage, rather than taking from what would be produced that day first remains. It was actually something considered during development, and left in intentionally. Yes, we could do some sort of reserve pool, and I might change my tune on that in the future - but for now, I like that people don't just perpetually stay at their storage cap when they are producing a lot. I think the desire to be at cap all the time likely stems from how buggy the resource system has been, so now that you guys have pointed me to some solutions, and we can start experiencing what a functioning resource system feels like, we can better gauge how to change things in the future.

One of the projects that we've been discussing, basically since launch, is doing a full re-balance of the costs, to get the progression system we were aiming for. Getting a first draft was really tough for the team, and we knew it was going to need a lot of tinkering. We have a rough idea of how we want it to play out, and now that I seemingly have the code working, we can start collecting some feedback from players before we proceed with a rebalance.

Getting feedback on balance, with everyone playing with the broken code would have been tainted - so I'm really excited you guys found some threads for me to tug on!

Will be posting a build tomorrow so you guys can let me know if I've fully squashed the issue. After we've confirmed the bugs are definitely gone, would love to have some people start up new saves "for real" (ie with the intention of actually enjoying the game, and not just a test save for checking numbers) and start taking notes about how everything feels with a fully working resource system!
 
Sounds great KingGath. The only suggestion I have about the problem of plot consumption when you hit the cap is it would be great for players to have the ability to throw out excess virtual resources to make more room if they desire, as an alternative to always building more storage space. This seems like something the people in a post apocalyptic world would do sometimes. I'm sure I could try to hack it with a script, but it would be nice if there was a legit way endorsed by the designer :grin

Unfortunately I will be away for the next week so I won't be in the first batch to test the fixed system :sad
 
I believe I found the issues now - in my test settlements for each of the complexity levels, all of the numbers matched up perfectly across multiple in-game days. I have not yet had a chance to test networked settlements, but presumably there will be no issue since the code simply queries each networked settlement for the same data it grabs for an individual settlement and adds it all together.


We had three major problems:

1. The HUD was fetching production numbers twice for plots in multiple places.

2. The plots were not recording their operating costs for the HUD at the Category and Scrap complexities, so the HUD and actual consumption of those costs would only work correctly if playing in Component Complexity, and even then the HUD would get out of sync since the category and scrap levels were not being updated as well.

3. Then we have the worst offender, plot production was being done multiple times. 2 x at the Category level, and 4x at the scrap level - which would lead to massive sync issues and storage filling up 4x faster than it should. For people playing on Category or Component, this effectively meant they could only spend 1/2 and 1/4 their storage worth of resources.

The concern described in this thread about how plots consume independently, and therefore can only consume what is in storage, rather than taking from what would be produced that day first remains. It was actually something considered during development, and left in intentionally. Yes, we could do some sort of reserve pool, and I might change my tune on that in the future - but for now, I like that people don't just perpetually stay at their storage cap when they are producing a lot. I think the desire to be at cap all the time likely stems from how buggy the resource system has been, so now that you guys have pointed me to some solutions, and we can start experiencing what a functioning resource system feels like, we can better gauge how to change things in the future.

One of the projects that we've been discussing, basically since launch, is doing a full re-balance of the costs, to get the progression system we were aiming for. Getting a first draft was really tough for the team, and we knew it was going to need a lot of tinkering. We have a rough idea of how we want it to play out, and now that I seemingly have the code working, we can start collecting some feedback from players before we proceed with a rebalance.

Getting feedback on balance, with everyone playing with the broken code would have been tainted - so I'm really excited you guys found some threads for me to tug on!

Will be posting a build tomorrow so you guys can let me know if I've fully squashed the issue. After we've confirmed the bugs are definitely gone, would love to have some people start up new saves "for real" (ie with the intention of actually enjoying the game, and not just a test save for checking numbers) and start taking notes about how everything feels with a fully working resource system!
Man, I can't tell you how excited I am about the upcoming changes! I'm almost drewling. I ran into virtual storage issues almost at day 1 of my SS2 playthroughs. But posting more than in game observations was way out of my league. So I am really happy @cbrgamer2 did such a wonderful job on this investigation.

I agree, having a recalculate and a delete virtual resources tool would be extremely helpful.

One question: would it be advisable not to set the virtual resources to 0 but to e.g. 10% of the available storage space? Otherwise all plots will fail after one resets the virtual resources, won't they?
 
One question: would it be advisable not to set the virtual resources to 0 but to e.g. 10% of the available storage space? Otherwise all plots will fail after one resets the virtual resources, won't they?
This is a very good point. If virtual storage is set back to 0, it may be hard to get production back up and happening again.
Another alternative might be to have it set back to 0, but pay no maintenance costs for 2 days or so to let the storage build back up a bit. Of course, I presume the player can just simulate that by turning off maintenance costs for a few days in the options.
 
Sounds great KingGath. The only suggestion I have about the problem of plot consumption when you hit the cap is it would be great for players to have the ability to throw out excess virtual resources to make more room if they desire, as an alternative to always building more storage space.

We have plans to give people more ways to engage with those resources, so that problem will go away in time. SS2 currently represents a part of something bigger we've got planned, so some things that seem like obvious QoL additions I'm avoiding are due to things we'll be adding with the expansions.
 
Looks like I picked a good time to really clean up my load order and optimize for a new playthrough. =)

The amount of work being conducted by Kinggath and company is amazing! Plus the amount of support that the SSx community provides to each other and the overall improvement of SSx is why I'll never remove SS from my load order.

Cheers to Kinggath and the rest of the SS team for the Great mod! And Cheers to the community for taking a great mod to the next level by providing additional assistance with suggestions, player help, and troubleshooting!
 
Top