Pages: [1] 2
  Print  
Author Topic: CG_REGISTERITEMVISUALS: ITEMNUM XX OUT OF RANGE [0-60]  (Read 47920 times)
GrosBedo
Member


Cakes 20
Posts: 710


« on: May 17, 2010, 06:41:06 PM »

Hey there Smiley

The last OA v0.8.5 produces a weird bug when playing on servers with mods and cl_allowdownload 0 on client :

"CG_REGISTERITEMVISUALS: ITEMNUM XX OUT OF RANGE [0-60]"

The number behind XX can change (Ive seen 446, 70, etc...).

It arises at random times, but usually only seconds after connecting to the server (with bots, without bots you can stay as long as you want, but I think that they only simulate players taking weapons and doing stuffs).

This problem doesn't happen with 0.8.1.

Mod tested : Excessive Plus v2.0a

Any explanation ? Any possible fix or workaround ?

Logged
RMF
Member


Cakes 12
Posts: 694



« Reply #1 on: May 18, 2010, 04:22:56 AM »

iirc same as what happens to players who join with the 085 patch on our server. Spectating is possible but if you join you get this error. It doesn't happen if you downloaded the patch here instead of autodownload. Server runs 081 with oanage mod, but we had the same prob without mod.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #2 on: May 18, 2010, 09:24:16 AM »

For me, the bug happens even if I only spectate (but players/bots must be added).
Logged
TwEeK!
Nub


Cakes 2
Posts: 20


« Reply #3 on: May 20, 2010, 02:56:39 AM »

I get spanked by this quirk as well, wasn't sure exactly what was going on because I was only able to stay in-game for a few seconds before getting dumped out with the same type of messages (and I'm pretty sure the opponents didn't speak much English, and I didn't have time to figure out what language they were speaking Undecided).

One difference in my case, perhaps - I have a VERY clean install on my main box (because when I first tried to do a lazy, simple upgrade by slappin' in the 0.8.5 patch into an old, tired, loaded beat-up 0.8.1 installation, I had all sorts of unpleasant funkiness, which was subsequently solved quite easily by putting together a fresh 0.8.1./0.8.5 setup by hand, which works beautifully). But I do often pick up maps, and I suppose mods on-the-fly via auto-download. It's almost certainly the case in this situation that I got the mod via auto-d/l. But I definitely can confirm being affected by this while still having very clean primary game files.

I'll try to go make a donkey's rear end of myself again on that server - it seemed like the other players were really havin' a laugh at me comin' into the game and suddenly exploding into the ether time after time. And I'm GOOD at that.... ;-)

          -- TwEeK!
Logged
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #4 on: May 29, 2010, 03:20:22 PM »

I didn't read carefully, but menga is tell me he has some similar problem so I answer here.
If I'm not wrong, it's a problem related to a conflict with QVMs.

If servers don't update, they run the older QVM. So if you playback a demo, remove your patch085.pk3 (because it contains recent QVM) and it should work.
« Last Edit: May 29, 2010, 03:32:10 PM by Cacatoes » Logged

Todo: Walk the cat.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #5 on: July 30, 2010, 11:25:10 AM »

Yes, the solution for now : either remove the 085 pak and then players can connect without autodl, or force autodl the mod, then the conflicting oa 085 vms won't be loaded.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #6 on: August 03, 2010, 04:49:57 PM »

Some more infos about this bug :

This bug indeed resides clientside in the 085 pak, binaries (even the latest from the test thread) can't fix (or reproduce alone) the problem.

This bug is particurlarly critical as it destroys any possibility to make serverside, or any unpure (sv_pure 0), server.

Description :
If a client with the file pak6-patch085.pk3 connect to a server with an older version or a mod WITHOUT sv_pure (and the client hasn't the mod nor autodownload), then as soon as the client join the game and takes a weapon (test with plasma on oasago2), then he gets kicked out with this error.

How to reproduce this bug :

1- Launch an OA 081 server with sv_pure 0.
2- Launch an OA 086 client (with the patch pak) and connect to the OA server.

----------------------------

Here is the code from the Q3 sources :
Code:
 833 /*
  834 =================
  835 CG_RegisterItemVisuals
  836
  837 The server says this item is used on this level
  838 =================
  839 */
  840 void CG_RegisterItemVisuals( int itemNum ) {
  841     itemInfo_t      *itemInfo;
  842     gitem_t         *item;
  843
  844     if ( itemNum < 0 || itemNum >= bg_numItems ) {
  845         CG_Error( "CG_RegisterItemVisuals: itemNum %d out of range [0-%d]", itemNum, bg_numItems-1 );
  846     }
  847
  848     itemInfo = &cg_items[ itemNum ];
  849     if ( itemInfo->registered ) {
  850         return;
  851     }
  852
  853     item = &bg_itemlist[ itemNum ];
  854
  855     memset( itemInfo, 0, sizeof( &itemInfo ) );
  856     itemInfo->registered = qtrue;
  857
  858     itemInfo->models[0] = trap_R_RegisterModel( item->world_model[0] );
  859
  860     itemInfo->icon = trap_R_RegisterShader( item->icon );
  861
  862     if ( item->giType == IT_WEAPON ) {
  863         CG_RegisterWeapon( item->giTag );
  864     }

Where can I get the list of items please ? Because it seems that it doesn't really comes from a new item, but a new HUD addition (particularly you can notice a health icon on the right side, which turns into some buggy icons sometimes like when you pick a rocket launcher, see attached image).

------------------

/EDIT : I've found an old post on the OA085 RC1 test thread :
http://openarena.ws/board/index.php?topic=3374.msg28310#msg28310

In this thread it is argued that this a bug from OA 081, but these tests shows that is _not_, since the same bug with the same numbers happens with serverside mods which replaces the vm (ExcessivePlus does _not_ use OpenArena as a base for the vm but Quake 3, so there's no reason the bug would come from their vms too).

And I'm more and more convinced that this comes from the buggy icons on HUD.
« Last Edit: August 03, 2010, 05:06:39 PM by GrosBedo » Logged
smcv
Nub


Cakes 5
Posts: 23


ioquake3/OA/Q3 Debian maintainer


« Reply #7 on: August 21, 2010, 10:21:14 AM »

I've been investigating similar problems in Debian, after updating our OpenArena packages to 0.8.5.

This bug indeed resides clientside in the 085 pak, binaries (even the latest from the test thread) can't fix (or reproduce alone) the problem.

Looking at the code, I'm fairly sure this is caused by a couple of incompatible changes in the qagame and cgame modules in the pak file, related to the introduction of persistent powerups (runes). 0.8.1 baseoa was approximately compatible with Quake III Arena (baseq3), whereas 0.8.5 baseoa is approximately Team Arena (missionpack) which is not compatible.

The problematic changes seem to be:

* 0.8.5 adds STAT_PERSISTANT_POWERUP into the middle of an enum in bg_public.h, changing the numeric values of all subsequent entries in that enum, but the members of that enum are indirectly used in the network protocol (as indexes into the stats array)

* 0.8.5 adds items into the middle of bg_itemlist in bg_misc.c, but numeric indexes into bg_itemlist are part of the network protocol

As a result, the 0.8.5 cgame module will misinterpret network messages sent to it by the 0.8.1 qagame, causing the crashes you saw.

In particular, if you pick up a weapon, the 0.8.1 server will update your STAT_WEAPONS stat and send it to you, but the 0.8.5 client will misinterpret it as STAT_PERSISTANT_POWERUP (because S_P_P in 0.8.5 has the same numeric value as S_W in 0.8.1). If STAT_WEAPONS is greater than 60, you'll get "itemnum xx out of range".

STAT_WEAPONS will always be greater than 60 if you have the lightning gun, railgun, plasma gun or BFG; it can also be greater than 60 if you have a lot of lower-numbered weapons.

This bug is particurlarly critical as it destroys any possibility to make serverside, or any unpure (sv_pure 0), server.

We've been particularly hit by this in Debian because we're using native-code game logic (the bytecode versions can only be compiled with q3lcc, which doesn't have a suitable license for Debian main, so we can only keep OpenArena in Debian if we discard the QVMs and use native code). I added some patches to the engine to do this in a way that bypasses the normal pure server mechanism, so that we can still be compatible with normal servers, but this meant we ended up running the 0.8.5 game code at all times.

I have some patches to give Debian's OpenArena two incompatible copies of the native code and make it choose between them based on the QVM that was requested, so it can behave the same as the official OpenArena and 0.8.1 pure servers can work again, but impure servers are still problematic.

Where can I get the list of items please ? Because it seems that it doesn't really comes from a new item, but a new HUD addition (particularly you can notice a health icon on the right side, which turns into some buggy icons sometimes like when you pick a rocket launcher, see attached image).

I'm fairly sure the incorrect HUD icons don't cause the disconnection, but they're closely related - they're another symptom of the same incompatibilities, caused by the changes to bg_itemlist.

The Debian bug where I've been working on this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592965.

In this thread it is argued that this a bug from OA 081, but these tests shows that is _not_, since the same bug with the same numbers happens with serverside mods which replaces the vm (ExcessivePlus does _not_ use OpenArena as a base for the vm but Quake 3, so there's no reason the bug would come from their vms too).

Basing ExcessivePlus on vanilla Quake 3 probably means its qagame.qvm is compatible with baseq3, whereas OpenArena's cgame.qvm is now more like Team Arena, so no, that won't work...
Logged
smcv
Nub


Cakes 5
Posts: 23


ioquake3/OA/Q3 Debian maintainer


« Reply #8 on: August 21, 2010, 10:27:33 AM »

From the other thread you linked:

You should be able to play a 0.8.1 demo in 0.8.5 but not the other way around.

0.8.5 has a bigger range than 0.8.1, so if the demo has an itemNum 62 then it must be a bug in 0.8.1

itemNum 62 would be the 0.8.1 server sending stats[STAT_WEAPONS] = 62 and the 0.8.5 client misinterpreting it as a persistent powerup number; 62 = 32 + 16 + 8 + 4 + 2 which would mean you had the rocket launcher, grenade launcher, shotgun, machine gun and gauntlet.

I've also seen this triggered by spawning and picking up a lightning gun, which results in itemNum 70, which is 64 + 4 + 2 (lightning gun, machine gun and gauntlet).
Logged
smcv
Nub


Cakes 5
Posts: 23


ioquake3/OA/Q3 Debian maintainer


« Reply #9 on: August 21, 2010, 10:59:58 AM »

I've opened <http://code.google.com/p/oax/issues/detail?id=3>.

I suspect that the way forward is to declare 0.8.5 to be the new thing to be compatible with. This would mean that:

* 0.8.5 and later clients can't join impure 0.8.1 servers
* 0.8.1 clients can't join impure 0.8.5 and later servers
* 0.8.5 and later versions interoperate (unless you break compatibility again - please try not to Smiley)
* every server-side mod has to be modified to be similar to 0.8.5/missionpack instead of 0.8.1/baseq3

An alternative would be to remove the missionpack items from bg_itemlist and statIndex_t, and re-add them at the end of the array/enum, write off the 0.8.5 compatibility break as a mistake, and release a 0.8.6 pk3 which only makes bugfix changes to the VMs. This would mean that:

* 0.8.1 clients can join impure 0.8.6 servers, but only if none of the new 0.8.6 items are actually present on the map
* 0.8.5 clients can't join impure 0.8.6 servers (a similar disconnection will occur)
* 0.8.6 clients can't join impure 0.8.5 servers (a similar disconnection will occur)
* 0.8.6 clients can join impure 0.8.1 servers
* 0.8.6 clients can join impure baseq3-based mod servers

If 0.8.6 was released like this right now, I'm not sure whether I could get it into Debian 6.0 or Ubuntu 10.10 (the Debian repository has already been frozen, so only minimal changes will be accepted), so the first option would be preferable from my point of view!
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #10 on: August 21, 2010, 11:54:47 AM »

OpenArena depends on sv_pure being enabled for determining if patches should be loaded or not. That will not change. This not just about the qvm files but maps too.

I did experiment with trying to get the server to load a pk3-file that was not part of the pure check, so serverside mods could go in there, but I never succeeded.

The real reason this problem bothers me is that it affects demos that apparently does not contain a list of files to load. They break even with sv_pure.
Logged

There are nothing offending in my posts.
smcv
Nub


Cakes 5
Posts: 23


ioquake3/OA/Q3 Debian maintainer


« Reply #11 on: August 21, 2010, 12:36:59 PM »

OpenArena depends on sv_pure being enabled for determining if patches should be loaded or not. That will not change. This not just about the qvm files but maps too.

OK, thanks for your feedback. To be clear: it sounds as though you'll be keeping this change in 0.8.6, and possibly making further network-incompatible changes in future. Is that true? (I ask because the answer affects how I package OA in Debian.)

Quote
The real reason this problem bothers me is that it affects demos that apparently does not contain a list of files to load. They break even with sv_pure.

As far as I can tell, bumping the protocol number doesn't alter how demos are played either, so if you want to keep the ability to play old demos, you can never make incompatible changes like these, only incremental changes that don't "break ABI" (add to the end of enums, add to the end of bg_itemlist, etc.).

With my software engineer hat on (it's my day job), if you do want to make incompatible changes, the cleanest way to do so would be to keep BASEGAME as baseoa, then use a different fs_game for each incompatible version - assuming you intend 0.8.x (x > 5) to stay compatible with 0.8.5, perhaps OpenArena 0.9.0 could be baseoa0.9 and so on?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #12 on: August 21, 2010, 02:42:49 PM »

OpenArena depends on sv_pure being enabled for determining if patches should be loaded or not. That will not change. This not just about the qvm files but maps too.

OK, thanks for your feedback. To be clear: it sounds as though you'll be keeping this change in 0.8.6, and possibly making further network-incompatible changes in future. Is that true? (I ask because the answer affects how I package OA in Debian.)
There might be further changes in the future. You will likely never be able to use a .so-file to replace more than 1 .qvm-file. Even if changes are not technically network-incompatible there might still be new commands that are annoying to miss. For instance the Vote Map Change menu in 0.8.5 would be quite useless on a 0.8.1 server because the 0.8.1 server does not send a list of available maps. The current Vote Map Change menu uses a rather ineffective network structure it is one of things likely to change.

Quote
The real reason this problem bothers me is that it affects demos that apparently does not contain a list of files to load. They break even with sv_pure.

As far as I can tell, bumping the protocol number doesn't alter how demos are played either, so if you want to keep the ability to play old demos, you can never make incompatible changes like these, only incremental changes that don't "break ABI" (add to the end of enums, add to the end of bg_itemlist, etc.).

With my software engineer hat on (it's my day job), if you do want to make incompatible changes, the cleanest way to do so would be to keep BASEGAME as baseoa, then use a different fs_game for each incompatible version - assuming you intend 0.8.x (x > 5) to stay compatible with 0.8.5, perhaps OpenArena 0.9.0 could be baseoa0.9 and so on?
Why I usually add to the end of an enum list I do know why STAT_PERSISTANT_POWERUP was added in the middle of the list... it was already written there in an #if-caluse.

Some of the current data structures have no nice way of being extended. Forcing bad code to keep network compatibility are not very good either.

Splitting in different fs_game has some currently unresolved problems like keeping the config files in sync. Solving the problems that is causing people to disable sv_pure might be easier.
Logged

There are nothing offending in my posts.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #13 on: August 24, 2010, 08:17:27 AM »

Thank you both, you rock. Truly.

Quote from: sago007
Splitting in different fs_game has some currently unresolved problems like keeping the config files in sync.

I know it's not so clean, but with launchers it's possible to fix this problem. Why not always write the config file to fs_basepath/baseoa ? Or at least give the option.

Quote from: sago007
Solving the problems that is causing people to disable sv_pure might be easier.

Personally it's to prevent people from having to autodownload a serverside mod. I would be ok to leave sv_pure, but then we need an exceptionfilter cvar to be able to specify which files needs not to be autodownloaded by the client.

To be more precise, what I wanted to do is set sv_allowdownload 1 and sv_pure 0, so people with cl_allowdownload 0 could connect without downloading anything, and people with autodownload would download the full mod and then connect. Everyone is happy.

--------------------------

I know you want to merge OAX with OA, because the code has much more functionalities, possibilities and is easier to maintain. But compatibility should be kept at all cost, because this is one of the main aspect of this game : the wide variety of mods available.

Now maybe a good way would be to do it the opposite way : making OAX the default baseoa, but keep old baseoa as legacyoa, as a mod, so old servers and serverside mods could use it.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #14 on: August 24, 2010, 03:54:43 PM »

Now maybe a good way would be to do it the opposite way : making OAX the default baseoa, but keep old baseoa as legacyoa, as a mod, so old servers and serverside mods could use it.
I have thought about. But ultimately I would like to improve the autodownload system, because most serverside mods that I know about have an albeit optional cgame that is only optimal because the current system makes it to difficult to make permanent.
Logged

There are nothing offending in my posts.
cheb
Lesser Nub


Cakes 3
Posts: 127



WWW
« Reply #15 on: November 06, 2010, 09:23:19 AM »

So, from the pure consumerist point of view: When will I be able to play back the demos where I recorded my awesomeness? Without 9 of 10 of them breaking? Huh
Logged

Imma lazy dreamer. I achieved nothing.
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #16 on: November 06, 2010, 01:18:39 PM »

Switch between PK3s, that should work.
That means, remove your patch085 pk3 when you play the demo, or run some old version of OAX.
Logged

Todo: Walk the cat.
St0n3*r
Half-Nub


Cakes 6
Posts: 82

Welcome in the ★revolution world :P


WWW
« Reply #17 on: November 06, 2010, 02:15:41 PM »

remove move out folder is enought Tongue
"consumerist" mmm hate this word  Rest In PEACE!
Logged

sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #18 on: November 06, 2010, 02:22:07 PM »

So, from the pure consumerist point of view: When will I be able to play back the demos where I recorded my awesomeness? Without 9 of 10 of them breaking? Huh
The day the demo-files contains a list of files to load.
Logged

There are nothing offending in my posts.
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #19 on: November 06, 2010, 06:05:28 PM »

remove move out folder is enought Tongue
Enought is enough. Tralalere.
Logged

Todo: Walk the cat.
heap
Nub


Cakes 3
Posts: 5


« Reply #20 on: November 07, 2010, 06:29:27 AM »

I am glad to see this topic popped back up.

GrosBedo (supeR,Grism) started this topic mainly for one reason. He and me wanted to set up a serverside-mod only server with OA 0.8.5 and excessive plus v2.0a / v2.1.  But we failed. We failed because of that bug/error discussed here. Our problem wasn't sv_pure 0/1 setting. Because the mod, when run serverside-only causes this bug wether sv_pure is set to 1 or 0. No difference.

Well first I was glad to see that this Bug was added to the List of known Bugs: DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs#Known_bugs_and_status_in_0.8.5:](DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Bugs#Known_bugs_and_status_in_0.8.5:

But i saw on the OAX project page that this bug was asigned with low priority and thus maybe won't get fixed for 0.8.6. I would like to gently ask the developers (especially sago007) to maybe prioritize this bug some more.

This bug doesnt only affect sv_pure servers or demo playback which could be fixed easily by just setting sv_pure to 1 or  by just deleting the 0.8.5 patch. This bug prevents siverside-only mods to be run.

I didnt update all supeR,Servers because of that and some other bugs. And i wont do so till this gets fixed (this is not meant to pressure you guys, no offence, but just to let you know why i didnt provide the 0.8.5 patch).

At the moment I try to find a way for me as a server administrator to get closer to the development of this game. meaning i could provide a lot of information and featurerequests that i have to make my servers even more attractive. Maybe you guys could tell me the best way to get in contact with you for such matters.
Logged
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #21 on: November 07, 2010, 06:39:16 AM »

Maybe you guys could tell me the best way to get in contact with you for such matters.
I think you're doing well by posting on this forum Wink
Logged

Todo: Walk the cat.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #22 on: November 07, 2010, 07:18:23 AM »

But i saw on the OAX project page that this bug was asigned with low priority and thus maybe won't get fixed for 0.8.6. I would like to gently ask the developers (especially sago007) to maybe prioritize this bug some more.
It likely won't be fixed in 0.8.6. It is a fundamental flaw in the engine. Alone fixing the demo problem is likely a protocol breaking change.

A serverside mods are by design hardcoded to the version they are released for.

The solution I am working on is about the autodownload system, so that mods can provide a cgame.qvm. Mods that has a cgame.qvm works across versions.

There two changes I want:
1. Nothing downloaded may corrupt the game, it should be perfectly safe to have enabled.
2. The speed in cases without a http-server (LAN parties) needs to be faster.

I have started on 2 first. It is not the fastest work in the world. Currently I stand with the problem that I need to send unreliable packets and the message mechanism is ordered and reliable by design.
Logged

There are nothing offending in my posts.
heap
Nub


Cakes 3
Posts: 5


« Reply #23 on: November 07, 2010, 07:37:05 AM »

It likely won't be fixed in 0.8.6. It is a fundamental flaw in the engine. Alone fixing the demo problem is likely a protocol breaking change.
uh.. damn Sad

A serverside mods are by design hardcoded to the version they are released for.
meaning what? there is a Q3 and OA version of excessive plus available. I used the OA version for sure, but could it be compiled for the 0.8.1 and thus throwing the error? Could this be fixed by excessive plus developers by recompiling it for 0.8.5?
The solution I am working on is about the autodownload system, so that mods can provide a cgame.qvm. Mods that has a cgame.qvm works across versions.
excessive plus has a cgame.qvm. but if you want to make it downloadable it wouldnt be a serverside mod only anymore... or am i missing anything there?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #24 on: November 07, 2010, 08:16:21 AM »

there is a Q3 and OA version of excessive plus available. I used the OA version for sure, but could it be compiled for the 0.8.1 and thus throwing the error? Could this be fixed by excessive plus developers by recompiling it for 0.8.5?
Well, unfortunately not that simple. smvc pointed out a change that breaks between 0.8.1 and 0.8.5. Generally Excesive plus already handles a lot of the other changes (by ignoring unknown/new messages) and should have handles the transformation from 0.8.1 to 0.8.5 without problem has it not been for the uncommented (STAT_PERSISTANT_POWERUP).

I normally try not to break things but did not give it much thought then removing the #ifdef because it was original idSoft-code.

Once released this is a not going back, so STAT_PERSISTANT_POWERUP will stay where it is now. Changing it back will just break all 0.8.5 demos instead. Currently I don't believe that anything that will break in the near future. But keeping bad code to preserve compatibility can force the programmer into writing even more bad code.

excessive plus has a cgame.qvm. but if you want to make it downloadable it wouldnt be a serverside mod only anymore...
Why is it so important that it is a serverside only mod?
Why is it so important that the clients does not have the cgame from Excessive plus?
Logged

There are nothing offending in my posts.
Pages: [1] 2
  Print  
 
Jump to: