Save Game Corruption PC (Version 1.3) Please Help!

[karlblau]

I hope you can see or do something with the screenshots I have send.

Yes, you provided very valuable additional data, and I'll try to give you a more precise recommendation, how to proceed with your game.

The size of your last savegame file and the number of loads until corruption fit perfectly into the diagram, I'll try to upload an updated version tomorrow.

Therefore we can conclude two facts: CDPR managed to keep the TW3 save data stable and useable for the tremendous amout of 1883 ingame hours (congratulations!), and your problem is exactly the nasty game-breaking bug, which we have to discuss here (unfortunately).

In 1883 hours you consumed 1634 loads, this is 1.1524 hours per load. If you go back to a savegame with a loadcount of 1400, you can expect to have 269 hours of gameplay until corruption without changing your playstyle. If Velen, Novigrad and Skellige until the Isle of Mists are each 20% of the total game, and the basic game until completion 20% and HoS+B&W 20%, you have done about 60% of the game, assuming you have to redo HoS. With 269 hours for the remaining 40%, this allows a total playtime of 674 hours. This would be a very generous limit for most gamers. In addition, you could reduce the number of reloads - I'm currently in my second playthrough and left Velen (all quests up to level 11, all ? explored) with a loadcount of 9.

Of course, I can't be absolutely sure, that my analysis of the bug's behaviour is correct, but I'd recommend: Select an old savegame with a suitable number of reloads below 1634 using the W3SavegameEditor, and proceed with confidence.

 

[DrDeathhand]

Yes, you provided very valuable additional data, and I'll try to give you a more precise recommendation, how to proceed with your game.

The size of your last savegame file and the number of loads until corruption fit perfectly into the diagram, I'll try to upload an updated version tomorrow.

Therefore we can conclude two facts: CDPR managed to keep the TW3 save data stable and useable for the tremendous amout of 1883 ingame hours (congratulations!), and your problem is exactly the nasty game-breaking bug, which we have to discuss here (unfortunately).

In 1883 hours you consumed 1634 loads, this is 1.1524 hours per load. If you go back to a savegame with a loadcount of 1400, you can expect to have 269 hours of gameplay until corruption without changing your playstyle. If Velen, Novigrad and Skellige until the Isle of Mists are each 20% of the total game, and the basic game until completion 20% and HoS+B&W 20%, you have done about 60% of the game, assuming you have to redo HoS. With 269 hours for the remaining 40%, this allows a total playtime of 674 hours. This would be a very generous limit for most gamers. In addition, you could reduce the number of reloads - I'm currently in my second playthrough and left Velen (all quests up to level 11, all ? explored) with a loadcount of 9.

Of course, I can't be absolutely sure, that my analysis of the bug's behaviour is correct, but I'd recommend: Select an old savegame with a suitable number of reloads below 1634 using the W3SavegameEditor, and proceed with confidence.

Dear Karlblau,

Thanks again for taking the time to look further.
Are you saying that I have to either reload my game half way? or like totally restart my game??
Jeez man... I do love the Witcher 3.... I really do... but to restart playing it again after putting so many hours into it and not having finished the
game is rather disappointing.

Like I said I was just about do the last couple of things @ Blood and Wine and then Finish the Witcher 3 main quest it self.
So now... when playing the game you have to constantly take notice of how much you are saving / reloading.... that sort of puts one playing the game
@ a time clock... and I hate playing a game like that. I want to explore every nick and cranny and do it at ease.

I really do hope the guys @ CDProjectREd will check out this message board and fix the Witcher 3 problem.
Otherwise I think I am just going to stop playing the Witcher 3 all together.
OR I might just reload the savegame I made just before starting Blood and Wine and Finish the main quest.

I really do hate this game breaking bug... its sooo disapointing....

 

[Salvatore80]

Hi Everyone,
My gaming laptop died few weeks ago and now I'm waiting for Coffee Lake release to buy a "real" gaming rig. Therefore I was not playing games last few weeks and I almost forgot this thread... My apologies.

Did you find a way, to scroll down in a list of Children?

Unfortunately not.

What is the size of your last savefile?

Just before the bug it is 2876KB. But from few months earlier I have saves over 3MB.
The nature of the bug seems to be very complicated and it may be very hard to find even for the developers.
I don't think we'll be able to find any workaround on this other than everything that karlblau already listed...

 

[karlblau]

Unfortunately not.

Never mind, it would not have been very helpful anyway. The more interesting variables, i.e. the quest system, have such a large number of children, that the 2 GB addressable memory of a 32 bit program is not enough to scan or display it - if one is patient enough (very patient ;-), the program will eventually hit that limit and crash.
This is probably the reason, why there was never a working savegame editor for the game - the sheer number of variables is simply too large to handle this with a program or mod in reasonable time - at least not without heavy optimization.

Just before the bug it is 2876KB. But from few months earlier I have saves over 3MB.

Btw. my numbers before the bug are: saves: 8208, loads: 2106 (so I load every fourth save).

These numbers do not fit as smoothly into my diagram as the other known values do; prediction would have been about 1830 loads for a savegame filesize of 2876 KB.
I observed a reduction of the size of a savegame file too, if Geralt is currently on a small map. However, simply to do less in the game reduces this size more.

Currently I'm in a second playthrough started under GOTY 1.31a, but it is too early to run macro tests. The savegame is about 250 KB smaller compared to the first run and at the same point in the story (left Kaer Morhen looking for allies, 120 hours less real time). I avoid reloads as far as possible, and do no fast travels between maps except what the story absolutely requires or does automatically, but it is like riding on a tiger. The game features still very old bugs (like CTD while staring at the many recipes of a vendor) and is designed to reload here and there.

And I noted subtle differences between 1.31 and 1.31a, this was not a galaxy-only update, even content was changed at very different places. For example, the cutscene when Crach gives the winter's blade to Geralt is different (he does not take it from the wall anymore - it looked a bit awkward before), or the quest "playing innkeeps" allows to do crossroads before Oliver now, or the recipe for superior full moon is found later (as late as on level 30 now, in 1.31 superior northern wind on level 25 was the last one).

 

[SigilFey]

The game features still very old bugs (like CTD while staring at the many recipes of a vendor) and is designed to reload here and there.

Confirming this is occurring with a very large save file? Or does it occur even at lower playtimes?

I've never encountered anything like this in 5 playthroughs. Bugs I've seen regularly:

Non-responsive / missing shopkeepers
Broken quest dialogues
Occasionally missing enemies
Whoreson Junior thugs that won't stay dead
Little graphical /scheduling glitches with NPCs (collision issues with sitting / leaning, characters walking in tight circles, little things)

