.Map :: MoHAA Mapping

Some thoughts I had about some techincal issues.

I assume you know how the TIKI files interact with SKDs/SKCs.

I was thinking of how to implement the support and the only reasonable solution I could invent is load-time compilation of all the SKDs and SKCs a model consists of into a data struct which is seen by the game as an MDR model (ioquake has support for MDRs).

As for the scripting interpreter, I think map script files could be compiled into an array of statements, consisting of an integer (enum value) and a linked list of parametres. The g_local.h file in the repository should give you an outline. A thread would be started with its position pointer set at the first line.
An event system will have to be emulated in order to mimic the MoHAA scripting functionality, but it should be easily written and even made compatible with the "server" section of the TIKI files.
I'm not sure how to cope with variables and arithmetics yet, though. Any suggestions? I've never written a script interpreter before.

The one thing I have discussed with Wambot is the issue with chams. When considering in creating model I think we should first look into our options.

Unlike quake3, MOHAA loads models as skd's\skc's (as you mentioned) and q3 loads md3's. Now here is the scenario.

You take any pair of pk3 chams loads fine in MOHAA, you do the same in quake3 (even if you modify them to work with the q3 specific model) nothing changes ingame. Why is that? The answer I found is quite simple.

MOHAA made the mistake (among many others) of having textures loaded clientside. Which is fine because so does quake3, however MOHAA models are rendered seperatly from the textures versus q3 where its is textured within the model. Hopefully you're following me so far.

So making chams (pk3) for quake 3 wouldn't nearly be as easy for a few reasons.
1. Quake 3 actually has SV_PURE working (as far as I know)
2. In order to make pk3 chams, the client would have to figure out how to extract the md3 file, modify the texture directly and then recompile. (I don't think people will go into the trouble doing that).

The point is, via simple tik editting you can attach any shader file to any model and have it render anything you want. Even with sv_pure working, I think MOHAA needs a more construct & stable way to load models as well as rendering the model. Something to think about. I'm not sure how other games attempt to block chams, but thats something that might be worth looking into.

What if we redid the file system? It may be more than we want to do. THe files inside the pk3's wouldn't be any different, but instead of it being a pk3 (which can easily be modified) we make like a custom packing method.. say something like .pak0, .pak1, .pak2 etc etc.

Heh, dude, sv_pure is much more than that. Not only does it check the pak names, it also makes sure pak file checksums match, which means that if the paks are not identical (including their contents), the client is not allowed on the server. Mind you it's the client that first sends the list of PK3s it has to the server, and then the server tells the client which ones to ignore and which ones it should download. While it's still relatively easy to hack the source to always send legitimate checksums and not the real ones of the paks you have, it will already stop most chams.

yeah, Im aware of the checksums, but I also know it's quite simple spoofing them. Thats why I like to play it safe.

The other alternative would be to just nop nodepthtest so that the function can't be used in shaders. Which brings up a 2nd thought, maybe we can limit what can and can't be used on shaders? Theres always that backup plan you know just incase the first check fails. Theres always opengl and other clienthooking methods but that can be stopped as well clientside by simply making sure that the only opengl32.dll file that is loaded is from the windows\system32 directory.

Also not sure how well you're familiar with Spearhead, but they seem to have some kind of depthtesting verification so it limits the distance at which chams are rendered through walls.

Actually, it's quite simpe to spoof any countermeasures. Especially when the source code is public, which is the case in OpenMoHAA. There is no effective way of combatting cheats. What could work, though, is a trusted community system; however, it's not possible to incorporate one into OMoHAA, as it would require user accounts and stuff - generally, infrastructure which stands no chance to function in this game. Forcing players to register with a 3rd party system has proved to be ineffective (vide DMW).

As for shaders - anything can be done and we will be considering all kinds of modifications in due time.

Haven't really noticed that behaviour in SH. Not that I played it a lot, it felt awkward to me.

Rookie One.pl wrote:I was thinking of how to implement the support and the only reasonable solution I could invent is load-time compilation of all the SKDs and SKCs a model consists of into a data struct which is seen by the game as an MDR model (ioquake has support for MDRs).

from what i know about it (and i'm really scratching the surface there), this is reasonable also to me. i don't know much about it, but second option would be adding skd and skc support directly. would this bring any advantages?

Direct support is not possible, as SKDs and SKCs are just the ingredients that make a TIKI.

Thinking about it again I reached the conclusion that MDR is not the perfect representation format for us. The thing is that MDR is monolithic while TIKI is modular. A bone pos+rot information in an MDR animation frame is absolute (in the model's space), while in SKCs it's relative to the parent bone. The latter has the advantage that you can alter the animations in real time quite effortlessly (no need to recalculate all children bones' positions, as opposed to the monolithical approach where you can move them around and then they're just added up just before the actual rendering), and considering MoHAA's design this is a necessity (player models are extensively manipulated by cgame when leaning and/or looking up/down).