-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration support to convert charges to copies #54376
Comments
As far as I understand that, it isn't possible to handle it there because that |
good to know. I'm a C# guy by day so reading CPP is like trying to read Dutch as an American. It looks familiar but wait what the hell does that mean? |
I just had a kind of crazy idea, at the point you identified, you could change the item being handled from a rag to a "bundle of rags", and insert the appropriate number of items into it based on the charges. |
Not ideal to force the player to manually dissemble the bundles generated, but certainly better than crushing stacks down to a single item. It would probably be confusing for players to find that they don't have any tailoring material after a migration, as all of it is suddenly locked up in bundles. Bonus points for creative thinking, but I think a proper migration is needed. |
I think these 'bundles' would be bags of rags/patches, not the proper bundle items, because migrating to the bundle item won't fix this (bundle items are of fixed size, we need to migrate to arbitrary size) |
This should not be closed yet as this fix only applies to what is in the player's carried inventory. Items on the ground still revert to just one single item. |
They should also have copies in their migration pocket, but you need to pick them up for them to fall out. Edit: When I try it with leather patches, it says |
Oh yeah, I see that now, my bad. I missed the migration blacklist step initially. did notice an issue or two so far - I migrated all the fabric scraps, and cotton scraps (50) gave me cotton scrap > 49 cotton scraps as expected. I then tried to pick up 1 (pressing 1 then l to select by quantity) and the game hung. Picking up the bundle broke it out into separate items, so that seems to work fine |
I'm not sure what you mean there? I did notice menus being slow to open with lots of items (~1000 in my test) in migration pockets, but after that everything went as usual. Items in the migration pocket shouldn't be directly accessible anyway. |
the game actually crashed completely and closed without giving an error message. i'd need to fire it up via visual studio to see what the error was. |
Ok other than the crash when trying to access individual items from the bundle, this works. Not sure how to deal with that, but yeah, picking them up breaks them apart and the ones in my inventory broke apart in one turn. I’ll get the fabric genericizing done today so I can get the rest of the tailoring stuff done. Thanks for your hard work! |
I'll check the crash out later. That really shouldn't happen. |
Alright I’ll see if I can reproduce it later. It could have just been this weird inventory item selection bug I only have when running it in debug. |
Is your feature request related to a problem? Please describe.
Working down the chain of tasks on the tailoring audit #53436, it's been decided that the fabrics should migrate from ammo to generic. I was attempting this in #54308, and the work on genericizing them is done, but the migration is blocking approval for the merge. When the item types are changed to generic, their charges are removed, so cotton sheet (1500) becomes 1 cotton sheet.
I'd do it myself, but after two days of trying to figure this out, I'm going to admit that this is beyond my skillset and knowledge of C++.
Solution you would like.
a 1:1 charge to item conversion
savegame_json.cpp could possibly be modified to catch this in the io function. This if block already checks for items with charges that shouldn't have them, and will throw an error if the items isn't in the charge obsoletion file, before setting charges to zero.
Adding an else to the end of that check on 2901 would be a good place to have the charge removed and then spawn in copies equal to the number of charges, but I'm not exactly clear on how to handle that part.
Describe alternatives you have considered.
a more elegant solution would be being able to specify the conversion ratio in an obsoletion file
Additional context
No response
The text was updated successfully, but these errors were encountered: