search

TheSil / base_enhanced

sil's base_enhanced server mod
3 stars 4 forks source link

Bug with randomly obtaining items #107

Open deathsythe47 opened 9 years ago

deathsythe47 commented 9 years ago

Sometimes in siege you obtain random items for no reason. You might just be standing in one spot and suddenly the game says "Obtained Portable Sentry" for no reason.

You can't actually use the item, but it's kind of an annoying bug for the game to tell you that you obtained it. I think it plays the sound, too.

Not just sentry, it happens with other items, too - shield, seeker, ammo dispenser, etc.

I'll try to find some demos...

TheSil commented 9 years ago

Demos would be interesting, because this might actually be a client side prediction problem. If that is the case, you will not be able to find any demos with this bug (prediction is not happening there).

deathsythe47 commented 9 years ago

Any thoughts from the demo I sent you? Maybe we need some logging for obtaining items?

dpadgett commented 9 years ago

plz to post the demos on the bug thread

TheSil commented 9 years ago

I have uploaded it here https://dl.dropboxusercontent.com/u/61761465/itembug1420.dm_26 (14:20, cannot be cut for reasons below).

I have briefly looked at it from the client perspective and there is indeed the pick up item entity, so this would seem to be caused by server. Interesting part is that when this demo is cut (even from like 13 minutes), this event disappears :o.

TheSil commented 9 years ago

Actually did more digging, and it seems to be caused by the fact that when client checks picked up item info, it does not care whether the info might be invalid (it seems this is even expected sometimes...). In this case the item entity is indeed invalid, so you will find whatever information was there from previous entity with this number. This explain why after cutting this behaves differently (therewas no entity at all known to the client, so it doesnt draw anything).

Now actual question is why client has not been sent info about the item he was supposed to pick. This will lead to some more server logs. It actually seems there is already one thing logged: "Item: %i %s\n"

Any chance you can get server log for this demo?

BTW: At 0:12 i noticed you obtained Large Shield Booster, isn't that bugged too?

dpadgett commented 9 years ago

ah, this can happen if more than 256 ents are spawned on the server at once. because the game sends the entity number of items in an 8 bit wide field. this happens a lot on my server too. there's a few possible work arounds, such as pre-spawning a copy of every item (there's not that many) and using one of those copies in the event. or, keeping a reserved pool of low numbered entities on server to use for spawning items.

TheSil commented 9 years ago

I guess there is not much we can do about this then, any entity with id greater than 255 will get screwed when sent in eventParms[1] field (8 bit), it seems to be alright when sent in eventParms[0] field, which for some reason has capacity for 16 bits :).

TheSil commented 9 years ago

Actually, we can force use of the eventParms[0], i have jsut tried it and it seems to work fine. Not sure how many problems it is gonna fix, but one simple and easy way to reproduce this is just go on mp/siege_hoth, get tech class, and keep spawning and picking ammo on the ground. Then when you pick it, sometimes you will not see the picked up animation, this is due to eventParms[1] field used.

Try the same with following commit and it seems to work always alright. This way we could perhaps fix another eventParms[1] bugs (if there are any).

TheSil commented 9 years ago

Nevermind, after testing a little bit longer, the bug is still there. Why they need to send entity number in 8 bit field...

dpadgett commented 9 years ago

yeah you cannot change which field it is sent in without breaking base clients.

dpadgett commented 9 years ago

see https://github.com/Razish/japp/commit/12297eeff0a25718e21cc60120e6537026c30cc0 which isn't working yet

ensiform commented 8 years ago

For whatever reason they decided to send the entity number instead of just the item modelindex like Q3 did. (And JKA still does for global item pickups) It seems they believed duplicate item pickup was an issue? But technically you cannot ever duplicate pickups (for real in a server).

I don't think you'll ever be able to fix this in a nice way without requiring the subsequent client mod to fix it.