I can safely say those things are all normal glitchy-poos, not related to the "super-big-save-game bug".

 

[ssdany]

I stumbled upon this bug more than a year ago (even before the inventory redesign). No mods. The symptoms were pretty clear: "blank" items popped up in inventory after some loads - i.e travel, save/load et cetera. Some of them were even equippable, and later it turned out that these particular items were actually technical entities for body parts and fists. I've spend a couple of days trying to pinpoint the root of a problem, wrote report to CD Project, found a dirty workaround, wrote about all findings again and got something like "OK, but please understand that there are a lot of more important issues to fix" (well, at least they're aware of it).

In my case, problem was tied to item IDs. Basically, each item in your inventory has its own ID (and if it's a stack of items, then the stack has, not the each item in it). When you pick something new, new ID is assigned. Not the smallest free one though, but the current maximim plus one, just an autoincrement; and this is why grinding is not recommended. IDs are limited, of course, since in savefile they're represented as uint16 (0-65535). The funny thing is that the game is able to use wider range when you're playing. So if you have an item with ID = 65535 in your inventory and pick some new items then these items will have IDs like 65536, 65537 and so on - I added some debug code to inventory scripts to ensure I'm on the right way and these are the numbers I saw. But then you have to save your game, right? After that, IDs will be truncated, 65536 will became 0, et cetera. This leads to a situation whereby your inventory could contain a couple of different items with equal IDs. As a result, some items can (and will) disappear from inventory, and when this collision affects "hidden" items like "fists" then you'll get "blank" items.

AFAIK there is no way to fix it without heavy modification of savefile processing and/or inventory scripts. The workaround I used was simple, but ugly; can't even call it a dirty fix, so ugly it was. I tweaked inventory initialisation scripts forcing the game to overflow ID counter (by adding and removing a piece of "Wolf's Liver" repeatedly) in a manner that after save and reload max ID was in a "safe" zone (in my case it was somewhere near 42K). The savefile I used for that was not yet affected and I also had to drop everything to the ground (also with some scripting, because "everything" includes recipes, formulaes and Gwent Cards and you can't drop them manually) before applying the tweak.

Overall, it is similar to FormID bug in good ol' Oblivion. The next step was to detect WHY IDs were incremented so fast. Because I believe that this should not happen in normal circumstances. Tested it with just a couple of swords and armour in inventory and after a save/load max ID was the same. Adding one type of runestone caused it to be incremented by one on each subsequent save/load. Adding 4 types... Well, by four. Seems like this is related to an old bug (if I remember correctly, some runestones were not function properly) and a little function that was added in one of patches in order to fix it on inventory initialisation.

After that I decided I have more interesting things to do and stopped playing for some time. Checked the game after a couple of patches, but the bug was still present. It's a pity to know that it is not fixed yet.

 

[karlblau]

Hi ssdany,

to begin with, many thousand thanks for sharing your knowledge - you added the most important and helpful contribution to this thread so far, pinpointing and explaining the root cause of the bug, and adding an explanation, what exactly destroys the inventory, while just saving and reloading the game repeatedly.

After reading this, I did some preliminary tests immediately, and can confirm your findings, therefore most probably the bug discussed here is exactly the same bug you experienced, analysed and already reported to CD Projekt Red earlier.

I used that last savegame, which reproduced the corruption after loading and one additional fast travel to a different map, and after dropping every runestone and glyph to the ground before this last fast travel, everything looked fine even several fast travels later. I added 100 save/restore cycles in Wyzima without problems, and then went back to Velen and picked up these dropped runstones and glyphs - and as expected, the bug occurred.

The basic game features 10 runestones and 5 glyphs in 3 sizes each, which totals to 45 stacks of items, and many gamers will carry around these in the inventory and therefore burn up to 45 item IDs during each reload. We know, that the total number of possible reloads approaches 1600, if somebody played for a long time (and therefore has a stack of each type of runestone and glyph, both item types matter), and 45 * 1600 = 72000 is not far above 2**16 = 65536.

AFAIK there is no way to fix it without heavy modification of savefile processing and/or inventory scripts.

This is correct, and this is probably the reason, why CD Projekt Red simply ignores such a disastrous bug. However, a fix is not necessarily required, the problem could be solved without any modification to the game, at least for PC players:

Imagine a utility, which reads and decompresses a savegame file, reassigns a new item ID starting with 0 to any item or item stack in the inventory, resets the max ID counter accordingly (if there is any), and compresses the data and writes a new savegame file. How much time would be required to make this - if somebody worked as developer with the game and has access to tools and documentation?
This could be used by everybody, who experiences the bug, as needed - just like the Animation bug fix in Oblivion.

If you still remember, please, could you give me more details? How to dig out item IDs in the game / saved game? I know how to unpack game content and scripts, how to read .w2phase files and how to modify and compile Atvaarks savegame viewer.

Overall, it is similar to FormID bug in good ol' Oblivion.

The resemblance is striking, unfortunately with three major exceptions: FormIDs were initially designed to be reused, there was an early community fix / relief, and finally Bethesda fixed the bug.

Checked the game after a couple of patches, but the bug was still present. It's a pity to know that it is not fixed yet.

The game has 2832 known console codes for additem(), and even more invisible items, recipes and Gwent cards. Every randomly generated weapon picked up from loot or a container, every little stack of plants or ingredients picked up and sold, will use an additional item ID. How is it possible, that somebody made the fatally flawed design decision, that 65536 item IDs will be sufficient? For an RPG game, playable by design for hundreds of hours in a vast open world with thousands of monsters to be killed?
How much ignorance is needed, to aggravate this problem by a patch, that burns up to additional 45 item IDs for each reload and each fast travel between different maps?

This is not a pity, this is something to bang his head against the next wall in utter despair!

 

[karlblau]

Confirming this is occurring with a very large save file? Or does it occur even at lower playtimes?

I tried what I could to produce a small save file and a low playtime on my 2nd playthrough. The only requirement for the bug, which is known to me, is a large number of recipes in the inventory of a vendor, something that happens, if you do not buy any schematics for runestone or glyph upgrades, because these cannot be found in containers. Of course, a higher level is required for this condition.

During a longer examination, or if the mouse hoovers for some time in that region of the inventory on the screen, the game crashes to the desktop. I learned, that these are remains of a very old bug, which happened in early times for many players, who just opened their inventory. I don't think, that it has any relation to the reproducible bug, which is the topic of this thread.

The bug can be eliminated completely, if Geralt buys all these diagrams - and this is what I did (painful with very small funds), because I wanted to avoid reloads. Unfortunately, this is not sufficient to evade the "super-big-save-game bug", because it is a "too many used item IDs bug", as I learned from ssdany. Now I'll add 200 stacks of runestones with the console, and if the number of remaining reloads is small, then my next Geralt will probably commit suicide and I'll buy ELEX from GOG.

I've never encountered anything like this in 5 playthroughs. Bugs I've seen regularly:

Non-responsive / missing shopkeepers
Broken quest dialogues
Little graphical /scheduling glitches with NPCs (collision issues with sitting / leaning, characters walking in tight circles, little things)

These three types of glitches I've seen too. I resorted to ignore these travelling or minor shopkeepers completely. Some things are even funny, for example the halfling selling herbs in the hut in the fields near Oxenfurt has half of his body below the floor, before Geralt talks to him - this makes him technically a quarterling.

 

[ssdany]

Thanks for quick response and testing, karlblau.

If you still remember, please, could you give me more details?

Yep, I'll try; modified files should still be somewhere on my PC. I'm pretty sure CDPR changed all those scripts, but hope it won't be a problem.

This is not a pity, this is something to bang his head against the next wall in utter despair!

I'm not justifying it, but these issues are not the ones that could be easily detected during the QA phase of release or in automated testing. I'm also sure that runestones "bomb" was "planted" with an assumption that inventory functionality was free of such bugs. Everybody can make a mistake. But this one became critical when CDPR released expansion packs and, more importantly, NG+.

When I investigated it, there was a function supposed to clean up your inventory during NG+ initialisation. I don't think it was completely rewritten or refactored, so here is what will likely happen on NG+ start-up: all quest items, Gwent cards etc will be removed and all other items - crafting components, alchemy ingredients, swords - will remain in your inventory without any changes, intact. On top of it you'll receive some recipes and, if I remember correctly, at least a couple of technical entities. Thus, your IDs won't start from zero. In my case, this number was around 40K, because I played since release and started NG+ on top this playthrough. Turned out that it was doomed from the start.

UPD: Found old code. Debug is OK (it's just a couple of lines here and there). Moving "workaround" to cheats so that it can be used from dev console, at least for testing.

 

[karlblau]

This is a long text, but probably worthwile to read, because it contains workarounds to prevent the bug discussed in this thread. Once more I'd like to thank ssdany, whose work made it possible to understand the bug.

The last two evenings / nights, I did some additional tests.

Test 1
Use a reinforced runestones bomb to verify the effect with a savegame created and used exclusively with TW3 GOTY 1.31a and determine the number of already used item IDs

The savegame used for this test was the current state of my second playthrough, and there were 42 stacks with runestones and glyphs in the inventory. I opened the developer console and entered additem('Glyph aard lesser',20800) to increase the total number of such stacks to 250, and prepared to do 300 save/restore cycles in Wyzima. This way, the runestone bomb should consume 250 * 300 = 75,000 item IDs, which is above the maximum of 2**16 = 65,536, and corrupt the inventory once the maximum was reached - a brute force way to learn, how many items IDs were already used.

Normally, I turn off sound and screen, while the PC does tests with keyboard macros, but this test was different:

Tension was in the air, while the five-fold reinforced runestones bomb burned item IDs in large chunks of 250 per iteration. I stared at the screen, and it was like standing before a court and waiting for the judgement - the savegame used had 27 reloads and 195 hours ingame time and once again a Geralt was ready to go to the Isle of Mists. It was the best, I could have done with my limited knowledge about the bug - but was it good enough to continue?

Some minutes later 25,000 item IDs were used and the inventory still looked fine, and then the test passed 50,000 item IDs and the relation between initially available and used item IDs improved rapidly, and finally the bug corrupted the inventory after 57,500 item IDs. Enough for the basic game, all extensions and even NG+.

Test 2
Workaround: Stash runestones and glyphs in the storage box

The next test was an attempt, to partially work around the runestones bomb by proper ingame action: I stashed all 250 stacks of runestones and glyphs manually into Geralts storage box, travelled to Wyzima as usual and did 300 save/reload operations, went back to the storage box and took all 250 stacks one by one to be sure, to really get what was displayed.

Result: The runestones bomb is not active, if this stuff is moved from the players inventory into the storage box, because even if the storage box would use a separate space of item IDs of type Uint16, an active runestones bomb would have burned 75,000 such item IDs and therefore destroyed the inventory of the storage box.

This is an important result, because it allows to work around the runestones bomb: Let's assume there are 1000 runestones of all 45 types to be found in the basic game (I doubt there are so many). If each is picked up and put into the storage box one by one, this will use a total of 1000 (inventory) + 45 (stacks in the box) item IDs. Probably significantly less, because in the game world, several runestones of the same type can be collected, stacked, and stashed into the storage box before the next reload using only one item ID per collected stack.
On the other side, if 45 stacks of runestones are carried in the players inventory during 1000 reloads, this will burn the dangerous amount of 45,000 item IDs. Quite a difference, isn't it?

Test 3
Add and remove a randomly generated non-stackable item many times

This test was lengthy: I added and removed a non-stackable item, the sword Moonblade, to the inventory 75,000 times - with a save/reload operation after 500 operations / 250 swords - with a new keyboard macro using the game developers console. I wanted to know, whether each such operation really consumes an item ID, and verify the results of Test 1 without involving the runestones bomb. I choose this famous sword not only for role-playing reasons, but because I assumed, each weapon, even this one, is generated with randomly choosen properties and therefore a different, unique item.
While it was possible, to add 250 swords with one additem() command, it was not possible, to remove these 250 swords at once - therefore I used additem() and removeitem() for each sword and optimized speed by recalling the console commands.

Result: After six hours and a number of operations consistent with the results of Test 1, the inventory was corrupted.

The consequences are striking: Each time, when you kill a bandit and pick up his junk weapon, just to sell it, an item ID is consumed. Each time, when you pick up some junk item, like a broken pitchfork the people in Velen often hoard in their chests, an item ID is consumed.
Especially, if you are a victim of the runestones bomb and/or the item ID game engine limitation and restart from an earlier savegame with many item IDs already consumed, you should think twice before doing that.

It is probably possible, to save and reload a game in "The Witcher 3" as often as you want, if you stash away or sell your runestones and glyphs, and it is probably possible to grind and loot at your hearts desire without dire consequences, if you keep this item ID problem in mind.

DrDeathhand played for 1883 hours, until he had used all possible item IDs. Salvatore80 reloaded 2106 times, until he hit the same wall. I could reload a small savegame with only 3 runestones in inventory 8600 times without problems. And during my second playthrough, I did some sessions of indecent length, but the game was able to sustain this in full stability. These foolish Uint16 item IDs used only in compressed or saved state, but not while running the game engine, are the equivalent to the limited speed of light in physics - this may be the final frontier here.

I would recommend, to keep always one piece of stackable items like hides / pelts / skins, plants, moster parts or common books in the inventory, even if there is some additional weight. So, if you hunted white wolfs and have 50 livers or pelts, sell only 49 and keep 1, this way you can always use the same item ID and kill thousands over thousands of wolfs. And when doing alchemy or crafting, do not use all ingredients and materials - make sure to have always one piece left.

Of course, I don't know what that taxman added in the Hearts of Stone extension will do, if he meets you with one piece of all types of hides in possession, but I'm sure, money is a minor problem, if you killed thousands of beasts (not the cows in White Orchid of course) and sold the loot ;-)

Live long and prosper.

 

[karlblau]

UPD: Found old code. Debug is OK (it's just a couple of lines here and there). Moving "workaround" to cheats so that it can be used from dev console, at least for testing.

It would be a great help for all victims of this item ID problem, if there would be an easy ingame way i.e. with the dev console, to check the number of available or used item IDs in older savegames, which could be used to restart and proceed in a more careful way.

 

[SigilFey]

This is a long text, but probably worthwile to read...

Absolutely was! Kudos, Brownie Points, and blessings of The Great Pumpkin be upon you. What you've posted sounds pretty solid.

Tension was in the air, while the five-fold reinforced runestones bomb burned item IDs in large chunks of 250 per iteration. I stared at the screen, and it was like standing before a court and waiting for the judgement -

We'll humor the drama here with appropriate underscore:

https://www.youtube.com/watch?v=3aYiiGd3PZc


So, in the end, does this seem like it would affect all inventory items the same way, or is this particular situation exclusive to runes / glyphs (as it's extremely unlikely to acquire the same number of weapons)? What about alchemy / crafting ingredients?

In the end, you seem to have found the trick. Sounds like "mystery solved". If this is reliably re-created, I'll ping CDPR internally about it. Really awesome, karlblau!

 

[DrDeathhand]

This is a long text, but probably worthwile to read, because it contains workarounds to prevent the bug discussed in this thread. Once more I'd like to thank ssdany, whose work made it possible to understand the bug.

The last two evenings / nights, I did some additional tests.



The savegame used for this test was the current state of my second playthrough, and there were 42 stacks with runestones and glyphs in the inventory. I opened the developer console and entered additem('Glyph aard lesser',20800) to increase the total number of such stacks to 250, and prepared to do 300 save/restore cycles in Wyzima. This way, the runestone bomb should consume 250 * 300 = 75,000 item IDs, which is above the maximum of 2**16 = 65,536, and corrupt the inventory once the maximum was reached - a brute force way to learn, how many items IDs were already used.

Normally, I turn off sound and screen, while the PC does tests with keyboard macros, but this test was different:

Tension was in the air, while the five-fold reinforced runestones bomb burned item IDs in large chunks of 250 per iteration. I stared at the screen, and it was like standing before a court and waiting for the judgement - the savegame used had 27 reloads and 195 hours ingame time and once again a Geralt was ready to go to the Isle of Mists. It was the best, I could have done with my limited knowledge about the bug - but was it good enough to continue?

Some minutes later 25,000 item IDs were used and the inventory still looked fine, and then the test passed 50,000 item IDs and the relation between initially available and used item IDs improved rapidly, and finally the bug corrupted the inventory after 57,500 item IDs. Enough for the basic game, all extensions and even NG+.



The next test was an attempt, to partially work around the runestones bomb by proper ingame action: I stashed all 250 stacks of runestones and glyphs manually into Geralts storage box, travelled to Wyzima as usual and did 300 save/reload operations, went back to the storage box and took all 250 stacks one by one to be sure, to really get what was displayed.

Result: The runestones bomb is not active, if this stuff is moved from the players inventory into the storage box, because even if the storage box would use a separate space of item IDs of type Uint16, an active runestones bomb would have burned 75,000 such item IDs and therefore destroyed the inventory of the storage box.

This is an important result, because it allows to work around the runestones bomb: Let's assume there are 1000 runestones of all 45 types to be found in the basic game (I doubt there are so many). If each is picked up and put into the storage box one by one, this will use a total of 1000 (inventory) + 45 (stacks in the box) item IDs. Probably significantly less, because in the game world, several runestones of the same type can be collected, stacked, and stashed into the storage box before the next reload using only one item ID per collected stack.
On the other side, if 45 stacks of runestones are carried in the players inventory during 1000 reloads, this will burn the dangerous amount of 45,000 item IDs. Quite a difference, isn't it?



This test was lengthy: I added and removed a non-stackable item, the sword Moonblade, to the inventory 75,000 times - with a save/reload operation after 500 operations / 250 swords - with a new keyboard macro using the game developers console. I wanted to know, whether each such operation really consumes an item ID, and verify the results of Test 1 without involving the runestones bomb. I choose this famous sword not only for role-playing reasons, but because I assumed, each weapon, even this one, is generated with randomly choosen properties and therefore a different, unique item.
While it was possible, to add 250 swords with one additem() command, it was not possible, to remove these 250 swords at once - therefore I used additem() and removeitem() for each sword and optimized speed by recalling the console commands.

Result: After six hours and a number of operations consistent with the results of Test 1, the inventory was corrupted.

The consequences are striking: Each time, when you kill a bandit and pick up his junk weapon, just to sell it, an item ID is consumed. Each time, when you pick up some junk item, like a broken pitchfork the people in Velen often hoard in their chests, an item ID is consumed.
Especially, if you are a victim of the runestones bomb and/or the item ID game engine limitation and restart from an earlier savegame with many item IDs already consumed, you should think twice before doing that.

It is probably possible, to save and reload a game in "The Witcher 3" as often as you want, if you stash away or sell your runestones and glyphs, and it is probably possible to grind and loot at your hearts desire without dire consequences, if you keep this item ID problem in mind.

DrDeathhand played for 1883 hours, until he had used all possible item IDs. Salvatore80 reloaded 2106 times, until he hit the same wall. I could reload a small savegame with only 3 runestones in inventory 8600 times without problems. And during my second playthrough, I did some sessions of indecent length, but the game was able to sustain this in full stability. These foolish Uint16 item IDs used only in compressed or saved state, but not while running the game engine, are the equivalent to the limited speed of light in physics - this may be the final frontier here.

I would recommend, to keep always one piece of stackable items like hides / pelts / skins, plants, moster parts or common books in the inventory, even if there is some additional weight. So, if you hunted white wolfs and have 50 livers or pelts, sell only 49 and keep 1, this way you can always use the same item ID and kill thousands over thousands of wolfs. And when doing alchemy or crafting, do not use all ingredients and materials - make sure to have always one piece left.

Of course, I don't know what that taxman added in the Hearts of Stone extension will do, if he meets you with one piece of all types of hides in possession, but I'm sure, money is a minor problem, if you killed thousands of beasts (not the cows in White Orchid of course) and sold the loot ;-)

Live long and prosper.

Dear God Karlblau!, SSDany

I have been following this forum Topic ever since I found it and replied to it because of the same problem I have been experiencing.
And well... I just have to compliment you both on all the time energy and effort you have been putting into solving this problem and or trying to find out what is causing this problem!
I was quite amazed to read that this is probably a bug that has been in the game from the very beginning and that has not been solved by CDProjectRED.

Man I really do hope that you Karlblau or SSDany find a way to create a program or script or something like that to fix this problem.

Reading your post above was really an absolute treat and the outcome of your research is really surprising to me.
Keep up the awesome work!!

I have two requests for you Karlblau and or SSDany.

1. Can you make another post here at this forum topic where you explain point for point how one might avoid this problem or postpone this problem for the longest time??
2. Can you explain to me what options are left for me to do to be able to get around or postpone this problem/bug, using one of the last savegames before they got corrupted, long enough for me to finish Blood and Wine and the last / final part of the main Witcher 3 game without getting a corrupt savegame etc?

Information regarding request nr2:
- you know I have been playing The Witcher 3 for 1883 hours.
- you know I have ALOT no really ALOT of save games (most of them not corrupted).
- you have seen via the savegames I send you what kind of inventory I have, what I have explored, what I have been doing etc etc
-Some things you might not know :
- I have TONS of items in the storage box @ Dandelion's bar / place... during my travels
- I have killed of soooooo many bandits and I have always picked up their items and then disassembled them for parts....
- I have harvested TONS ingredients along the way and so on....
- I not changed or added any item by using console commands
If there is any information missing regarding request nr 2 then please ask or look into the savegame I send you which is one of the last ones before encountering the corruption.
- one odd piece of information. In the savegame I send you I am playing the Blood & Wine Paperchase quest. There I get a corrupt inventory after talking to the bank employee.
but I do not get an item from the bank employee so how can it get corrupted?

Alright Karlblau, Thanks again for all your hard work! I hope to hear from you.
Ohh and I should not forget, Thanks SSDany!!!

Greetings,

DrDeathhand

 

[SigilFey]

I was quite amazed to read that this is probably a bug that has been in the game from the very beginning and that has not been solved by CDProjectRED.

Oh, it certainly exists in the game -- I think that's confirmed now. Digging it out was no small feat, though, and it wouldn't have manifested until someone got to this extreme (1,883+ hours) / vast number of inventory items.

Frankly, the game was never really designed for that type of play (NG+ was only included after the fact by overwhelming player demand.) This bug is actually in the engine itself, so I still highly doubt that there will ever be a fix, but at least there now appears to be a workaround. It's similar in nature to the Minecraft "Far Lands" -- the amount of memory allotted by the engine reaches its limit it cannot correctly process values after that point. Weirdness ensues.

I'm mostly interested now to see if there is some way of making the issue occur sooner. (Which I seriously doubt.) It looks like the source of the issue is solved. I'll run it by Tech Support, although I don't imagine that there will be a fix. Still, they might be able to add something...

karlblau, do you have an answer for my questions above? I want to be able to summarize accurately before I send this on.

- one odd piece of information. In the savegame I send you I am playing the Blood & Wine Paperchase quest. There I get a corrupt inventory after talking to the bank employee. but I do not get an item from the bank employee so how can it get corrupted?

This sounds like a completely different thing. Does this occur at around the same time / just after the bug would occur? It could simply be another manifestation of the inventory system running out of reference values. (Somebody above posted that clearing inventory would sometimes grant them quest-specific potions out of thin air. Might be along those lines.)

 

[ssdany]

Thanks, DrDeathhand and SigilFey.

1. Can you make another post here at this forum topic where you explain point for point how one might avoid this problem or postpone this problem for the longest time??

This was my masterplan after investigation:

1. Do NOT carry runestones/glyphs with you. Do NOT craft new ones. Put them into a chest (well, chest is also affected, but at slower rates) and use only when necessary.
2. Avoid picking items that will take a separate inventory slot. Remember that dropping a sword and picking it will also increment a current max ID.
3. Always carry a little amount of everything - plants, hides, whatever. For example, at least one wyvern hide, one wyvern egg etc. In this case, new item will not take a separate slot.

I played this way only 10 hours or so, but everything was fine. Not very enjoyable, though. And, besides, I would have to merge/rebase all my script changes after each patch and I'm a not a big fan of rebasing on top of the code I'm not familiar with.

Man I really do hope that you Karlblau or SSDany find a way to create a program or script or something like that to fix this problem.

I have a debug code isolated into a mod; the "workaround" (a controllable uint16 overflow) is also included, but not yet completed: still thinking of how to make it more safe or if there is another way to reassign IDs. Don't have enough time to test it though, so if you want to try then I can send it to you.

- one odd piece of information. In the savegame I send you I am playing the Blood & Wine Paperchase quest. There I get a corrupt inventory after talking to the bank employee.

Didn't have a chance to play it, since it was released after I stopped playing. But here are some assumptions:

1. There are technical items, internally flagged as 'NoShow' and 'NoDrop'. Thus, in some cases, you won't receive notification about new item in your inventory.
2. Inventory may be corrupted without any visible signs of it: uint16 oveflow has already occured, but there are no collisions yet.
3. Internally, the game fires a special event after you load a save or use a "travel" function. There is also a callback for it, `onSpawned`, which instantiates a lot of things, including inventory. If talking with bank employee causes this callback to be triggered, or just re-instantiates inventory, the bug may occur or become visible.

I'm mostly interested now to see if there is some way of making the issue occur sooner. (Which I seriously doubt.) It looks like the source of the issue is solved. I'll run it by Tech Support, although I don't imagine that there will be a fix. Still, they might be able to add something...

Collecting runestones will definitely make it occur sooner: the "runestones bomb" is a separate internal issue, which, despite its insignificance, brings the inevitable. As for the fix... yes, the last time I contacted support, they stated that this is not a 'truly game-breaking issue', but hey, they were pretty busy. And, technically, items in "corrupted" inventories are completely safe - you can "lose" some hides but they should appear in crafting menu no matter what (if this part of code was not changed). This is because different parts of scripted functionality use different ways to access inventory: by UniqueID and by Name. The latter seems to be safe, but you can't be sure that yet another vitally important function will not ever use the former.

Somebody above posted that clearing inventory would sometimes grant them quest-specific potions out of thin air. Might be along those lines.

This seems to be possible, but only if such a potion already exists in inventory and, for example, marked as 'NoShow'. In such a case, collision could make it visible.

 

[DrDeathhand]

Dear SSdany,

Thank you very much for your reply. It has made for some interesting reading. I like to answer / reply to some of the things you said. Il add Quotes and answer / ask / reply to them.

This was my masterplan after investigation: 1. Do NOT carry runestones/glyphs with you. Do NOT craft new ones. Put them into a chest (well, chest is also affected, but at slower rates) and use only when necessary. 2. Avoid picking items that will take a separate inventory slot. Remember that dropping a sword and picking it will also increment a current max ID. 3. Always carry a little amount of everything - plants, hides, whatever. For example, at least one wyvern hide, one wyvern egg etc. In this case, new item will not take a separate slot. I played this way only 10 hours or so, but everything was fine. Not very enjoyable, though. And, besides, I would have to merge/rebase all my script changes after each patch and I'm a not a big fan of rebasing on top of the code I'm not familiar with.

1. So point nr 3 does not apply to Runestones/Glypths?? Never carry any Runestones/Glypthes even if they stack up like the items in point nr 3??
2. About point nr 3. I really do have a lot of inventory items which I collected during my 1883 hours of exploring / adventuring... just an example, I have not counted everything but I have at least 20x 99 of every alchemy ingredients and or at least 20x 99 food items like Dried Fish, Chicken sandwich etc.... Does it help / work in anyway to either sell, drop, dismantle, store (in storage chest) these items to clear ItemID's ??
3. I do understand the whole merge/rebase all your script issue after each patch... the good thing though is that I think Patch 1.31 is the last patch that they will release for The Witcher 3 (even if there are still some huge bugs in there like the Runestones bomb bug... even SigilFey said so... soooooo if you finish your script work for Patch 1.31 it will most likely be the last time you have to do all that work!! sooo maybe that is some kind of motivation?

Didn't have a chance to play it, since it was released after I stopped playing. But here are some assumptions: 1. There are technical items, internally flagged as 'NoShow' and 'NoDrop'. Thus, in some cases, you won't receive notification about new item in your inventory. 2. Inventory may be corrupted without any visible signs of it: uint16 oveflow has already occured, but there are no collisions yet. 3. Internally, the game fires a special event after you load a save or use a "travel" function. There is also a callback for it, `onSpawned`, which instantiates a lot of things, including inventory. If talking with bank employee causes this callback to be triggered, or just re-instantiates inventory, the bug may occur or become visible.

1. This sort of makes sense yes... I mean with some quests you receive quest items or stuff like that which you cant remove but they do add an other item ID.
2. Your speaking about Uint16 overflow. Is there some way to find out or check if an inventory has gotten corrupted even if there are no visible signs of it / no collisions have happened yet?
I would like to be able to check my savegames to see where / when the corruption began so that I know how far back I need to go to play a non corrupted savegame and from there on do the things
you described (like leave all runestones /
3. If the inventory already has been corrupted but the corruption is not visible can it still be fixed? or is it as soon as you cross the 65535 threshold your inventory will become corrupted beyond repair?

I have a debug code isolated into a mod; the "workaround" (a controllable uint16 overflow) is also included, but not yet completed: still thinking of how to make it more safe or if there is another way to reassign IDs. Don't have enough time to test it though, so if you want to try then I can send it to you.

1. What would your Mod do exactly?? Does it fix the risc of a Uint16 overflow? Does it fix your inventory if it has gotten corrupted? Does it show how far ahead one is in corrupting their inventory?
I am just asking this because I am very interested in it workings and well I just find it AWESOME that your taking the time to create something like this so that people like me can continue playing The Witcher 3.
2. I do have time for testing it so if you want to send it then awesome! When I have received it I think we need to speak on how to test it. Like.. do I test it on an already corrupted savegame? or on a savegame that has not yet been corrupted etc etc.


Alright well.. hope to hear from you SSDany,

Greetings

DrDeathhand

 

[DrDeathhand]

Oh, it certainly exists in the game -- I think that's confirmed now. Digging it out was no small feat, though, and it wouldn't have manifested until someone got to this extreme (1,883+ hours) / vast number of inventory items. Frankly, the game was never really designed for that type of play (NG+ was only included after the fact by overwhelming player demand.) This bug is actually in the engine itself, so I still highly doubt that there will ever be a fix, but at least there now appears to be a workaround. It's similar in nature to the Minecraft "Far Lands" -- the amount of memory allotted by the engine reaches its limit it cannot correctly process values after that point. Weirdness ensues.

Dear Sigilfey,

I concur and also think that this Runestone Bomb bug does still exist in the game. It indeed was no small feat digging it out.
You said, "it wouldn't have manifested it self until someone got to this extreme 1883 hours / vast amount of inventory items".
I think this is not really true... because as you can see in this Forum Topic there are a couple of people who have spend a lot less hours
playing the game but who have also experienced the same inventory issue as I have experienced. So it can happen to anyone if the circumstances are right.

Also.... you said that 1883 hours is an extreme amount of hours spend into this game... I sort of have to agree with you there.. it is A LOT of time spend in this game
but hey... a big supporter of the Witcher games... who bought all Witcher games from the beginning... pre ordering them all... bought multiple collectors editions etc
its only natural to spend a lot of time into those games. All the Witcher games have been sooo emerging to play and The Witcher 3 tops them all.
And well... I am an avid gamer so when playing a game like the Witcher 3 I want to see everything, experience everything, explore everything, do all quests... try to complete all quests with green tags etc etc sooo that just takes time

I'm mostly interested now to see if there is some way of making the issue occur sooner. (Which I seriously doubt.) It looks like the source of the issue is solved. I'll run it by Tech Support, although I don't imagine that there will be a fix. Still, they might be able to add something...

I think all other people that have replied here on this Forum Topic have had this issue occur sooner then me.
Also I think that SSDany has explained that using the runes / glypths will allow one to have this issue occure sooner.

I'll run it by Tech Support, although I don't imagine that there will be a fix. Still, they might be able to add something...

That would just be AWESOME!! I hope they will respond and help us!

Thanks again Sigilfey for you know... sticking around and taking this problem seriously! Thats what good support is all about!

 

[karlblau]

Status update

This is a short update with recommendations and the state of my research. ssdany sent me his code packed as ModKit compatible mod, and I used it, to do more detailed tests, and added new functions to drill deeper and to learn, how it might be possible, to repair savegames with critically high item IDs.

For those, who play the game and want to prevent the bug:

1. The runestones bomb is active in the stash / storage box too, the box has a separate inventory subject to the Uint(16) or 65536 limit for item IDs in saved games. If all other items (except runestones) have stash-specific item IDs below 1000 (the ususal case), no damage is seen after an overflow, if the runestones were added later (but only in this special case). Btw, the horse has its own inventory too.

2. There is an additional game feature, which consumes an item ID after each reload and probably on other occasions. This is Geralts head - you remember, his beard can grow? The game therefore replaces his head, most times with the same head, but sometimes with a different head. This reduces the possible ingame time and the number of reloads.

Current recommendations: Avoid reloads and stash away all runstones in your box. Don't pick up every junk item, and always keep one item, if you sell, use or drop stackable items.

For those, who are hoping for a repair or a fix:

It looks still difficult, but is no more completely out of reach without help from the developers / CD projekt red, because even very basic, atomic functions of the game engine are realized as scripts and can be modded. ssdany tried a hack, which did a controlled overflow of the SItemUniqueId counter, after dropping as much as possible to the ground (with scripts of course), giving schematics and gwint cards a special treatment.

The problem here are Geralts body parts, invisible and not-droppable items in the player's inventory. Every Geralt is created nude, in underwear and with his witcher medallion, and these items, equipped / mounted like armor parts, always occupy the first unique item IDs 1 to 6 in the player's inventory. This should be no problem, just set the counter above and go on.

It is a problem, because later in the game additional, unnecessary copies (only two or three) of two distinct body parts are added with higher item IDs *and* these elementary body parts have special protection against removal (because Geralt would dissolve in thin air without), and not even the basic function RemoveItem( itemId : SItemUniqueId , optional quantity : int ) can remove it. Perhaps a bug, if an identical item is mounted ... hmm ... will check.

Therefore it is a matter of chance, whether a saved game shortly before overflow can be repaired or not - in a tedious, manual way: If the highest item ID of such an additional, duplicate body part is low enough, it can be done, if it is high, this makes no sense.

It may be possible to create a "override-anything-and-ask-no-questions-because-I-know-what-I-do" version of a function to remove items by id, but this is not for the faint-hearted, and will eat up more time, because you have to check what item is really mounted, it is probably even more atomic, and all this has to be packed into console commands (exec functions). Not to mention, that I never learned the script language to code this, and probably use it like a blind one stumbling through the forest .

Another way to fix the bug once and for all could be, to update the function, that adds / creates new items in the player inventory, and make it reuse free item IDs. If the game scripts are created properly, and everything manipulating items uses the same basic services, then this would work even for games with only a few item IDs left. But I'm dreaming, in reality, there are probably numerous exceptions handling the stuff in another way.

Effectively, the architects of the game engine tried to do the impossible and gained nearly nothing, beside an ugly bug: Increasing a counter instead of looking for a free, already used item ID is a bit faster, but if you have to do this only 64536 times at most during hundreds of hours, you gain nothing. To store about 1500 items with 2 byte ids, instead of using 4 byte ids like the running game, is 3 KB before compression, and nearly nothing after compression (maybe 2 bits per item, saved games are compressed in LZ4 chunks).

Enough rambling, this should be short. I'm waiting for feedback from ssdany, perhaps he will agree to upload his mod, then everybody could easily check, how many item IDs are left in a saved game.

 

[ssdany]

Sorry for silence. Spent couple of nights trying to do something acceptable with the bug.

1. The runestones bomb is active in the stash / storage box too, the box has a separate inventory subject to the Uint(16) or 65536 limit for item IDs in saved games. If all other items (except runestones) have stash-specific item IDs below 1000 (the ususal case), no damage is seen after an overflow, if the runestones were added later (but only in this special case). Btw, the horse has its own inventory too.

It’s also a body part, in my case it was a `head_3`. And there are 2 such items during the tutorial section.

It is a problem, because later in the game additional, unnecessary copies (only two or three) of two distinct body parts are added with higher item IDs *and* these elementary body parts have special protection against removal (because Geralt would dissolve in thin air without), and not even the basic function RemoveItem( itemId : SItemUniqueId , optional quantity : int ) can remove it. Perhaps a bug, if an identical item is mounted ... hmm ... will check.

Oh, my first attempt for a fix was simple: drop all items, overflow to 2 ** 16, transfer everything back. This is how I met the Mighty Body Parts. All 16 of them. Initially, there are 10 at max and later you will receive new parts and copies of already existing ones. That’s the problem. Their identifiers can be spread across a very wide range (1-64802 in my case). And yes, you can’t remove them. There IS a function which allows you to “drop” them - DropItem. It accepts 2 arguments; the second one, if set to `true`, forces engine to really remove item from inventory. But… You know, your body parts love you! They’re so happy to be in your inventory that they made a pact with the engine (as you may already realized, engine also loves them). Engine not only won’t allow you to remove them, restoring when necessary, but will also keep most of their IDs unchanged. Thus, significantly reducing a chance to find a range suitable for a safe playing. And, considering a runestones bomb…

Therefore it is a matter of chance, whether a saved game shortly before overflow can be repaired or not - in a tedious, manual way: If the highest item ID of such an additional, duplicate body part is low enough, it can be done, if it is high, this makes no sense.

I tried to reutilize free values. Advanced version of a fix intended to overflow counter to 2 ** 16 and then transfer all items back avoiding collisions. It’s like a sweeper game. The (not only) runestones bomb makes it extremely tricky if not impossible.

Another way to fix the bug once and for all could be, to update the function, that adds / creates new items in the player inventory, and make it reuse free item IDs. If the game scripts are created properly, and everything manipulating items uses the same basic services, then this would work even for games with only a few item IDs left. But I'm dreaming, in reality, there are probably numerous exceptions handling the stuff in another way.

Unfortunately, we either have to find the body of original function (assuming there is any) in scripts or write a new one and integrate it with… hm… Well, I did not even manage to find a definition of SItemUniqueID struct (which is, by the way, a TW2 legacy). The C++ dialect or whatever it is is not a problem. We simply does not have most important parts of the puzzle yet.

Effectively, the architects of the game engine tried to do the impossible and gained nearly nothing, beside an ugly bug: Increasing a counter instead of looking for a free, already used item ID is a bit faster, but if you have to do this only 64536 times at most during hundreds of hours, you gain nothing. To store about 1500 items with 2 byte ids, instead of using 4 byte ids like the running game, is 3 KB before compression, and nearly nothing after compression (maybe 2 bits per item, saved games are compressed in LZ4 chunks).

Initially it was OK - there are not enough space in TW2 to get this issue. But changing the type later, especially after the TW3 release, would require quite a refactoring and cause a lot of collateral damage. I mean, more bugs.

Enough rambling, this should be short. I'm waiting for feedback from ssdany, perhaps he will agree to upload his mod, then everybody could easily check, how many item IDs are left in a saved game.

Sorry, the code is probably bad, but I have neither the time nor the patience to elegantly fix something that developers do not care about. Regardless, here is what we have now:

Warning:

The main purpose of this mod is debugging and, in some cases, postponing the inevitable. It’s not a fix.

Functions:

highestID
Shows a highest ID (as a dialog box, sorry, so to dismiss it you have to close the console).

highestNoShowID
Shows a highest ID taken by an item with a ‘NoShow’ tag.

highestNoDropID
Shows a highest ID taken by an item with a ‘NoDrop’ tag.

showAll
Close inventory, execute this command and all items in your inventory will become visible and droppable. This is irreversible, so do not save after that. There is a way to allow ALL items to be visible, but I don’t like monkeypatching.

Yep, this mod changes (a very small portion, just a couple of lines) of existing functionality:

• ID will be displayed as a part of in-game notice about receiving a new item (in square brackets)
• hovering an item in the inventory will also display item ID (as well as internal name) - in a form of in-game notification in a bottom left corner.

liverHack
Will attempt to execute the overflow procedure:

• will create a lootbag and transfer all possible items into it;
• will increment ID counter to 2 ** 16. It will use a lot of “Wolf’s Liver” in the process, thus the name;
• will calculate the highest body part ID and increment ID counter to 2 ** 16 + calculated value.

1. It would be wise to unequip everything (including skills, mutagens, horse equipment) and get rid of weapon/armor upgrades before trying.
2. All items except body parts will be transferred into a lootbag. Some of them will be hidden and not lootable though:
   1. Removable hidden items (fists, scabbards): the game creates them automatically when necessary.
   2. Recipes and schematics: I think it’s a bad idea to add yet another hundred of items. Please notify me if disappearance of these “papers” will cause any bugs - I’ll change the code. Regardless, all recipes and schematics should still be available in related menus.
3. Gwent cards will be transferred into a lootbag. My first implementation caused them to be duplicated (thanks karlblau for testing). Hope it’s OK now.
4. You can call this function with an argument, e.g. `liverHack(43000)`. In this case it will use the number provided as a desired offset (new IDs will start from this value plus one).
5. Please note that resulting state may be worse that initial one, especially if you are near the limits. Save before and check after.

 

[DrDeathhand]

Sorry for silence. Spent couple of nights trying to do something acceptable with the bug.



It’s also a body part, in my case it was a `head_3`. And there are 2 such items during the tutorial section.



Oh, my first attempt for a fix was simple: drop all items, overflow to 2 ** 16, transfer everything back. This is how I met the Mighty Body Parts. All 16 of them. Initially, there are 10 at max and later you will receive new parts and copies of already existing ones. That’s the problem. Their identifiers can be spread across a very wide range (1-64802 in my case). And yes, you can’t remove them. There IS a function which allows you to “drop” them - DropItem. It accepts 2 arguments; the second one, if set to `true`, forces engine to really remove item from inventory. But… You know, your body parts love you! They’re so happy to be in your inventory that they made a pact with the engine (as you may already realized, engine also loves them). Engine not only won’t allow you to remove them, restoring when necessary, but will also keep most of their IDs unchanged. Thus, significantly reducing a chance to find a range suitable for a safe playing. And, considering a runestones bomb…



I tried to reutilize free values. Advanced version of a fix intended to overflow counter to 2 ** 16 and then transfer all items back avoiding collisions. It’s like a sweeper game. The (not only) runestones bomb makes it extremely tricky if not impossible.



Unfortunately, we either have to find the body of original function (assuming there is any) in scripts or write a new one and integrate it with… hm… Well, I did not even manage to find a definition of SItemUniqueID struct (which is, by the way, a TW2 legacy). The C++ dialect or whatever it is is not a problem. We simply does not have most important parts of the puzzle yet.



Initially it was OK - there are not enough space in TW2 to get this issue. But changing the type later, especially after the TW3 release, would require quite a refactoring and cause a lot of collateral damage. I mean, more bugs.



Sorry, the code is probably bad, but I have neither the time nor the patience to elegantly fix something that developers do not care about. Regardless, here is what we have now:

Warning:

The main purpose of this mod is debugging and, in some cases, postponing the inevitable. It’s not a fix.

Functions:

highestID
Shows a highest ID (as a dialog box, sorry, so to dismiss it you have to close the console).

highestNoShowID
Shows a highest ID taken by an item with a ‘NoShow’ tag.

highestNoDropID
Shows a highest ID taken by an item with a ‘NoDrop’ tag.

showAll
Close inventory, execute this command and all items in your inventory will become visible and droppable. This is irreversible, so do not save after that. There is a way to allow ALL items to be visible, but I don’t like monkeypatching.

Yep, this mod changes (a very small portion, just a couple of lines) of existing functionality:

• ID will be displayed as a part of in-game notice about receiving a new item (in square brackets)
• hovering an item in the inventory will also display item ID (as well as internal name) - in a form of in-game notification in a bottom left corner.

liverHack
Will attempt to execute the overflow procedure:

• will create a lootbag and transfer all possible items into it;
• will increment ID counter to 2 ** 16. It will use a lot of “Wolf’s Liver” in the process, thus the name;
• will calculate the highest body part ID and increment ID counter to 2 ** 16 + calculated value.

1. It would be wise to unequip everything (including skills, mutagens, horse equipment) and get rid of weapon/armor upgrades before trying.
2. All items except body parts will be transferred into a lootbag. Some of them will be hidden and not lootable though:
   1. Removable hidden items (fists, scabbards): the game creates them automatically when necessary.
   2. Recipes and schematics: I think it’s a bad idea to add yet another hundred of items. Please notify me if disappearance of these “papers” will cause any bugs - I’ll change the code. Regardless, all recipes and schematics should still be available in related menus.
3. Gwent cards will be transferred into a lootbag. My first implementation caused them to be duplicated (thanks karlblau for testing). Hope it’s OK now.
4. You can call this function with an argument, e.g. `liverHack(43000)`. In this case it will use the number provided as a desired offset (new IDs will start from this value plus one).
5. Please note that resulting state may be worse that initial one, especially if you are near the limits. Save before and check after.

Dear SSDany,

Thank you very much for posting your MOD.

I have downloaded it but I cant get it to work / I dont know how to get it to work.
I am not really an expert in these things so I probabbly forgot something.
I have extracted the MOD to the MOD folder in my Witcher 3 folder and I saw that the game loaded the scripts and stuff when I started the game.
But after that when I am ingame I do not know how to run the different options of the MOD.

So can tell me / us how to run it?