I believe the animation names (BOTH_STAND1 etc.) are hardcoded. That's why there's BOTH_CIN* for level-specific cinematic animations. It would be nice if the names were not hardcoded, and you could just add a new one by listing it in animation.cfg.

The .ibi format does not need to be changed, the animation names are saved as strings in there anyway. It's not until ingame that they're presumably turned into an enum.

I propose that the renderer is rewritten or at least updated to take advantage of the newer graphics techniques which have been available for the past 10 years or so (they were introduced around the same time that JKA was released).

There are many ways the current renderer can be improved. The bottlenecks in the current renderer (from an educated guess) are:

• All vertex processing is performed on the CPU. All games nowadays offload this work to the GPU which is designed to handle these types of calculations (in parallel).
• All vertex data must be transferred to the graphics card every frame. Using vertex buffers allows the vertex data to remain resident on the graphics card which are referenced by identifiers. Instead of sending all the vertex to render, the renderer can instead tell the GPU to render vertices from a specific vertex buffer instead.
• Each shader stage is a separate 'render pass'. This means that a surface may have to rendered multiple times in order to generate the desired outcome. I half-wrote a Q3 shader to GLSL shader translator a few years ago which I may consider finishing to help with this. By doing this, most cases the shader stages should be able to be merged into one render pass.

I'll post a proposed renderer design some point in the near future (hopefully). I probably won't have enough time to code it until June/July so by posting the design, there's a chance someone else can start work on it.

I'm currently in the process of doing so in order to be able to compile it on non-windows platforms. Are you guys interested in a contribution?

Any chance you guys are going to update these to work properly in widescreen and eyefinity? They can be made to run at any resolution via an ini file, but it'd be nice to have proper resolution detection in the menu, or at the very least just fix the HUD for WS and Eyefinity.

When Return to Castle Wolfenstein's source was released, a guy did a fix for them for widescreen and triplehead, I've mirrored his source code here: https://github.com/thelolotov/RTCW-WSGF

He unfortunately seems to have dropped off the face of the earth, otherwise I'd just ask him.

Anyone willing to give this a go? It would be amazing to have widescreen and eyefinity working properly in these games, and it couldn't be that hard to port from another Q3-based game, his solution was kind of bare-bones, but it worked.

I have the programming capabilities of a legless frog, otherwise I'd try and do this myself, but if there's any way I can help, please don't hesitate to ask. I can clear up any confusion regarding my request, etc. If someone does do this, I can give you guys a plug on wsgf.org, as I am staff there.

Thanks either way, guys!

I've found with jamp that if I have two monitors and put the JKA window on the secondary monitor, the mouse doesn't get locked to the window properly. It seems to lock it towards the left edge of the second screen (sometimes outside of the window) which prevents me from turning/aiming etc. This might be because my second monitor has a different resolution (1280x1024 compared to 1920x1080).

https://github.com/Razish/OpenJK/blob/master/codemp/renderer/tr_scene.cpp#L215

ifdef _DEBUG

if (ent->reType == RT_MODEL)
{
    assert(ent->hModel || ent->ghoul2 || ent->customShader);
}

endif

to get error make yourself have flag powerup i tested with powerup 4, which is red flag i think.

another way to reproduce can be give yourself all items, and deploy inventory shield, then run up to it while pressing +use

FIX IT

While I realize this is an early project, I've notices that several commits are a bit... ambiguous in what they are accomplishing, and several of the pull requests don't exactly state what they do. If this project is going to become the main base of all other JK mods, organization is crucial.

For an example of good organization, lets take the Bukkit project as an example. Each pull request plain and simply states exactly what it does. Now to be honest, their formatting standards are ridiculous, but I think we should at least have clear pull requests so that project followers and contributors can easily track progress and see what needs to be done. Some examples of ambiguous pull requests (and now commits) include this commit, this commit, and this one.

On the first link, I had to go in and check the diff just to see what it did, which was change the config files from 'jaconfig.cfg' to 'openjk_sp.cfg.' As such, a more appropriate title would have been Moved SP config file from jaconfig.cfg to openjk_sp.cfg or something similar. For the third, I might have said Merged Linux and Mac ifdefs on dedicated server

Another thing to work on is squashing commits. I know, it's a pain in the rear if you're like me and use a console to do everything Git, but this (again) goes to help with the topic of plain and simple PRs. This might also require a bit of cooperation between the PR commitee and acceptee, since it can be difficult to get people to squash when needed. The only other option is to have the PR acceptee to squash them and then commit them. Again, either way it's a pain, but once this project is up and going it will end up making things a bit more clear.

Now obviously this is just my opinion and is just a mere suggestion, but it is definately something to think about and consider for OpenJK. If anyone has something to add or critique feel free to comment. :)

Remove QVM layer, add import/export tables like the renderer interface.
QVM binaries are not used in JASP/JAMP anyway, the QVM/syscall layer is just extra overhead: CG_Print -> Com_Print -> trap_Print -> CgameSyscalls (pass arguments etc) -> Sys_Print ... or we could just call cgi.Print which points to Sys_Print

If we plan on officially supporting JO, we'll likely need multiple versions of the imp/exp tables for binary compatibility -- or just one large imp/exp table with all necessary functions?

We can also have a simplified syscall layer for legacy purposes (e.g. existing JA+ builds)

From the game/cgame/ui perspective, *_syscalls.c is all that needs changing, it's very easy to port existing code to the new API.

I've been looking for source code for years because I've been developing a project based off JA, and wrote to devs many times to ask for the source but eh, anyway, it's finally released.[/offtopic]
What I'm actually asking about is if OpenJK project is going to be compatible with other two popular platforms - Linux and OS X? This is a thing that have been stopping me from further development of my project for months.
I'd personally love to see support for latest GCC in Linux and Xcode 4.6.1 (possibly clang?).
And so I'd love to suggest that it would be a good idea to use CMake to generate project files for Linux and Mac.

P.S. I'm pretty sure there are many people who are ready to work on Linux stuff if OpenJK aims for cross-platform support. However, not sure if there are any people who are going to port this on Mac, and so I'd love to contribute to this project too by helping with cross-platform code porting. Though my C/C++ knowledge is not more than 'a bit below average', I can test building and fixing some stuff for Mac and Linux support since that one really bothers me.
Thanks in advance.

P.P.S. I am completely new to GitHub, just registered, forked this and posted here for the first time in 5 minutes while being asleep at nighttime. So please, if I posted this in wrong place, don't be angry and explain where to post it in, and I'll fix that.

Note: This issue is to do with the ghoul2 format, not something that is wrong with the OpenJK project itself.

GLA doesn't allow a 1:1 copy of an animation from XSI ModTool/3DS Max/Blender. Instead, you will get slight 'jitters' in the animation where the bone will 'jump' around at the bone pivot when it is being played. Any high detailed animations will look horrible.

