Items are still vanishing from inventory

I was repacking gear between two teams and two Synedrion sniper helmets just vanished from inventory. I had 3 now I have 1.

I know about this problem:

and

… and because of that I didn’t scrap anything!

So items disappeared just because I unequipped some soldiers?!?

This game becomes burden to play if I have to constantly watch for missing items. Who ever programmed this part must be a pure genius.

Caught it finally. It is reproduceable.

Save file: https://drive.google.com/file/d/1Cwld4VAmKNHa8wXTURXtdx3kMTvdsXs4/view?usp=sharing

Picture 1, available armor:

Picture 2, going to ALL tab:

Picture 3, equipped soldier with grenade launcher (magazine is not full) and Synedrion pistol:

Note that now storage should be 164/200 but is 161/200

Picture 4, going on ARMOR tab and two pieces are missing:

For bug to reproduce grenade launcher (magazine is not full) and Synedrion pistol have to be added consecutively without changing tabs.

Bug will not reproduce:

  1. If after equipping grenade launcher (magazine is not full) you change tab to ARMOR again
  2. If grenade launcher magazine is full (more than 8 ammo in store)

How does this occur?! Being a programmer would drive me insane. Each patch seems to create a bug in a completely unexpected way. I read what they change - I read what new bugs occur - and I’m just confused and interested as to how it happened.

There must be part of code repeated many times in the processes:

“If at least 2 changes were made to this element, Then generate next random bug”.

1 Like

In programming there are “good practices” that every programmer should comply with. For instance writing “DRY” code (Don’t Repeat Yourself), or practice not to use “magic numbers”, or practice to write “unit tests” for every function you have in code. When you comply with this practices making bugs is much harder, and finding bugs is easier.

But when bosses and managers start to rush things up most programmers are compelled to deviate from good practices, because it is “faster” to do the job in dirty way. Ofc that “faster” becomes extra slow when you have to fix the bugs.

The problem is that today programmers became corporate drones. There is no more game enthusiasts who make good and quality games because they love to. Today game has to be released by some date, and if you don’t finish it there is no bonus for you at the and of the year… if you keep your job. And deadlines are given by managers who often don’t have a clue how much time is needed to program something.

I can’t claim that game code is written in dirty way, I don’t know that… but game is definitely rushed.

Sounds like every job I’ve had in this world. Never been a programmer though.

What should be done vs. What is done.

Kind of gross in restaurants.

Is this reality of video games? I doubt it if Larian did conference on all the automatic testing tools they develop and used to have a lot of automatic testing.

Moreover UI automatic testing is a lot harder even with good frameworks, I wonder if they have any for games using engines.

Nothing is simple, and any code is aging, with video games project that last years, and endure many changes, the aging is real even before release. It means that good practice stop work if you don’t refactor your code, and you won’t do it without have a backup of heavy automatic testing, and you won’t do it without great framework test.

That said, I would agree that all the problems around items management and inventory hints there’s something wrong in the core, a lot of garbage somewhere.

That’s why I wrote “unit tests” aka testing functions or methods, not UI testing. For unit testing there are frameworks for most modern languages. If they have method for adding weapon in soldiers inventory they certainly can test it. For instance “if grenade launcher added to inventory check how many items are left”. Or “There is X items in inventory. If random item is scrapped check how many items are left in inventory. If new number of items is not X-1 than report error”.

By not using good practices you can easily come in situation where code becomes unmanagable and where one bug fix makes more bugs (sounds familiar?).

And because of that more and more games come in unplayable condition on release. This trend will have to resolve. Or we will all become beta testers even if we paid for game and this will become new normal, or in the end players will reject those practices and start to massively demand refunds. Fool me once, shame on you, fool me twice, shame on me.

Got this today while moving armour off a new recruit for reverse engineering. It just disappeared. Very very annoying.

There’s UI unit test, but anyway, mock everything and do pure unit test, I doubt it’s for many projects. perhaps for video games. :slight_smile:

Very local unit testing requires mocks, mocks purely based on languages, eventually but it’s limited, mock often need a bit more thought.

But I know the topic for too few languages, it’s possible that pure unit test with mocks everywhere is at their disposal. Such unit test is limited.

For example the inventory bugs most certainly involves interaction between different sub systems, it’s hardly local bugs where they did +1 instead of -1.

Well good practices won’t stop regressions, automatic testing is the most powerful tool. I believe that dev know the good practices, and try apply them, now for automatic testing the topic is complicated, it’s probably the hole, but I’m not sure it is easy to manage as I already evoked.

Eventually, but it’s not that simple, an easy clone and simpler game with no bugs at release, myself I don’t exchange PP for that.

Automated unit testing is necessity in big projects. IMO there is no excuse to skip it.

I too believe that devs know and like the good practices. But I also believe they were forced by marketing guys to deviate from them to rush the project… and now they have very hard time fixing bugs.

I agree that this game has big potential. It could easily be the best UFO/X-Com like game at the end. If it survives all the refunds and bad publicity.

As PHP/JavaScript developer who works in scripting languages I can only trust you on that.

I am familiar with that concept, Node.js (JavaScript server) works exactly like that.

Nevertheless adding weapon to soldiers inventory, imo, should be synchronous and easily testable thing.

Yes, adding weapons would theoretically not be a coroutine. If they coded it in a nice, segmented way, it definitely would not need to be a coroutine (unless it needs to do a ton of update logic, which would cause the game to appear to freeze or hang up until finished, in which case a coroutine would be needed). Although the problem is assuming that it is that simple. Sometimes, as I am sure you know from reading other people’s code, people have a tendency to make things more complicated than they need to be.

But I like to give the benefit of the doubt when I can’t actually see the code. I am assuming that the issue is ultimately in integration of the “add to inventory” logic around multiple other more complex factors. Otherwise, there would be an issue in general any time things are added to inventory, rather than under specific scenarios, order of adding, etc. So given that, I want to assume that they at least had something unit-test-wise there, but just did not cover all scenarios or all facets of the inventory logic.

First it was this:
https://forums.snapshotgames.com/t/items-disappear-in-personell-screen-reproduceable-savegame

Then it was this:
https://forums.snapshotgames.com/t/missing-inventory-since-last-patch
https://forums.snapshotgames.com/t/missing-items-since-miskatonic-patch

And now this what I reported.

Looks that something is very wrong in that part of the code if bug keeps resurfacing.

Ads to my conviction that devs were rushed.

1 Like

Yeah. If it keeps happening, they need to desperately increase the testing coverage around it. Because any tiny tweak could break something that seems to be so fragile.

Not really, it’s just never been fixed. Which clues some garbage and multiple sub system interacting. Most probably for some reason responsibility didn’t get defined well for each sub system, often performances issues lead to weird design of responsibilities, or series of changes changed a cleaned code into garbage.

Could be. I Agree.

But at the end everything leads to the question when it will be fixed. And to fix it they need to allocate enough resources. Which leads to may question on other topic

DLC/bugs already got a comment, for now it’s no way the same tasks, that is pure code programming didn’t started for DLC, this was a post like 2 weeks ago.

How many is an insight they could not want divulge. You feel your harassment normal, I feel that ok you do what you want but for me you are heavy and have an inquisition spirit.

Yes, it was addressed. But in a way that only PR manager could do, making sentences that look good and not saying anything specific.
“We’ve said we’re working on balance and we’re working on fixing bugs. At the same time, we’ve got another team working on DLC.”.
What does that means? 2% on bugs, 98% on DLC or vice versa.

They could answer in percentages. For instance 70% works on bugs, 30% on DLC. But by being quiet they let me believe the opposite.

Yes I have heavy character, I admit… But after reading lot of your posts feeling is mutual.

1 Like

Just an FYI Zzzz, for future reference. Harassment is a very strong word for what djoles77 is doing. In English, that goes into “illegal” territory. I think the word you are looking for instead is “criticism”.