Low Priority [4.1] Bug or something else? itemname_hatch_11D_03 found repeatedly in jungle

[Tingyun]

@Pieter Boelen @Jack Rackham @Levis @ANSEL

Found the source of the bug!

See my previous post for proof it was caused by the recent update. By installing the folders one by one, then the files, then using winmerge to check the lines, and testing on backups of my folder, I can confirm the bug is from the new (and moved) Jack Rackham items contained in initItems.c

Specifically, in the latest update, some building and quest items were moved in location, and a few new ones added. When I reverted those specific lines to the July 28th version, and kept all other changes to the file from the update, the bug is fixed.

Attached find a version of inititems.c that fixes the bug, with the new items and moved items reverted (so about 6 lines reverted to the previous version). All other changes intact.

Also, a save so you can easily test yourself if you prefer. Load the save, right in front of you will be the improper item. Reinitilizing under the following conditions produces the following results:

1) if using July 28 version, reinitilizing transforms the itemname_hatch_11D_03 into a purse of 100 gold (the graphic will only change if you switch scenes, but you can immediatlly press spacebar to pick it up and it will already be transformed)

2) if using most recent update zip file, reinitilizing does nothing, it remains the bugged itemname_hatch_11D_03

3) If using most recent update + my modified initItems.c attached to this post, reinitilizing fixes the glitch and itemname_hatch_11D_03 transforms into the purse of 100 gold.

Now, I don't know whether there is something specifically wrong with the new lines I reverted, or whether this is a compatibility issue where saved games are incompatible with additions or moves to the item file. But for now, the attached file will preserve saved game compatibility.

EDIT: Haha, simultanous post with Pieter. Yes, your guess was correct.

 

[Tingyun]

Something interesting that may help in figuring out why the new/moved items created this problem:

In the attached saved game, I am standing where I think the church protection quest to retrieve the items from the lost monk should be (which according to the walkthrough should be a book and gun Church Protection | PiratesAhoy! ).

However, no items are present currently.I had been here earlier, and had picked up a four barrel grapeshot pistol (which shouldn't exist, given the golden age period) and another item (forgot what it was). Both were picked up from the ground, with the hand icon.

I have tried talking to the monk, but I can't continue the quest. Consoling in the items worked fine and allowed the quest to complete (GiveItem2Character(PChar, "LongRifle_C"); GiveItem2Character(PChar, "book_exorcist"); ).

What I think happened is this: the game replaced the rifle with the 4 barrel grapeshot pistol, which appears 2 lines above the rifle in the items file.

I think this was probably caused by the same issue reported in this thread, as I picked up the 4 barrel grapeshot pistol after updating but before reverting the new and moved items. So the glitch happens in defined items as well as random items in the jungle, and maybe the two line difference between the rifle and 4 barrel grapeshot pistol isn't a coincidence.

 

[Jack Rackham]

I'll look at it when I find some time. Today I'm moving back to my winter house though.

 

[Tingyun]

Jack,

This issue isn't urgent at all. Anyway, I suspect it will turn out there was nothing wrong with any of the changes, but that new or moved items are not fully saved game compatible, and regularly cause these glitches (which would explain why Ansel had the bug in the past, and then after starting a new game did not hit the bug again until recently).

I'm just reporting additional notes to provide maximum information, not to imply urgency, the file I posted fixes compatibility for current campaigns fine for now.

 

[Pieter Boelen]

I wonder if there is code in place to always put a Quad Barrel Gun in place somewhere?

 

[Tingyun]

Pieter,

I did figure the quad barrel gun was intentionally placed at first. It was only after I exhausted the crypt yesterday (mapping every room), and did not find the rifle, that I suspected this room with the body was where it was supposed to be, and that the quad barrel gun I had picked up last week had replaced the rifle.

I still don't know. I just figured best to post the saved game showing the room for reference (on the chance it might be helpful while looking into this glitch, since it occured before I reverted the item additions/movements, and the two line distance between rifle and wuad barrel grapeshot pistol entries in the file seemed interesting). But maybe the pistol wasn't a bug at all, indeed.

 

[Pieter Boelen]

Will need checking anyway.
Maybe make a separate Bug Tracker entry about it showing up?

 

[Tingyun]

Ok, will do!

 

[Pieter Boelen]

This seems to be by far the worst new issue recently introduced.

From what I understand, it is NOT in the current EXE (28 Jul 2016), but IS in the newer ZIP.

What I'd very much like to know is if the messed up random item appearance also occurs if a New Game is started with this ZIP.
Or is it only when continuing on a savegame, with or without using Reinit?

 

[Tingyun]

Pieter,

I think last plan was @Jack Rackham was going to look into this and see if there was a problem with introducing new items, or moving items around in the file (both of which would be just save compatibility I guess), or whether there was truly wrong with the item lines themselves.

Right now the old version of the items file with his items has been displaced by 5 or so generations of item file changes, the most recent of which was my gun price rebalance editing Levis's skill item complete reorganization of the file. All of these were based on my original deletion of Jack Rackham's new and moved items, so no recent item file in use had the problem items.

Then Jack just posted the baker rifle, which presumably used the same file but added the baker rifle line (not sure if he readded his new items yet). We should have one with new items soon though, even if that one doesn't.

Even then testing for the glitch is not simple: it affects some random items, not others.

Considering this did affect a player previously (ANSEL I believe) and it cleared up for him those many months ago after he started a new campaign, then I think if Jack Rackham cannot find anything wrong with his new items or his edited lines, then we should assume it is a save compatibility issue. Jack should read the items, but avoid moving existing items this time (leave everything where it is in the file). Then we release that version, and we should have a range of people who play either new or old campaigns.

If no one encounters the problem again, then it was likely from moving the items, not the new items. If only current campaign people encounter it, then we know it is from the new items. All best discovered through play reports, rather than dedicated tests, since it is a random item bug that only sometimes happens.

From recently reworking the weapon equipment code, I have a bet at where the bug comes from. It seems the random item selection often works by generating a list of items ordered from some min level to some max level. I think moving items around or adding new ones could mess that up if the saved game is storing things by number or something to designated locations.

From what I saw, the weird items only appeared in currently generated items already sitting on the floor in the current save, and once you picked up the weird item, when the location regenerated a new random item, it would be normal again. I tested that out multiple times.

So that leads me to think it is purely a save issue. New or moved items mess with the way saved games refer to currently existing objects. If Jack Rackham can find nothing wrong with his new items, I say release with them (but don't move current ones around).

summary: in other words, I think we already have good tests. In a current game, the bug doesn't appear until you reinitilize, and then only current items already generated transform. If picked up, the random item spawn point behaves normally going forward, at least when I tested it 5 times. All points to a save compatibility issue, but Jack Rackham should look at he items once more to be sure, and avoid moving items around and just add the new ones.

 

[Jack Rackham]

"Items moved around" occurs for ex when some of my buildingitems should be used for general purpose
in ALL storylines. Like when @Levis moved a door I think for the Cartagena hotel. So it's not that easy
that I just can stop moving things around.

Guess you have to start a new game.

 

[Tingyun]

Jack, I'm not worried about starting a new game, I was just thinking to try to better trace the source of the glitch so we know what action causes it. If you have examined your items and there is no problem with them, I am 100% in favor of you doing everything you need to do in editing that file. Move, add, delete, let's get what you need out there, of course!

(because I won't be starting a new game anyway, I'll be using winmerge to make myself a save game compatible version for until my current campaign wraps up )

 

[Pieter Boelen]

From what I saw, the weird items only appeared in currently generated items already sitting on the floor in the current save, and once you picked up the weird item, when the location regenerated a new random item, it would be normal again. I tested that out multiple times.

That would actually explain a lot. Sounds like then Reinit works exactly like it should, which is good to know at least.
But existing random items still have an index value pointing to what is now a different item.

Would you guys say that is pretty much confirmed? Or is it still a quite plausible assumption?

What I'd very much like to know is if the messed up random item appearance also occurs if a New Game is started with this ZIP.
Or is it only when continuing on a savegame, with or without using Reinit?

If anyone is able to answer that, it would certainly add further proof.

For certain I'll look at initItems.c when finally updating my own game as well.
But if you're right, then indeed there is nothing to find there. Which would suit me just fine.

 

[Tingyun]

New game started with aug levis update zip and all content patches released since (plus my experimental modification). Itemfile includes all of Jack rackham's items and the baker rifle, so roughly in the same state that caused the glitch before with current campaigns.

Picked up around 10-15 random objects around barbados, all within the normal item range. No weird items at all so far.

Combine that with Ansel having experienced the bug in the past, and the having it resolve on him starting a new game, I think we can confirm this is simply a save compatibility issue that comes up when new items are added or moved around.

 

[Pieter Boelen]

Thanks! Then I think we know how this bug gets triggered:
Random items are already generated and then the item IDs and indices are shuffled around and those random items aren't updated to match.

That makes it a real bug, but an easily avoidable one.

 

[Levis]

So are we going to keep this on in the bugtracker? I would sugest to move it to buidl 15 brainstorming because its not really a bug, but more something which might be nice to have at a certain point.

 

[Pieter Boelen]

I do wonder if something could be done in Reinit to loop over all locations and swap out the random items with their new IDs/indices.
That should solve it properly.

 

[Levis]

I do wonder if something could be done in Reinit to loop over all locations and swap out the random items with their new IDs/indices.
That should solve it properly.

it could be done, but that before the reinit you first need to check ALL locations and store theire item ID's.
Then you need to do the reinit.
now you need to loop trough ALL locations again and change the idx again to fit the right ID's you stored.
Might be easier then to see if we can change the random items so it stored ID's instead.