Pages: [1]
  Print  
Author Topic: Clarification about how OA versions evolve around the engine  (Read 10363 times)
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« on: September 14, 2008, 08:43:54 AM »

Hi, I've been around on the forum for a little while to get a bit familiar with OA's development, but there are still a few issues I don't understand well.
Mainly, it has to do between compatibility between versions, and the part OA takes in modifying the engine.

So here are a few questions, if you don't mind to enlighten me a bit Cheesy :

1) Imagine I get latest ioquake3 version from their SVN, what are the modifications which are done to it so that we obtain on openarena build ?
- One element: changing baseq3 for baseoa directory
- Second element: protocol version number
- Is there anything else ?

2) This is for the engine, but from what I understood on Q3's way to work, it uses QVM. So QVM are a great thing as they allow to modify the game's logic in an cross-platform way, without really interfering with the engine. Is the missionpack a simple rework on these QVM (bringing Q3 Team Arena's code + some custom work) ?

3) So now we've got our OA engine, with some  missionpack, and with assets. In common with Q3, we've got the engine with slight modification (see 1)), some common assets such as ones used for weapons and Sarge model. And so some mod like Defrag, simply by coming with a common QVM, can make OA and Q3 compatible, right ?

4) Is there some other mods, like Defrag, which could have been both used with OA and Q3 ? (I enable the mod inside OA, and I /connect to some specific "q3" server, right ?)

5) Now imagine I get some _old _ ioquake 3 release, with no SDL, without VoIP support. If I build the engine from it, and use latest OA QVMs and assets, would it work ? Why if not ?

6) Between 0.7.1 engine, and 0.7.6 engine which has the funky mouse input, were there some changes which were quite awaited (or even necessary) and welcome in OA ? Were there even more in 0.8.0 (except the mouse fix) ?

7) OA 0.7.1 uses protocol 68, OA 0.7.6-7 uses protocol 69, OA 0.8.0 uses protocol 70, from what I understood it helps in not melting versions (which all have different engine/qvm/assets) it also broke compatibility with most Q3 clients which were using protocol 68. Would there be a way to alter protocol version at launch time, such as with a command-line argument ? Would it help to have such a feature ?

Cool And lastly, why OA hasn't been designed as a simple mod over ioquake3 if it's goal is mainly to add assets ? If making a standalone game brings flexibility, it seems to be some flexibility which is sporadically used (no physics modification intended, and so on ... ). So, was there some necessary need to make it a standalone game ?

I've finished, I repeat myself a bit in these questions, and hope I didn't say too much bullshit Wink

Thanks
Logged

Todo: Walk the cat.
kit89
Member


Cakes 6
Posts: 636


Shoot him..


« Reply #1 on: September 14, 2008, 09:39:12 AM »


2) The mission pack is really just a MOD. In some aspects it's simple but in others it's more complex.

3) I'm not entirely sure what you mean. Defrag should come with it's own qvm files, they would call specific functions to the engine. If the OA engine supports all called functions and returns data that the Mod expects, then it will run.

5) So long as the new files don't require specific features that are not supported in the older engine then it should work. For example if the OA qvms had functions that required the use of latest ioquake3 as it had voip, running those qvms may crash on an older ioquake3 as it doesn't support voip.

6) I believe it was mainly the implementation of mission pack, a few bug fixes & the implementation of some game types.

Quote
And lastly, why OA hasn't been designed as a simple mod over ioquake3 if it's goal is mainly to add assets ? If making a standalone game brings flexibility, it seems to be some flexibility which is sporadically used (no physics modification intended, and so on ... ). So, was there some necessary need to make it a standalone game ?

You are right in saying that OA can be used like a MOD, infact the original Q3 game could also be viewed as a MOD.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #2 on: September 14, 2008, 10:17:21 AM »

1)
Changing base-directory, protocol number, cd-key, trademarks (names+icons), default servers, some effects (bloom) and features wav2ogg, g_humanplayers and g_password)

2)
Yes. But missionpack can access some features baseoa can't.

3)
Q3A and OA has two incompatible things: cd-key and protocol. In 0.7.1- there was some OA defrag servers that accepted connections from Q3A clients.

4)
See 3. And even on 0.7.1- you couldn't connect to most Q3A servers because of cd-key protection.

5)
Most of the functions will just be disabled if you use an old ioquake3 binary. However s_marine cannot work for some unknown reason and it must be an ioquake3 with support for the fixed-qvm format as the OA stuff is compiled with that.

6)
0.7.6 introduced resolution detection and was easier to compile on different platforms
0.7.7 introduced protocol change and a single bugfix
0.8.0 introduced VoIP, IPv6 and g_humanplayers/g_password

7)
The protocol number is saved in a read-only CVAR, so you might be able to change it at startup.

8 )
You are suggesting that people should download OA and then start to wonder how to use it. A small percentage might then download ioquake3 and of those a small percentage might figure how to choose the OA master server and get it to launch without a copy of Quake 3. And thoose that gets that far cannot join anything because the server admins have forgotten to disable cd-key check on the servers.
At the time of the pre-0.8.0 launch the above was even harder as no startup parameter could change it.

 
Logged