Suggestions: Try to fix the format (start with modview first, before carrying it on into game as it's easier to see fixes) or replace the format entirely with something that is XSI ModTool/3DS Max/Blender friendly.

It would be nice if at least the entities of a level could be modified, like having any file in <levelname>/*.ent be added to it or something like that.

This would also allow for making changes to original levels (say, showcase a new feature) without getting asset redistribution problems.

When I try to run the JediAcademy solution in Visual Studio 2012, I keep on getting a "Unable to start program 'C:\Users\pakn\Desktop\OpenJK\code\game...\Debug\game.dll'." error message. Is anybody else having this issue, or is it just me?

I don't know if this has been fixed yet, but in the original jamp.exe, mod assets weren't loaded properly from the mod folder (e.g. animations, language files, etc) unless the game was launched specifically for that mod using +set fs_game "modname".

By using the HUB Spawnflag on a target_level_changer, you can save a level's state and restore that on a subsequent load. This allows for a lot of cool stuff in mods, like splitting big levels in multiple parts.

The technical realization leaves room for improvement though: The level's state as you exit it is saved to save/hub_.sav - the obvious problem here being having multiple parallel playthroughs - you can't save two different states of the map.

I propose a playthrough GUID that is kept across level changes and saved/loaded, but renewed when starting a map via console or the New Game option. This would be used for the hub savegame names, and could incidentally also be used for auto- and quicksaves.

The set()/get() functions in scripts should be able to operate on cvars to give mod authors more power. This does not require changes to the .ibi format, we could just check if a given name matches a cvar before doing other tests. Optionally, a prefix ("cvar_g_speed") could be added, which would especially make adding new cvars from within scripts easier without changing the format.

We might want to investigate 64 bit compatibility at some point.

Short version: We're illegally redistributing binkw32.lib and bink.h

As Rich Whitehouse noted here, they accidentally included the Bink library. We might face legal issues in the future for having that in our history. For that we'd need to rewrite history, as described here.

As mentioned there though, this will break every single fork done before the rewrite, and users will have to do a rebase as described here under "Recovering from upstream rebase". That makes me a bit reluctant to just do it.

If we're going to do it, it should be done ASAP though, before we get even more forks. (50 is already far too many though...)

There are also still BinkVideo files in client/, those should be removed as well.

Full list of people who forked (We can't know who just downloaded it locally of course.)

Add that.

I remember a playermodel that got changed via

set("SET_PLAYERMODEL", "...")

from Icarus would lose its textures after saving and reloading. (Needs verification?) Let's fix that.

The current menu system has a couple of drawbacks, including:

• Defining looks and data in the same file - Model View Controller could help?
• Only knowing relative coordinates - having both absolute and relative coordinates would help support different aspect ratios and would add the option to have constant-sized (in pixels) elements, i.e. HUD is smaller on higher resolutions. (Keep high DPI screens in mind though (Retina or whatever apple calls theirs?) - maybe make the Virtual Menu Resolution configurable in the options.
• Not being very extensible - if two mods want to add to the HUD, they'll conflict.
• Not being easily customizable - an MMO-like interface that users can rearrange would be nice?

I can look into this at some point, though that's some time off still.

Simply put, this makes the rodian2 model look pretty funneh/see-through where his vest should be.

In singleplayer, alternate between multiple quicksave slots in case something goes wrong while saving or the player quicksaves in an unwinnable situation (e.g. accidentally saving instead of loading while falling to their death).

Can anyone else compile SP and see if they get issues running the game when com_jk2 is 1? Thanks.

We've received reports of SP being broken due to lack of Force Feedback files, which might just be true since they were recently always have been removed. Could somebody check if jasp.exe/jagamex86.dll/jk2gamex86.dll still compile, and see Rich Whitehouse's Commits (particularily the "Fixed all JAMP errors and warnings in Visual Studio 2010, added new project files and upgraded solution file." one) for potential fixes.

What are we going to do about merging the playerState and game_import_t/game_export_t from JK2? I suggest using the JKA one in JK2, and adding all missing fields from JK2 back in, but I'm not totally for sure on that.

It would be useful if mods could add additional animations without having to change the original .gla. (Incidentally, that would also help with redistribution, since the new files are no longer modified versions of Raven's assets.)

It could work like this: When loading a .gla, all animations from .gla files in the folder with the name of the .gla get loaded as well. So to add a climbing animation to _humanoid, you'd have

• models/players/_humanoid/_humanoid.gla/climbing.gla
• models/players/_humanoid/_humanoid.gla/climbing.cfg

The latter is akin to animation.cfg, but since there can be multiple additional files we obviously need to use a recognizable name.

An obvious problem here is MAX_QPATH - when adding to the animations with already long filenames, the path could easily get longer than 64 characters. As long as the filesystem is able to cope with that it won't be apparent to anybody once the additional animations have been added though.

Some groundwork for this has already been done in SP, where _models/players/humanoid/humanoid<levelname>/humanoid<levelname>.gla is added when playing maps/<levelname>.bsp. (Which also easily reaches MAX_QPATH, by the way.)

Apparently Raven did an Oops and shipped the XBox version's code in the jediAcademy.zip archive, which has a couple of things stripped out and in general does not compile on Windows anymore.

Meanwhile, the jediOutcast.zip archive contains the actual Jedi Academy PC source code. We should use that for this Repo instead.

Ran Visual Studio 2012's static code analysis on the code, and found these problems:

common.cpp, line 1696

    buf = new char [length + 1];
    FS_Read( buf, length, f );
    buf[length] = 0;

    bufParse = buf;
    parser.Parse(&bufParse, cleanFirst);
    delete buf;

The delete should be delete[]

common.cpp, line 1721:

    buf = new char [length + 1];
    FS_Read( buf, length, f );
    FS_FCloseFile( f );
    buf[length] = 0;

    bufParse = buf;

    parse = new CGenericParser2;
    if (!parse->Parse(&bufParse, cleanFirst, writeable))
    {
        delete parse;
        parse = 0;
    }

    delete buf;

Same as above.

CVec.h, line 595:

    float& radius()                                                         {return v[3];}

v has type float[3] - it has no fields following it.

tr_bsp.cpp, line 1774:

            out->parms.color[3] = 0.0f;

color has type float[3], with a float field following it (which is set in the line below anyway).

• can't control people on speeders properly (buuuuugs!)
• controlling people = bad prediction mojo
• viewmodels on tuskens = MESSED UP
• Remove spacebar from mind control dismount, instead use force powers
• Add weapon switching to NPC
• Add force power usage for Jedi

I finally got Jedi Outcast to compile under Visual Studio 2012, but now I am getting linking errors for SG_read (I have no idea which library could this be) and Ghoul2 (I can't find a lib or dll file anywhere, not even the source but its source lies somewhere in the code folder).
As soon as #5 is merged, I will upload my fixes here

So in JA and I'm assuming JK2, jedi/reborn NPCs have no recognition of pitfalls or lack of ground when they're moving, and often run/jump off cliffs/into pits without any regard if there in an open area.

Now I know Jedi don't use waypoints, but they're smart enough to know when they can leap up/down after you, so is it possible similarly they could have some awareness of areas where they could fall? It's beat you can't really have jedi in open areas because they won't pay attention to cliffs and stuff.

For example doing /serverstatus:
SV packet loopback : getstatus
SVC_Status: rate limit from loopback exceeded, dropping request

Other clients unable to getchallenge aswell.

So the electro-binoculars view is messed up in JKA SP, works fine for everything except lightsabers/melee which have no 1st person view, so it forces it to stay in 3rd person.

Any chance this could be fixed, and maybe the 1st person lightsaber view could be brought back from JK2?

I heard JK2 used it's own special transparent model for 1st person sabers, but JA could just use some variation of the cg_thirdpersonalpha cvar to some extent, which doesn't work but I think is supposed to make the playermodel look transparent...

Also, I would love to see the screenshotted save games return from JK2...

After playtesting for a few minutes, being the person I am, I decided to repetitively stab Kyle on yavin2 (training grounds), who in turn killed me. However, after I died the death menu that has the load save, quick load, change level thing did not appear.

After multiple tests, the same bug recurred. Also, I should note, that after betraying your friends, you can get the epic slow-mo shots while killing them. I particularly enjoyed killing Rosh in slow motion. >:)

pic of no menu
pic of me epically killing Rosh
another pic of me epically killing Rosh

How soon are we going to distribute prebuilt binaries? How far along is Mac/*nix compat?

The startup ROQ(s) don't play video (but audio works) when in custom modes in the single player exe.

If the mp binary is not called jamp.exe, it crashes due to stack trashing or something like that. Apparently some driver-level application-specific legacy-hacking going on. Let's find out what the problem is (OpenGL Extensions?) and fix it.

Finish CMake so #68 can be started. @mrwonko

I couldn't find any IRC channel about this project, perhaps I simply missed it.
It might be worth creating one and mention it on the main page of the project to help people involved getting in touch.

https://github.com/Razish/OpenJK/blob/master/codemp/renderer/tr_shade.cpp#L1680

if ( !pStage->active )
{
    assert(pStage->active);//wtf?
    break;
}

I hit that assert. Not sure why. Note I'm using my WIP CMake projects, so could somebody please try to reproduce this using the vcxproj? I doubt it makes a difference, but who knows? Debug build of jamp.exe on Windows.

Meant to create a milestone, not an issue.

Probably want to add some code to allow modern CPUs to be recognized. JKA still thinks I'm using a Pentium IV (I'm using a Core i5).

We should use libpng for PNG loading, since it's likely better than what Raven hacked together.

Old message:

Just opening this so people see they do not have to do this. I'm on it in my CMake branch, which will be merged back once I'm done with it.

Reportedly alt-tabbing does not work in fullscreen. I wouldn't know, I play windowed.

Deploy buildbot or jenkins to automate testing and possibly automate builds.
Could replace #52

What video resolutions does the ROQ format support? Are HD videos possible? Can the ROQ creator handle higher resolutions? (I think we've got its source?)

Just thought I'd create an issue regarding this. We're evaluating adding the SP features to MP in order to have only one codebase. I'd be willing to look into this at some point, I think it would be very useful. It would likely be done through a mod.

The SDK is available after registering at https://developer.oculusvr.com/

Development info can be found here:
https://developer.oculusvr.com/forums/
http://www.mtbs3d.com/phpBB/

com_maxFPS 85 -> 125 see http://jkhub.org/topic/1669-/?p=19939
rate 4000 -> 25000 because 4kB/s is not enough for up+down
sv_fps 20 -> 40 to improve saber collisions and general responsiveness (50msec vs 25msec)
snaps 20 -> 40 and/or synchronise with broadcast sv_fps ala CPMA
r_picmip 1 -> 0 if people want low resolution textures, they'll do that themselves. 0 is not unreasonable on hardware in the last 10 years.
r_mode 4 -> -2 with native res support @ensiform :D?
sv_master2 N/A -> master.jkhub.org
g_maxForceRank 6 -> 7 (real max)
cl_maxpackets 30 -> 63 (~2 usercmd/packet with 125fps/8msec)

Objections?