OpenArena Message Boards

I don't know where else to put this, but there are things I wish for in general

Client:
- Build switch to allow Win95 compatibility again (no PSAPI, restored old network code and no document home path)
- Restore console startup window on Win32
- Fix SDL input sluggishness (see: Darkplaces-sdl for how to do SDL right)
- Allow sound playback to be interrupted (such as pre-1.27g)
- Switchable announcer voice via client so it'll work in other mods (also important for future localization support)
- MME fx particle system (moving cg_leiEnhancement to r_leiEnhancement for improved versatility and performance)

Renderer:
- Loading of DDS images (supporting the special dmmq3 maps) (DONE-ish.  Some textures do still fail to load but for the most part it's working. Hardware support only.) Not yet done in the Git tree.
- GLSL-based color control so overbrights work in a window, so we can finally kill all those "the game is too dark" excuses. I believe the opengl2 renderer does this already. (Done with a polygon blend, as well as by shader as an option)
- Default textures for map textures (defaultMapTexture) and models (defaultModelTexture) and everything else like 2d elements (defaultTexture). That white black square is a grating placeholder. done
- An option for simpler flare testing (for performance) (DONE - r_flareQuality 0 makes oa_pvomit perform in the three digits without losing flares)
- Gamma control in a window (DONE - fragment shaders required)
- Performance enhancements for MDR models, like using hardware transform & lighting (Geforce256/Radeon7x00), vertex shaders (GF3/R200), or something
- Dynamic lighting in vertex light mode


Renderer - new features for content:
- Parse the string in q3map_flare to actually load and use the said defined shader, pass that to tr_flares.c and use it (Done)
- proper world space tcGen environment (like Elite Force and Q3Revolution) (Done, thanks to the JO source release - implemented as 'tcGen environmentWater')
- tcMod Atlas
- tcMod atlasalpha, which will pick a frame based on the texture alpha instead of it being a looping sequence. This is to get around certain video cards' lack of alpha modulation (Rage Pro, S3 ViRGE)
- skipbias shader parameter, which just skips drawing the polys completely when at a distance from viewer, could be very useful for vegetation details

Renderer - legacy fallbacks:
- Software rendering via a touched up TinyGL that supports at the least vertex coloring and alpha test
- Reimplement 'alphahack' for PowerVR PCX2, Matrox MGA and S3 ViRGE - generate alpha channels for all additive and subtractive shader textures; remove alpha channels from textures of non-transparent map surfaces (like tinfx stuff)

UI (not q3_ui):
- 16:9/16:10 scale and alignment support (instead of stretching 640x480 to 1920x1080 it'd be centered, stretched with correct aspect, and allowing coords beyond the strict 640x480 space so the UI can 'fit' in HD, and this would also make the UI model drawing elements maintain perspective consistency better) (Done)
- Somehow allow the 'team heads' to be selectable (as in the heads defined for missionpack, and not a mix-match for every head ever) Not supported

- An optimistic culling algorithm instead of (or as an alternative to) the conservative culling algorithm. The vis-thing is putting limitations on map design.
- I find the FreeType in UI interresting although I doubt that it will look very good and translations has been added to NOTTODO (wasn't translations a goal for 3.0 at some point?)

I don't know much about this. It this https://bugzilla.icculus.org/show_bug.cgi?id=5442 relevant?

I think this is controlled by the game code. There are multiple scaling functions. I think there are missing some drawing routines that can draw at relative locations (like from the left, center at).

Yep, though the decoding part should never be included - instead the Darkplaces software decoding should be used since it's patent free and does it differently
ideally since DDS textures are typically huge, the software decoding would probably be done in half resolution for mip consistency

Heck, no! Those should never see the daylight again, let alone connect to the internet (via IPv6 ;) ). KernelEx (http://kernelex.sourceforge.net/about/) should be the maximum handstand.

I have no problems with SDL. On the contrary, my mouse is seriously broken in id Quake 3 1.32c (this being on a Linux system). Instead of spreading FUD, you should file proper bug reports.

I don't know what's special about the missionpack heads, but this is most likely gamecode, not engine. Are we just talking about a GUI for the headmodel and team_headmodel cvars here?

This is indeed mostly gamecode (also see the multiple same questions in ioquake3 forum and bugtracker, rftm). While you're at it, don't forget to fix the crosshair being stretched.

You weren't around at the time of each and every single of the SDL complaints circa 0.76/0.7.7 (http://openarena.ws/board/index.php?topic=1722.0).

I have heard of this complaint too in other games like UrT.  I think the complaints are usually for Windows so you may not have experienced it if you use Linux.  I don't think I ever had a problem in Linux with ioquake3/SDL other than at one point the resolution selection was messed up.  That has long since been fixed for me.

I think it may be a problem on older SDL releases.  I have tried the openarena_engine in github on Windows and it feels fine to me.  It feels fine in Linux too.  It feels even better if you enable the QuakeLive sensitivity settings :D

Edit: Also, they are in the middle of upgrading to SDL 1.2.15.  zakk added mac support and changed all of the includes.  Hopefully they update all the other platforms. -_-

Seeing that crosshair has been mentioned..

When I asked for it, someone said it's engine, someone said it's gamecode... I don't know, anyway it would be nice to have the crosshair shown when using r_anaglyphMode (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Stereoscopic_view]stereoscopic view (http://([b)).

By the way... wiki pages that may be related with this thread (and that may be updated with things from this thread, maybe):
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Wishlist
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Bugs

By UI I was referring to the Missionpack UI. That has its own stretch functions and it's not related to cgame (cgame's where the traditional hud and crosshair stuff is at)

The trick is to issue a zero sleep.

Another thing (probably the solution would be a very small gamecode change, anyway I write it here because it's a rendered-related feature!):

Geometric detail: I've seen that it is possible to set r_subdivisions to 1 or to 0, other than its "classic" values (4=high -default-, 12=medium, 20=low). And curves actually look better than with "classic" high quality (e.g. wrackdm17 shotgun platforms, over the jump-pads).
This means that is easily possible to get better quality from the game (when looking at Bezier curves, I suppose), without the need to change anything in the engine. What do you think about adding a "very high" geometric detail option to the GUI (linked to r_subdivisions 0 or 1), to make this available to all users and do not cause anymore r_subdivisions to be reverted to a lower quality (higher number) the first time the user will apply any kind of change in the "graphics" menu?

See also: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail

Question: is the "geometric detail" in the GUI related also to some other cvar, other than r_subdivisions?

yes, r_lodbias which controls the bias distance of LOD meshes

If I do missionpack UI i'll have all sorts of options exposed in the menus, like 16x anisotropy which is oddly omitted in the q3_ui...

now you're getting more into the trivial 'add menu options' wishlist rather...

Sorry for being a little "OT", if it is... I'm interested into understanding better what that r_lodbias is.
Searching the net for "lod bias", somewhere someone said it controls the distance at which a lower-quality model of an object is shown.
But in this page http://www.planetquake3.net/tweak/lod_benchmark.html (quite old, about 3dfx, but however q3-specific) it says "L.O.D. bias" changes texture quality (from sharper to smoother), and even suggests to set it to negative values. Maybe he was referring to something different? In that page he does not mention r_lodbias, but there is a place where he mentions r_picmip (texture detail); but in OpenArena negative r_picmip values are not allowed at all (I can't check in Q3 now).

Doing some quick tests in OA, I can see that setting geometric detail to "high" sets r_lodbias to 0, while setting it to "medium" or "low" sets it to 1. I don't notice differences in texture quality by changing r_lodbias, but I can notice that, with it set to 1, some weapons (it seems not all... however, an example is the shotgun) in my hand are drawn using less triangles (with lower quality); if I set it to 2 (or more), even less triangles are used and the weapon looks bad.
Looking at the "bubbles" of health bonuses in the arena, instead... I can notice that r_lodbias influences them, too. If I set it to 2, they look "low polys" even when I am next to them... if I set it to -1, they are still shown in "high polys" also at the distance where they usually switch to the low polygons mode at the default value, 0.
I suppose a future "very high" geometric detail quality may set it to -1 or similar, too... what do you think about it? Okay, maybe it's stuff for another thread...

Anyway, what do you think about that page I linked? That guy made some confusion with texture detail and lodbias, maybe? But where his negative values would come from, in that case?

PS: I tried to explain DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail]here (http://([b) what those settings do... would you like to fix it, if I did errors? Thank you!

That guy doesn't know what he's talking about.

I already explained what r_lodbias does. Also I have to produce the LOD meshes by hand btw so it's not automatic reduction

Consider that I'm not too much into how a renderer works.
I suppose "LOD" means "level of detail":
From Wikipedia: http://en.wikipedia.org/wiki/Level_of_detail
... thus the variable controls the distance at which the engine switches from using an low-detail model to a high-detail model (or vice versa), to save resources or to give better looking. And it affects some items only because you created low-detail models only for part of them. Summed up right?

I did update the wish list.

Gig, first time I am reading this thread and I have no issue with anything you wrote unless you are advocating that r_subdivisions be locked to 1 or 0.  I don't think that is what you implied but I want to make sure that if anyone has that thought that it be banished.

It may not matter to baseoa but having r_subdivisions set to 20 is advantageous (and one of the recommended settings) in Excessive Plus because surface imperfections are more visible and are the starting point of our BFG/Rocket/Nade and Rail slides.

Unlike other Mods, we use our weapons as much for locomotion as for fragging**.  Any crack, corner, bas relief, sunk relief, etc, is a point for planned or impromptu slides.


** That's why it's easy to spot the noobs in E+.  They are the ones always walking, running, bunnyhopping, and even multi-jumping.

Don't worry, Killer. I was absolutely not saying to place further limits to the option (by the way, the current DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail]r_subdivisions (http://([b) 20 limit is from videoflags).

I was talking about allowing an additional value for the menu option in the GUI. At the moment, we have "low" (that uses the r_subdivisions you like, 20), "medium" and "high". I suggest to add a fourth value, "very high", that would set r_subdivisions and r_lodbias to achieve better quality than with "high". It would make the game look better without having to invent new ideas in the engine, but using something that is already there but is hidden. At the moment, the user can set that better quality only by using the console, and that setting will be lost the first time you will change anything from the "graphics" menu. I suppose a little change in the GUI should be good.
It would not prevent you from setting "low" value.

PS: "Nade and Rail slides"? What's this Excessive Plus' "Sliding"? A sort of enhanced plasma/bfg/etc climbing? Why don't you add sections DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Mods/Excessive_Plus]here (http://([b) explaining main E+ specific features (physics, weapons, etc)?

r_subdivisions can do negatives, FYI, but it's not much difference. r_showtris 1 should reveal how messy it'll get.

Probably, when I did those test, noticed that r_subdivisions works with negative values, too. But I did not try to check with r_showtris 1. Anyway, I didn't notice further difference while setting it to negative values... while I noticed a visible difference (checked with curves in wrackdm17 platforms) while setting it to any value lower than the one set by "high" option (that sets it to 4), so I came up with the idea of a menu value "very high" that would set it to 0 (or to 1, if 0 is too messy) (and that should also affect r_lodbias to show the detailed version of a model at a longer distance).

I am the one who edited most of that page, however, you have to know when to stop before you overwhelm a player who is simply looking for a wiki definition of "What is Excessive Plus?"

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



The best way to explain E+ slides is via demo.  The following 2 minute video breaks it down into its basic parts in a slow controlled manner.

http://oa.goquake.com/servers/basic_ep_movements.flv


This next 2 minute video shows it in real-time:

http://oa.goquake.com/servers/fast-flag-caps.flv


These videos can be viewing via your browser at http://oa.goquake.com if you prefer not to manually download and view these.


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


Fromhell, I was unable to embed an SWF into the post.  Either you have not enabled it (...Admin > Posts and Topics > Embed flash into posts) or you do not want it enabled in which case you can and probably should remove the icon.

Portal rendering. Portal rendering is what unreal 1 & 2, max payne, source engine, doom 3, and other games do. It's much less time consuming to place a portal on a window or doorway than to place a lot of hint brushes. Even Crysis had them.

Or drop PVS and use a buffer to determine visibility in realtime like http://www.umbrasoftware.com/ That's what unreal engine 3, cryengine, killzone, and other games are using now. But then, dynamic visility is much harder to do, who is gonna do it?

During development Quake used to have portals for traversing but it was slower. Then again Quake was weird, software only, had surfacecaches, etc.  This was never approached in their GL version.

And their maps broke each and every single map development rule.
It's crazy how nowadays there're strict, non-flexible rules for mapping to follow, when the people who mapped for the company which did the engine itself violated them at many points.

Violated on what grounds?

Well, as most things, it has to be tested first so mistakes can be whipped out and  people actually learn how it should be done. Quake 1 is a good example of that.

I'm talking about the technical side.
Word from the era where the Q1DM maps were introduced in 0.7.0 said that it was a lot of pain to work with those maps as they had overlapping brushes (leading to glitches) and bad brushwork in general.

I did attempt to port this but ran into errors on even things as simple as structs. Also, it's an engine client feature, not renderer.    The FX code can be found in here btw (http://sourceforge.net/p/quake3mme/code/HEAD/tree/).

If enhanced new lens flare reflections are something to be implemented....

(http://leileilol.mancubus.net/crap/oaflare2.jpg)

I got that down too :P

Nice... will that be \r_flares 2?

r_flares 5 actually.  I'm combining the lensReflection cvars into r_flares 2, 3 and 4.

Also I just made r_film.....which is much like a next gen game's post processing
(http://leileilol.mancubus.net/crap/oavignettes.jpg)

but done with only blending functions

Wow, are you in a coding spree, nowadays?
Very good news!!!!  :)

Other engine changes i've done (but yet to commit :()

- Fixed the bloom "32-bit textures not supported" message and allow it to work with r_textureBits 0.
- Made the mips of detail textures fade to gray - this combats the distance pattern artifact.  Enabled by default.
- Restored r_drawSun (another feature cut out of Q3A) and added r_flareSun to it, to draw a sun flare above the level.  Has some issues with some skyboxes (two suns effect) so it's disabled by default.
- High resolution dynamic lights (256x256), disabled by default.
- Backported texture resampling from Darkplaces (r_resample). Should lead to less jaggy artifacts on some badly sized textures (non-power-of-2) and will be used by default.  This should not be confused with r_simpleMipmaps 0 which also has lerping but to a lower resolution.  This might also lead to better image quality on Riva128, but this has not been tested.   Here's an idea though - have a scaler algorithm for lightmaps like HQ4X?


A picture of the sun right now, which needs its brightness and size tuned automatically in the code

More engine hackery, flare edition

- custom flare textures finally supported
- r_flareQuality 0 now offers a very fast but rougher flare.

Compare the framerate differences between these oa_pvomit shots :P

Too much cool and awesome stuff... I can't wait to try that.
Eyecandy which doesn't cause framerate slowdowns is a good thing in my book.

I'm also working on r_textureBits 8 support.

It would only benefit Voodoo users (paletted texture = huge vram savings, possibly allowing picmip 1 or even 0) and the software GL ICDs that support the paletted texture extension.   It also looks a bit retro as a side effect.  Also it's a long deprecated extension most cards since the Riva TNT don't support.

PCX textures will get their palettes used (hopefully), otherwise everything else is converted to gfx/palette.lmp.


Also I fixed r_monolightmaps/greyscale so oa_thor doesn't have black lights for the blue lights


EDIT: I got paletted alpha working, also, and on an actual Voodoo2 it uses the extension and utilizes it :D

EDIT2: I benchmarked. Definitely is faster with r_picmip 0 in just Quake3. q3dm11 has a particular spot where texture thrashing happens and takes a nose-dive to 5fps on 16-bit textures. Forcing 15bit makes no difference. 12-bit textures are also not an option.  8-bit textures? No problem! No thrashing happens and the framerate is still okay.

Whoa! Fromhell, I like how much you are working on OA recently! This stuff sounds very interesting!  :)

With all respect towards Fromhell; Too bad it's voodoo-only improvements; some late '90s graphics cards while we are living in 2014 currently =S.

Has there been any poll of which graphics card players use on this forum?

It's not Voodoo-only.  Some onboard video chipsets and software rasterizing ICDs can make use of paletted textures.  The way I've implemented it has been successful in function on a Voodoo2 so far.   Another point of this is to strive and improve performance on that BSD platform where entitlement of software rasterization seem to be the norm.... kind of a bizarro world.  It's an extra step towards this on the list:



Although modern graphics are a nice thing, taking advantage of modern functions like per pixel lighting would require another art overhaul that is impossible to achieve in the current circumstances - and renderer_opengl2 doesn't look that great with OA right now... and polishing by HDR, SSAO, new lighting methods does not solve the stiff animation art consistency problem

Perhaps there is a stiff animation art consistency problem, but is that even related to this topic; a wishlist aimed on the game engine of OA?
I think not...

Considering most of the OA complaints are about performance and darkness, permanently going the path of XReaL for the minority of graphics snobbery without any legacy options are not high on my interests.  I don't know how many times I have to repeat this.

If I want to make something look good, I do that in a modeling and texturing art program.  If I want to make a whole game look good, i'd want to equalize the effort I do on assets.   I do not believe bumpmapping and shadowmaps would take ease on production efforts because that would to me, equate to 'polishing a turd'.   The reason why OA supports GLSL are for postprocessing (for supporting gamma by shader and the like) and minor map texture improvements, not a whole renderer reworking.

Do you remember Sauerbraten when it was still using MD2?  Modern graphics couldn't cover 1998 anachronisms well.

It still uses the .md2 format for monsters in SinglePlayer mode (the reason for that is as that mode is stable and eihrul isn't planning to improve it due that).
Then again, I get what you mean...

I do want some stylized phong-based shading however, as an option...


like this:

Not sure if it's an engine or gamecode thing...

Another seemingly unfinished Q3 feature which may be useful is the nearbox. Q3 shader manual mentions it probably does not work.


Yesterday I did a try, and it looks like nothing happened.
I tried with both alpha-channelled .tga (which I can guess may be needed to achieve the "clouds hidden behind mountains" effect) and plain .jpg (I can guess in theory this should just cover that whole face of the skybox with that side's nearbox texture, isn't it?), and it did change nothing. Maybe it's my fault and I did something wrong, but I have the impression this doesn't work in Q3A (FAKK2 shader manual hints it as experimental (http://www.ritualistic.com/games/fakk2/editing/shader_manual.html)).
Maybe some GPL'd iD Tech 3-derived game already completed its support?

Actually glsl implementation has something like this (though I have never used or tried it). It was part of the original ZEQ2 glsl and for its usage you would need to read the glsl related post on the ZEQ2 site. With glsl lights it should be possible to have the specular component.

Huh! I never knew.  Though if OA implements it optionally I'd also have to make a special cel skin for each texture which would only have flat colors, and a rather soft normal map by it, with only hard edges on clothes, and these cel textures would only be loaded when the renderer is in cel mode...


Also, i've made a few cvars:

r_slowness
r_slowness_cpu
r_slowness_gpu

which should roughly fake the speed of the MHz you set CPU to (based on p2 performance, default is 300)  GPU is much looser and is based on mhz (like 93-96 for Voodoo2) and also scales the slowness by screen resolution.  There's even a synthetic bottleneck.  It won't be practical for play, but may be useful for content production (like for realizing the critical performance choke points in the maps - oa_spirit3 has a BAD one thanks to the portal in the water, for example)

What it really  is, is just a sleep command called every finished backend buffer determined by a bunch of division on numbers of vertices, indices, surface count, etc...  It's much better for nailing low performance that com_maxfps can't reach.

Currently no way to simulate texture thrashing (r_slowness_vram would be such a cvar, notably R_SumOfUsedImages does not function at all - and would have been great for doing this)

No, that could possibly regress all the sky shaders if implemented.  I think Spearmint implemented this (in it's unrealistic weird prospect of trying to support the closed games) but that's GPLv3.  Nearbox is not in JO, JA, RTCW or ET.

Besides, a mapmodel operating in a q3map2 skyroom would be more lively and possibly vram saving :)

Not sure about the reason for this... Considering nearbox does not currently work (setting it seems to change nothing), I can guess almost all existing shaders should already have "-" (no nearbox) at its parameter... However, one might also create a cvar to enable/disable the feature.
However, if that's hard, patience.  :)

Maybe I may give a try to this "skyroom" thing: is that the same thing named as "skyportal" here (http://en.wikibooks.org/wiki/GtkRadiant/Skyportals)?
I may need to find some more detailed guide about that... first googling results aren't satisfactory...

What about a placeholder shader depending on what path the texture gets loaded and not found?

like for textures/ shaders, (EXCEPTION BEING sfx and fx) there could be some sort of rock texture.

for models/ there could be a metal chromey placeholder texture.

for gfx, the yellow :] face could return :P


EDIT: I have just implemented this and it is working as intended.
(http://leileilol.mancubus.net/crap/placeholders2.jpg)

Fromhell, you are a genious!  :)
However, it should be possible to enable and disable this feature (even from the GUI, maybe?), otherwise checking for missing textures would become quite hard! I don't know if that should be enabled or disabled by default...

I agree  ;D ;D

There is a PK3 to download this feature ?
It will be implemented in OA3 or something else (community mappack maybe) ?

;)

Well, that would solve a lot of issues! But how does that work?

I can guess it's an engine tweak which will be shipped with updated binaries (however may also require a new pk3 if the shaders/textures invoked are new).

It's an engine tweak yes, and relies on two shaders for now:

placeholder_texture
placeholder_model

but I should expand this to include six more

placeholder_sky - which would be a blue sky, unless I can somehow color it from the map's ambient light somehow
placeholder_fog - which would be a generic gray fog.  Fogs are textures too
placeholder_water - which should be water.
placeholder_lava - which should be lava.
placeholder_slime - which should be slime.
placeholder_metal - which is a generic metal texutre - for metal surfaces


And for map/texture development one could just make nicely specific grid textures for these explaining what they represent, instead of placeholders intending to blend.

and finally if the engine can't find these shaders, it won't use them and will go back to the white square.  I've already committed this feature to the Git btw.

About the way to distinguish whether it's fog, water, water+fog, lava, etc.... If the shader itself is missing, you cannot just read it surfaceparms from the shader file... I suppose in that case you will somehow read the properties that q3map/q3map2 stored into the .bsp file, right?
A few surfaceparms are however considered during game run-time instead of during map compile time^[1]... how to manage them? For surfaceparm nomarks, I can guess your tweak may presume if the surface is water, lava or slime, that it should have "surfaceparm nomarks"... but for other parameters, I don't know.

^[1] I remember I noticed this with "surfaceparm nomarks": you can add or remove it without having to recompile the map to see the change.
Side note: water shaders only show marks where water depth is smaller than X units. I can guess for future OA versions, we should fix existing water shaders to add "surfaceparm nomarks" to those which currently don't have it.

PS: Don't forget to make a cvar to enable or disable this (smart) feature.  ;)

PPS: Maybe, for "standard" missing textures (which are not models, sky, water, etc.), one may read if the filename contains "red" or "blue" character sequence, and then use slightly red-toned or blue-toned variants of the "generic rock" texture? Uhm... maybe that may become too random...
However you may do tests with DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Map_compatibility]maps which lack many textures (http://([b) and look at the results...

Also, some textures just can't be avoided, such as the CTF-specific textures, for base recognition. We already have the replacements for the base arrows, which became pretty common post-TA (especially thanks to the Threewave packs) but some base-specific deco must still be made by hand.

OK Gig, i'll take this feature out too. You convinced me how important it is to leave glowing white squares in every map OA isn't compatible with.

I'm porting Quake3MME's FX system over now (the fx_ files placed after huffman.o in the makefile).  It is in the github engine, it's not linked in the makefile yet and I'm getting a crapload of errors with the header that i'm lost on what is causing it.


Unlike MME I do plan to have the FX scripts triggered just by sounds and models rather than cgame hooks so the compatibility can still remain.

This of course brings up two other discussions...one I'd like not address GPL v3  versus V2, but RTCW introduced a trap-call "trap_getTag" into the game logic.  What this allowed for was easy implementation of location based damage.   

If a feature such as this was introduced into the engine it would open up a whole new dimension of game play...."BOOM Headshot!"

It would also mean many models would have to be reworked as their tag-head/tag-torso locations are in weird spots visually.  I think fromhell (fromhell) mentioned this about Angelyss a long time ago.

Currently the only other way to do the locational damage is really code heavy in the logic like Smoking Guns, ET:NoQuarter (which borrows the code from Bani's ETPro). Whereby the models are all essentially reparsed/reloaded in the game logic so their coordinates are accessible for hit detection.  this means a lot of hacking up the header files, ballooning the memory the server would use and at the end of the day the models would still have to be reworked to be visually correct.

but just a thought...iortcw did get qvms working again, fixing one of Hacktivisions major bastardizations of the multiplayer component.  Among other things they screwed up shader parsing in an effort to cache them to speed level loads.   Its why the same maps on essentially the same engine never looked the same.    BUT...think of the AI for single player missions that would be accessible...

if I'm ever integrating 'headshots', it would be purely a clientside cosmetic with no effect to balance,    and I do not think scavenging RTCW sources would be necessary for it.

Playermodel bounds should not matter for hit detection, as the rest of the game uses uniform hitboxes for all playermodels.
Some Quake 3 mods implemented headshots by splitting the hitboxes into e.g. upper third and claiming a shot into it would be a headshot, no matter whether the playermodel actually has its head right there.

I don't remember which license is q3mme under...
However, a couple of links about oamme by biox1dE (http://openarena.ws/board/index.php?action=profile;u=3795):
http://openarena.ws/board/index.php?topic=4117.0
http://oa-chs.warsforum.com/t75-oamme-openarena-movie-maker-s-edition
(Was it done by reverse engineering q3mme? I don't remember...)

About damage location, I think it's DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/NOTTODO]NOTTODO (http://([b) area (sounds more adapt for a mod). Maybe one may decide to implement it like a few Q3 mods did, but it should remain an optional feature disabled by default in baseoa.
Also, as Unlagged mod documentation shows in these screenshots (http://www.ra.is/unlagged/faq.html#IJRAMBIHOIJRAHBIM) (thanks to its cg_drawbbox command), Q3 models placement inside their hitboxes was quite variable (during some animations, the player model appeared almost completely outside from its hitbox!)... I have no idea if OA models do suffer of this problem to the same degree or less.

GPLv2 engine source is available on sourceforge (http://sourceforge.net/p/quake3mme/code/HEAD/tree/).

Thank you. It looks like someone already posted it before, and I just forgot about it (I just noticed that link is already mentioned DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Demos]here in the wiki (http://([b), I added it last September).

That's why I contributed to OAX in the first place, so servers wouldn't have to run all their crazy 10 year old, not updated anymore or closed source quake 3 mods.

And because I'm on a phone so I can't quote the post...to fromhell/fromhell's comment about rtcw sources....I noted that it wouldn't be necessary either, just more efficient from a code perspective    Smokin Guns has the game module reparse all the player models again to create the hit boxes (they are already parsed by the renderer/client subsystem in the engine).  The thing RTCW does is just add a trap call from the game module to the engine so the engine with a return value of which model tag the shot intersected with.

Again, in both cases it would require models to be reworked so tag_head is actually at the head as displayed---and it is a lot of work.

Adding trap calls or messing with any of the structs in q_shared typically breaks the compatibility with all the other old mods anyhow--Although it would be nice to have playerState_t and entityState_t to be 32-bit instead of 16.  Does anyone know if this would break old mod compatibility if we changed the engine to use Msg_WriteLong for these instead? I'm not sure it would/would not.  Nor do I have two hours recompiling the source on Windows to do so...or the 6+ hours to repartition and dual boot 'Nix.   Any indicators whether or,not this would work?

playerState_t and entityState_t are structs, both larger than 16 bits (pointers to them are not transmitted). Any surrounding struct will change size if you adjust any of the two and thus most likely cause desync or crashes.

I should have rephrased...
playerState_t->persistant[]
playerState_t->stats[]
playerState_t->powerups[]
playerState_t->ammo[]

Now you are correct, it does crash.  When you modify msg.c to use MSG_WriteLong and to write the above integer arrays as 32 bits, you have to modify the corresponding read calls as well to use MSG_ReadLong. 

I suspect we could dual code this...
Use a cvar like sv_legacyMod.
When set to one, it codes these as 16-bits.
When set to 0, it codes them as 32-bits.

Old mods we can't update would work just fine.  New mods, wouldn't be limited by just 16 stupid bits.

The server would send this cvar to the client during the initial connection phases. 

Whenever I need some additional bits, I just stuff them into (the high bits of/unused) fields. This is not a very clean (could use macros for access to make it somewhat readable) or nice solution, but it works if you do not need space for that many values :)
Most of the time you can get away with restricting yourself to a char instead of a full int as well.

heres a wish. delete your engine.

I know it's a no-no in the general forum netiquette of the Internet to answer to a troll, but...
Do us a favor and get a goddamn life. =)

Added lightingSpecularDiffuse and removed r_shadeMode because I couldn't reallly go far with different shading models. Not even my 'lame' diffuse shading was any faster on P2 300 and I never got multiple light sources to work from the lightgrid.

There's probably a change i'll return to that idea in the future though but anyway lightingSpecularDiffuse is intended to replace my 'second stage specular pass' method which takes a bit of fillrate and also works in vertexlight mode.  However it expects overbrights to work, and disables itself if there's no overbrights available or if r_shadeSpecular is set to 0 (falls back to normal lightingDiffuse). It's intended to make OA3's guns and players shiny with less overhead of also having alphaGen lightingSpecular, blending a stage, etc.


I also added tcgen environmentWater since it's a direct import of the environmentmapping code from JK2 (which may be directly inherited from Star Trek Voyager Elite Force) and has some coords set differently which is more than appropriate for use on water surfaces to make fake reflections.  The viewmodel reflection stuff is still left in there so the old 'gun gleam' can still be made from it.

New water effects, you mean? Interesting.  I'd like a screenshot or a video. :-)