There are nothing offending in my posts.
damocles
Bigger member


Cakes 0
Posts: 158


May cause drowsiness


« Reply #3 on: September 14, 2008, 10:40:12 AM »

3) So now we've got our OA engine, with some  missionpack, and with assets. In common with Q3, we've got the engine with slight modification (see 1)), some common assets such as ones used for weapons and Sarge model. And so some mod like Defrag, simply by coming with a common QVM, can make OA and Q3 compatible, right ?

4) Is there some other mods, like Defrag, which could have been both used with OA and Q3 ? (I enable the mod inside OA, and I /connect to some specific "q3" server, right ?)

(presumably OA and Q3 users playing each other on the same server)

sago007, are the protocols any different aside from just the protocol number?  (I vaguely remember getting old/new 6x/70 demos to work with other people's 1.32 builds, though I don't recall which direction.

(For those of you following, demo format kinda-sorta ~= network protocol (Q1/Q2 demo specs also meant easy picking for network exploits, partially leading to the use of [basic] encryption in Q3).  I could be wrong.)


(Also, I once "accidentally" connected to a DarkPlaces game using the engine and Open Quartz, and while the entire map was black and autodownload was kicking in for things it shouldn't download, nobody seemed to notice anything. Smiley)

5) Now imagine I get some _old _ ioquake 3 release, with no SDL, without VoIP support. If I build the engine from it, and use latest OA QVMs and assets, would it work ? Why if not ?

I can confirm the 0.6.0 and old alpha binaries working with 0.7.x / 0.8.0 (aside from things like nailgun wall hit, missing flat shell casings, etc., and what sago mentioned of the invisible s_marine as in the 0.7.0 binaries at Rainbow Networks).  (Old alpha complained of mismatched pak0.pk3, had a CD key dialog, and looked in baseq3/, but nothing much.)

(also presumably the same for the non-OA side of jackthompson's 1.32 source, aside from CD key check)

8 ) And lastly, why OA hasn't been designed as a simple mod over ioquake3 if it's goal is mainly to add assets ? If making a standalone game brings flexibility, it seems to be some flexibility which is sporadically used (no physics modification intended, and so on ... ). So, was there some necessary need to make it a standalone game ?

Slightly off-topic, but there was also a time when OA wasn't yet using ioquake3.
« Last Edit: September 14, 2008, 10:45:40 AM by damocles » Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #4 on: September 14, 2008, 11:09:55 AM »

sago007, are the protocols any different aside from just the protocol number?  (I vaguely remember getting old/new 6x/70 demos to work with other people's 1.32 builds, though I don't recall which direction.
No. It is possible that the protocol number is coded into the files and in that case they are only forward compatible. It is also possible it is only saved in the filename. I think the latter is the case but I have never tested it.
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 #5 on: September 14, 2008, 02:02:19 PM »

Hehe, thanks, that answers my concerns Wink

1) It may not be that easy, but shouldn't some of these changes be reported upstream ? I'm not sure, but rest (master server, protocol version...) may not need to be hard-coded. Of course these are minor issues.

3-4) I wasn't really expecting OA to connect to Q3 servers, but, why not the contrary, yes. I mean, this is normal not to put efforts to stay compatible with things which are closed-by-design, but it's good if OA doesn't dig holes between things which are compatible by their roots, and which are not required by its own development.

8 ) I'm rather suggesting it may help if we had some binaries with which setting these things up (master server...)  would be easy, without necessarily rebuilding the whole stuff. I see ioq3's mini-fork as an unwanted side-effect, and so, why not, OA as a "mod" (which, of course, should be easy to set-up and be ready to be played).

Just to be clear, i'm not accusing OA of doing things badly, I'm not competent enough to judge Cheesy but I was mostly worried with compatibility issues and wanted to get a better understanding of what separates OA versions and Q3 and ioq3 builds ...
Logged

Todo: Walk the cat.
epicgoo
Member


Cakes 5
Posts: 203


« Reply #6 on: September 14, 2008, 02:55:11 PM »

oa is a complete game and ioq3 is just an engine
it should come with a binary...
Logged
andrewj
Member


Cakes 24
Posts: 584



« Reply #7 on: September 14, 2008, 09:40:47 PM »

I wasn't really expecting OA to connect to Q3 servers, but, why not the contrary, yes.
OA is too different for a Q3A client to connect to OA servers and just work.
Model names are different (no klesk etc), textures are different, etc etc.
I see only a lot of work and no benefit in trying to support that.
Logged
fufinha
stop making alt accounts and self-termination
Member


Cakes 7
Posts: 584


retired


« Reply #8 on: October 04, 2008, 01:46:26 PM »

Quote
3)
Q3A and OA has two incompatible things: cd-key and protocol. In 0.7.1- there was some OA defrag servers that accepted connections from Q3A clients.

4)
See 3. And even on 0.7.1- you couldn't connect to most Q3A servers because of cd-key protection.

If server admins use sv_strictauth 0 then would this still be an issue? The only difference for me is the extra prompt for the key but just click ok and your in the main menu
Logged
Pages: [1]
  Print  
 
Jump to: