OpenArena Message Boards

not sure if this is the right location but anyway

has anyone ever noticed how you cannot playback

0.8.1 or any other kind of demos [0.7.1 ,0.7.6 , etc]  on a 0.8.5 openarena?


will this be fixed in 0.8.8

and will folders be added



example: say if the demos are in a folder they are not seen in the demos section.


EDIT: it is seen only under Q3 with folders

It has been noticed. The demo files does not contain information about what files are needed to play them, so it justs attempts to play them anyway. To fix this will likely require a change in the demo format and that would only fix the problem going forward. This is not part of 0.8.8

Did you really change anything of the net protocol? Otherwise you should be able to play Quake 3 1.32c .dm_68 files by just renaming them (or ignoring their file extension code-wise). Just bumping the protocol number does not make demos incompatible.

Searching folders recusively for demo files might not be a good idea. You should still be able to run "/demo some/folder/with/demos" from the ingame console.

I just tested playing demos, recorded with v0.8.1 and others with with v0.8.5.

There's some kind of compatibility, so that demos recorded with v0.8.1 are also playable with v0.8.5, but you get some icons bugs, that probably has its root to the same problem as the "CG_REGISTERITEMVISUALS: ITEMNUM XX OUT OF RANGE [0-60]" bug pointed in this thread:

http://openarena.ws/board/index.php?topic=3717.0

On the other side, demos recorded with v0.8.5 are fully playable with v0.8.1 (unless there are special weapons such as chaingun or mines or "shardgun" - can't remember the real name).

So, normally, demos recorded with lower versions than v0.8.1 should be playable with v0.8.5. Anyway, if you encounter a problem, you can simply rename temporary the 085 pk3 file, because there's no change in the binaries (I tried, binaries are clean, the only thing that changes the recording is the 085 pk3).

This problem might also be related with the maps. Between versions, maps get changed.

Though IANAC, so I might be wrong.

so can it be added?


or fixed?

Just rename the 085 pk3 to another extension when trying to open an old demo, and see if that works.

Why not juust ask the devs to fix it?

Renaming it is honestly a hassle

Because there's no real problem, this is not due to some weird new ultra complicated functionnality but due to adding the team arena weapons and items in OpenArena standard. So the simple fix would be to remove completely these things, and I don't think that's a good idea, or to find a way to make the code retrocompatible, but that is way more complicated.

But if you are up to the challenge, you are free to take a look at the sourcecode.

Or just rename your OA 085 pk3.

It's not simply to remove Team Arena weapons. Maps change with each release, for example (you may see the player passing through a wall because in the recorded version there was a passage there).
I suppose the only solution would be to store somewhere the list of the pk3s that were "in use" at the moment of recording.

Of course, that would allow to play 0.8.1 demos on 0.8.5, but not 0.8.5 demos on 0.8.1.
Indeed... what in case some of pk3s in use at the moment of recording are not available when playing the demo (e.g. demo copied from an user to another)? Unlike when connected to a server, the client will not have any chance to autodownload them.
It would be something like the "pure server" checks (you must have the same versions of all the pk3s the server is effectively using at that moment -you can notice maps pk3s are usually downloaded one-by-one, when needed-), but without the ability to autodownload extra files.

@Gig: indeed Sago's idea to save all files that were used along with their checksum (or better, the MD5 hash) would be the best, but anyway having different files is a minor bug since players can easily change their files to replay correctly the demo. As long as the demo plays. And that's the problem here, that this is a so big gamecode change that it breaks compatibility not only with demos but also with mods.

But I don't think these additions should be removed. But if they could be fixed to be retrocompatible, this would be perfect.

/EDIT: As pointed out by NeonKnight, these additions were also included in OA 081, so this is not the root of the incompatibility. But something changed in the weapons and items management and that is the root, but I don't know exactly where and why.

Well, if engine changes would not be enough to implement the feature, I suppose this could simply be applied to new gamecode like many other additions. I mean that new feature would work with OA 0.9.0/OA3 and later (example), while demos up to 0.8.8 would continue to work in the classic way. Also all mods based upon previous game logic (all q3 mods, plus mods based upon 0.8.x gamecode) would continue to work as they ever did (not storing/requiring hashes).

AFAIK all changes regarding game logic (gamecode) -unlike engine changes- do NOT affect old mods. All new game logic features/fixes introduced with an OpenArena version do not work in a mod which is based upon a previous version (the gamecode in use completely overrides other gamecodes, they do not get mixed. I don't know if there are some cases -e.g very small modifications?- where this may happen.). E.g. all quake 3 mods will continue forever to immediately end matches with timelimit set to -1, while 088 baseoa does not anymore; aftershock, e+ etc. will continue to have the problem until their developers will integrate 088 changes into them (or maybe they may have already fixed that problem by their own, I don't know!).  

all im saying is we all want this fixed


dont say its not broken

cause it obviously doesnt work..

Sometimes you should cut ropes and forget about old things.
There are many pitfalls regarding a fix: maps changed (remember the "weapons fire through the platform in ctf4ish).
If you still like to see old demos for old maps, just use old versions ;)

i dont see why no one would not fix this..


i doesnt make any sense to use a older version because older versions will not be avalible to new comers


im doing this for the new people to oa

they will not know why demos dont play

Can't you understand? The demos got broken due to having the TA stuff added into main OA.

Fixing your demos = restoring them to missionpack-only. Personally, that's the bad idea.

I'm here for a while now... and I never wanted to play a demo in OA. If the demo was created by an older version, it's enought to have it uploaded to YouTube, IMO.

Of course, if a such improvement would not be excessively hard, it would be very good. But I don't know how hard it would be (maybe parts of the "pure server" checks source code may be reused for that).

Anyway, that would work only with patches, not with major versions that "reboot" all pk3s. OA0.9.0/OA3 will not be able to play 0.8.x demos, because their pk3s will be totally different. If the feature will be implemented, OA 0.9.4 may be able to play 0.9.0 demos.

A question: what do you say guys, is this a thing that may be proposed to ioquake3 guys or not? I fear this would require game logic changes (that they probably don't do at all) or to make the engine look into data files (that probably is not good, generally speking)... and anyway I suppose this problem affects ioquake3 much less than OpenArena, beause they are not used to change game stuff (but mods may be positively affected by an engine upgrade with this feature, if technically possible -again, I fear it's difficult to do everything engine side, but IDK-) .

Ps: Graion, I think that storing the list of used pk3 files (not simply those installed!) while recording, and then loading only the same pk3s while playing the demo -like when connecting to an old-version pure server- may do the magic (game logic would revert to old one! And old maps versions would be loaded). But I don't know if that would hard or easy to implement. And unofficial pk3s in use when recording may prevent the demo from running on another machine anyway.
But, unless this may be done fully engine-side (that I fear unlikely, but I don't know), this may affect only future versions of OA. OA 0.8.x would always continue to work with classic demos.

PPS: By the way, me too very rarely play demos. But I'm not an hardcore gamer, I'm not in a game clan since many years (I was in TEQ q3 clan... many years ago!)... maybe someone may use demos much more than what I do (this change would not be very useful for me, but maybe for someone else).
Anyway, the ability to export to avi files already allows to have "long lasting copies" of your favorite demos... so probably this compatibility enhancement would get very low priority is Sago/Fromhell's plans.

This is false, that's what I also believed, but as pointed by NeonKnight (and which I tested myself), OA 081 already includes TA gametypes and weapons, but doesn't break compatibility, only OA 085 breaks compatibility, and I don't know why.

Also, the compatibility break also affects server-side mods, which are no longer compatible with OA 085 (all mods are still compatible when used client-side - ie: with autodownload - but no server-side).

Now that I'm getting more used to the game code, I may take a look at this issue. I'm pretty sure this is a small change that breaks the compatibility.

@Gig: the ioquake3 project is pretty dead, and anyway the guys are really reluctant to add new functionnalities, so I think we are on our own if we want to enhance the game code.

I don't know enough about server-side mods, so I can't help you about them. I don't know how they can use different pk3s without requiring the client to download them. I don't know how can they change game aspects without loading a different QVM in the clients.

But I want to tell you that working around specific game logic incompatibilities between 081 and 085 probably will not be enough: different map versions are also a major problem... I feel loading and unloading patch pk3s to fit those used when recording the demo would be the only possible solution (and that would not need further tweaking at every new release). But again, I have no idea about serverside mods... maybe they should be left out from the new demo system -using standard demos instead-, like all old standard mods that will keep their own gamecode?

@Gig: Loading a map is not a great matter, because players can always find a way to fetch the required map over the net. But if the gamecode is incompatible, they have absolutely no easy way to fix that.

About server-side mods, they simply can't modify client-side aspects, they can just add server-side functionnalities, but that's enough to add a lot of features (eg: with E+, you can have full delag for all weapons + anti-cheat + anti-camp + advanced config scripting + locking and managing teams in matchs + referees system + etc...).

Swaggerall, speaking as a programmer, we all have limited time.

Fixing the demos would be nice, but there are a LOT of issues involved in making it work.  So, the developers have a choice to make, they can spend precious time and energy on attempting to fix the demos, which is somewhere between very very hard and impossible, or they can spend that same precious time attempting to fix bugs and add features that are much easier to implement, and probably more important.

You mention everyone wanting the demos fixed, but the reality is I never use the demos.  For me, it would be a huge investment of time to fix something of little to no personal value.  By contrast, fixing bugs and balance issues in maps, adding new characters, and improving performance are all issues that DO affect everyone, quite literally.

In the end, it's about setting priorities.  Working on something that has a known work-around, does not benefit everyone, and may be a waste of time is probably going to get a much lower priority than the dozens of other issues that are on the table.  I don't contribute to this project right now, and I freely admit that.  But if I REALLY wanted a feature added, I would take a few polite "no"s as my incentive to do it myself, or accept that my priorities are not their priorities.

Sago, if you read this thread, could you please point me to the exact version of the gamecode used for OA 0.8.1 please? For OA 0.8.5, I guess the version on the SVN branch for 085 is the right one, isn't it?

Isn't the 0.8.1 gamecode in the OA SVN under the source/081 folder?

I'm not sure about it, versions can differ a lot and it's very important that I have the exact versions of OA 081 and 085 gamecodes if I want to try to fix this compatibility break, so I would like Sago's confirmation about it.

I believe the version in SVN is the correct one. But I originally uploaded it here: http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-modSDK-0.8.1.tar.bz2

I should notice that smcv already pointed the change out in another thread. It was a piece of out-commented code in 0.8.1 that was in-commented in 0.8.5. This changed an enumerator. Normally new items are added to the end of an enumerator but because the code was commented in it was already in the wrong place. The code was supposed to have been activated in 0.8.1.

There are other changes that sometimes causes "Invalid command" to be displayed while playing a demo.

There is actually quite a few commits to ioquake3 but not anything that would draw a headline. My favourite enhancement have been the qvm based serverside mod on pure server thing.

The ioquake3 team has a rather large list of NOTTODO, that's all. If you want to add something fancy, just create your own fork. Their main interest has always been eliminating bugs and cleaning code. They will not touch the gamecode, unless you find a serious flaw, but they might add new stuff into the engine (and thus being mod-agnostic).

What's new about server-side (QVM) mods? They've been around ever since id Quake 3.

I have never been able to get them to work. But of course just because Google does not know about it does not mean it is not possible.

About server-side mods, I guess that what they did is allow server-side mods with a sv_pure 1 server, because before, if I remember well, it was not possible, you had to set sv_pure 0.

Indeed now it works, simply unzip the vm into the vm/ folder, and launch a server (with OA <= 081), and it will work. Also, most serverside mods require to set vm_game 2, but a few ones, like ExcessivePlus, supports 0.

About ioquake3: yes but there are a lot of things that they could do, such as fix the /rcon tell which _should_ work logically.

Well, different versions of the same map may be difficult to identify... :)

i dont see why i just cant be editted and fixed for newer versions....

renaming it is so stupid...


weather you play demos regularly or not just because YOU dont doesnt mean other do.


i also think demos should have a rewind pause fastword button :\


espically since the meer touch while playing a demo sends you back to the main menus

@Gig: I agree, but this is a different feature to implement than compatibility break, which is what we are discussing here. The problem with compatibility break is that with time it will get worse, and either the dev team will have to maintain an old release just for compatibility sake, or drop it and risk to lose all the compatibility (which is probably what will happen, try to download OpenArena v0.6.0 to see what I mean).

So I don't think that saying that old release are to be used for this kind of case, because one day they will be dropped. If the compatibility break is fixable, I think it rather should be.

And about your feature, there is already i mapChecksum integrated, but maybe this is not stored in demos. But a simple check based on checking could easily be implemented I think (if that's not already done).

@sago: then will it be fixed for the next version? Could you please point me to the code in question?


Please do not mix up your requests AIM, this is a different matter.

Anyway, even if these features are not show on the GUI, they already exist.

To avoid quitting by just hitting any key or button, use:


To pause the demo:
or

To slow down or fast forward the demo:
With 1 = normal speed.

And if you want advanced features like rewinding, just use q3mme or oamme (available on this forum).

never knew..

I tried cl_freezedemo in the past, but it strangely freezes the current frame, but the demo continues playing in background. I will try cl_paused when I have some time.

Anyway, I don't understand why you separe the game logic compatibility from the maps compatibility. In general (maybe with the exception of serverside mods?), both of them depend from loaded pk3s. If you have 085 pk3s loaded, you use 085 game logic and 085 maps. If not, you use 081 game logic and maps. Demos capable to save and load the right pk3s list should work with different patches, in theory.

Anyway, I've told various times that the compatibility checks may not do miracles, and may make compatible different OA patches, but not different major versions (oa 0.9.x will not be able to correctly play 0.8.x demos, cause of completely rebooted pk3s). Maybe, for this reason, spending too much time about the feature would not be worth?

@Gig: I make a difference because, as you point it, the technique or loading a previous pk3 only works because 085 is a pk3 patch, but when there will be a new major version, there will probably be a single vm so you can't load a previous one (unless of course you download a previous version of OpenArena...).

And there's nothing that says that the next major version of OA can't be compatible with previous demos and serverside mods. OA 081 was compatible with every demos, be it for OA <= 081 or Quake 3 demos (as far as I know, I can remember I tested, you just had to change the extension).

So that's why I say: if the compatibility break is due to a simple unnecessary change in the code, then fix it ; if it's due to a major change in the game, then nevermind.

Sago confirmed that this is due to a very simple unnecessary change, so what's the fuss? Do you really want to break compatibility now (while this was a major goal of OA until now) for such an unnecessary thing? To me this is quite logical to revert the unnecessary change.

In bg_public.h:
STAT_PERSISTANT_POWERUP should be after STAT_MAX_HEALTH. Of course changing it now will break compatibility one more time and that is why I haven't done it.

Thank you very much Sago for the code.


I understood that this is why you haven't done it yet, but breaking compatibility with OA 085 is worth, since it will fix the compatibility with all previous OA versions and ioquake3 and server-side mods. And after all, this should simply be called a bugfix, because that's what it is.

IANAC, so sorry if my question is dumb, but... is it possible to keep compatibility with all the OA versions by using an "if" statement which detects 0.8.5, and if OA version is 0.8.5 uses the current code, while if not it uses the fixed code?

The compatibility break will mainly happen between the server and client, so if the server gets fixed, the clients with the old code won't be able to play, unless they download the new version.

Anyway Sago, since noone these day use OA 085 as server-side, because when they update, they need the clients to download the OA 085 pk3, I think it won't matter much to fix this bug and break the compatibility with OA 085? I mean, anyway, either players won't upgrade, or they will be required to download the pk3 by the server, so practically there shouldn't really be a compatibility break.

And about OA 085 demos, players will still have the possibility to temporarily rename OA 088 pk3, at least they won't have to do this trick anymore for OA <= 085 versions nor ioquake3 demos.

Sorry, I still don't understand something... how is it possible that 081 played pre-081 demos or even q3 demos? Where would it find the right gamelogic? Where would it find the required maps, models, textures, shaders, effects?

@Gig: the necessary gamelogic to replay the demo stayed the same, because ioquake3 (and even Quake3) is a subset of OA 081: OA 081 includes everything from ioquake3 but adds more features, without modifying what is already existent.

About shaders and graphics stuff, indeed OA 081 cannot find them (and most Quake3 shaders and textures aren't implemented yet), but you could download the map elsewhere (there are Q3 map packs) and use Rainbow's textures pack, and it works quite well if I remember well.

The code is now broken starting from OA 085 because the weapons are not anymore in the same order, so that old clients get a new info that they do not expect at this place (before it was appended, so no problem, now it's mixed in between -> bug).

And as numerously told, the entries were placed there by iD. They were just commented out in the whole time.

They maybe were commented off for a good reason. And iD isn't god, they may be wrong sometimes. Did you try to place those additions at the end instead of in the middle?

Demos include information about which map was played (though not which version, as there are no checksums). Everything else is just a dump of network packets. The game will then load whatever assets are required by the local map and use whatever local gamelogic is present and whatever assets it loads. As long as this is compatible to what has been used during recording, everything will be fine.
If the gamelogic interprets stat[2] as STAT_PERSISTANT_POWERUP during playback while it was STAT_WEAPONS during recording, then things break. The demo itself has nothing to do with this.
That is, if you change any of the code logic behind these "magic" offsets, then old demos will be interpreted incorrectly.

If there is any chance to detect a .85 demo, a little program could change the order.
But maybe thats overkill.

will it be fixed or not..?

Shouldn't it be the other way around? vm_game defaults to 2, meaning QVM compile mode. 0 is to run shared libs (.so, .dll, .dylib). The latter one is bad for portability. 1 means QVM interpret mode.

"tell" is not part of ioquake3. As said numerous times, they won't add anything but bugfixes to the gamecode, but will accept changes to the engine. Using the engine for "/rcon tell" is not portable, because each game might be using different commmands for this in cgame gamecode.

This looks like as read-only...

And here http://joz3d.net/html/q3console.html they say "variable holds the status of the paused flag on the client side".

PS: Strange... that com_cameramode 1, does not only prevent from exiting the demo by simply pressing any key... but enabling it also hides your player model drawing if \cg_thirdperson is set to 1. I don't see the logic behind this... id software mysteries?

@Gig

Ah sorry Gig, didn't check it, maybe cl_paused is only accessible with /devmap (cheats enabled).


@Grey Matter

Yes exactly, that's why 1 is the worst in terms of running time (since it's interpreted), 0 is bad for crossplatform compatibility but if you can afford to compile the "libraries" for every platform, you then get the best running time you can with a vm. 2 is a good compromise: faster than 1 (interpreted), but worst than 0, but its crossplatform.

That's why only few mods are nowadays runnable with vmgame 0 (such as ExcessivePlus), but anyway they are all runnable with vmgame 2 or 1.


/tell _is_ part of ioquake3, it always worked, but the problem is that /rcon tell does not work, while /rcon say and similar client-side commands work. I do not think that was on purpose, rather a forgotten implementation by Id Software that persisted over time. I think it's clear that it's a bug (of partial implementation).

And I think this is rather unfortunate, because this simple litte bit of code allows to use a lot of third-party applications that add a lot of functionnality.

And about ioquake3 project, they are not only implementing bugfixes but also new functionnalities such as VoIP. But I can't understand why aren't they backporting codes from mods of their engine that could be considered as core functionnalities, such as advanced scripting capabilities, which does NOT break the compatiblity with the Quake3 assets and old engine.

Anyway this is another debate, but I really do think that ioquake3 release cycle is flawed. Ok for stable releases, but they could also create a testing branch implementing new functionnalities that do not break compatibility.

I doubt that there is much of a performance bottleneck within the Q3 VM. The only reason I've ever seen native shared libs is to use functions not available for QVMs (such as direct iptables support without additional engine trap_* calls).
If you really were after the "best running time for every platform", you'd also have to compile the gamecode with -march=native, which also means you'd have to compile for each processor architecture as well (and, again in theory, test for each platform and architecture).

This would not be a problem at all, if all mods were properly open source'd (the OA Debian port for example uses native libs due to licensing issues with q3lcc).
I'll be a bit pendandic here (regarding "they are all runnable"); mods in QVM format can always be run in both compile or interpret mode (vm_game 2 and 1 respectively). Furthermore they need to be compatible with either id Quake 3 1.32c or use ioquake3's improved QVM format (and can then no longer be used with id Tech 3. This applies to OA for example.). Mods in native library format (e.g. qagamex86_64.so) can only be run on a specific platform and architecture (let alone problems like being linked to outdated glibc versions).

Sorry for not being more explicit here, I meant to say "rcon tell is not part of ioquake3" (I thought this was obvious from the context).
Game commands do not automatically become "rcon-ready". They either need to be added to g_svcmds (and can then be used from server console and rcon) or hacked into the engine (which is a bad approach). I do think this was on purpose, since iirc "say" is the only command you can use within rcon. Anything else like "say_team", "tell", "callvote" can not be used with rcon.
I'll say it again; the ioquake3 team won't add this. They will not touch the gamecode, but adding "rcon tell" to the engine is just not cross-compatible for all mods (and is thus not in the interest of the ioquake3 team either).

This is not a real problem. If you have the source code, just add the required commands to the gamecode. If you don't, just create your own hacked engine, which is compatible with whatever mod you're using.


If you've loosely followed their changes, you'd notice that they hardly ever added any changes which require more than one new file (not counting entire external libs like curl or speex). If I had to guess I'd say they are afraid of the number of potential bugs that large new changes could bring (assuming that small changes are less likely to contain bugs :) ).
I don't quite see why scripting capabilities (like variable substitution) are a core functionality. People have been playing Q3 without it ever since. IPv6 on the other hand *will be a required core functionality soon.

The ioquake3 team is rather small. Combine that with the fear of new bugs and the lack of time for testing "experimental features" and you know why they don't do this themself. You're always free to create your own fork. I agree that this is bad, since everyone starts to maintain his own fork with some own new features and some borrowed from other forks, without any kind of "central additional feature repository". Thus you'll have to keep an eye on all these forks and safe interesting .diffs and .patches for later ;)

By the way, ioquake3 does not really have any release cycle. The latest official stable release is v1.36 and from the stone age. Even the "untested Angst Build which is compiled from the freshest of SVN sources" is quite old.