Raz0r

Of an entirely separate game from another genre which does not affect the feasability of a JO/JA port.

Not sure what the relevance of posting an entirely separate game from another genre was. The only thing they share is the name "star wars"

Yep. Also, I've never heard of high resolution external lightmaps only working on patch meshes. All of the screenshots I've seen indicate they are used on regular brushes, across the whole map :S... Confirmed in #ioquake3 that external lightmaps can be larger than 128x128 on regular brushes :/

You replied to mrwonko who said "The code would surely benefit from some refactoring and doing that in C++ wouldn't hurt either, but it's just such a massive task that I don't know if anybody is going to do it." =p

That's not refactored, just compiled as C++

...Because writing the entire process list to a file and grepping it every 10 seconds won't cause any issues If you have the option to run it in a screen session, I would recommend something like: #!/bin/bash echo "Superleet startup script!" status=1 while [ $status -ne 0 ] do ./linuxjampded +set dedicated "2" +set fs_game "japlus" +exec "server.cfg" >log.txt 2>&1 status=$? if [ $status -ne 0 ] then date=`/bin/date` echo "Server crashed with status "$status" at "$date fi done echo "Server exited peacefully"

I forget how MaceMadunusus does it, but.. low resolution (256x256) high resolution (1024x1024)

You already can use external lightmaps?

Talking to rww right now, he has plans to improve the collisions even more =]

r_automap =] It's from SOF2 iirc, was never really completed but some cool stuff =] it actually shows the map as a heightmap too.

theora + vorbis will be an option in the future, we've also improved the RoQ code to allow higher resolutions and fix some bugs.

No, that bug was experienced in Windows servers too and does not affect whether or not you can hit someone, only if your saber can block incoming attacks. It's also extremely obvious when it does happen.

r_lodBias 0 r_detailTextures 1 r_ext_compress_textures 0 r_picmip 0 r_subdivisions 4 r_textureMode GL_LINEAR_MIPMAP_LINEAR r_ext_texture_filter_anisotropic 16 r_textureBits 32 r_stencilBits 24 r_depthBits 24 r_simpleMipMaps 0

Ego and ping, with a touch of low sv_fps when using MP damages (cheat-protected by default). Not even kidding.

Er, I've been using r_mode -1 with r_customWidth/Height for years on online servers before OpenJK o.O<br />The only issue is when you /devmap with it

That was one of the first things we fixed =]

You mean like r_mode -1 r_customWidth 1920 r_customHeight 1080 like we've been using for years =p? Or r_mode -2 where it uses your desktop resolution? Or automatically adjusting cg_fov based on aspect ratio? (mod change) Or stopping the HUD from scaling badly with widescreen aspect ratios? (mod change)

I've created a co-op branch here =] Keep in mind we'd still like to maintain base compatibility as much as possible when not using gametype GT_SINGLE_PLAYER. Jump on the IRC when you can and we'll work out where to start

Only for MP, but should be the same method to make it work for SP

It's not something that can be fixed. It's a miracle they work in the first place There is no positional data for the left saber, so it stays bolted to the left hand.

That's the point of OpenJK. Engine modifications that don't affect base or mod gamecode.

Yep.

It will be a continuous WIP state, but there are milestones set, and you can still use OpenJK when it's in development - it's not likely to randomly crash or eat your computer. At-least no more than jamp.exe

It's usually: loading too many <x> (shaders, NPCs, sabers, models) - these limits can sometimes be raised, but never "unlimited"Poorly constructed mod (invalid image format/size, oversized filepath)Name conflicts (two models named "myreborn", two shaders named "shinything")JA not liking multiple humanoid animation sets

Set 'engine' as your startup project and try again.