Xycaleth

If I recall correctly, using the launcher (JediAcademy.exe) always launches the game in safe mode. Does the problem still exist if you load up MP or SP using jamp.exe or jasp.exe directly?

Ah right. You're using the provided .sln file. It's currently broken so to want to avoid it. Instead you should generate a working one using the .bat file in the root of the OpenJK directory. You'll need to install cmake. Once you've run that, use the .sln file in the build/ directory.

Are you running SP through Visual Studio or are you copying the openjk_sp.x86.exe and rdsp-vanilla_x86.dll files into JKA's GameData folder and running it by double clicking the .exe?

There's some very basic support for JK2 if you build the codeJK2 folder and run SP with start up parameters +set com_jk2 1. However it's very unstable atm and there's a lot of problems.

I'd hazard a guess that your normals are inverted on those sides that are black.

What do you mean?

No, patches cannot be made detail brushes. As the name says, a detail brush is a *brush*. However patches don't create splits anyway. Adding the detail keyword to the shader doesn't make a surface a detail brush either - it simply adds detailed shading (you see more detail the closer you are to the surface).

The reason the loading screen is static is because the game is "locked up" - every time the screen changes is when the game updates the screen. Since there's no multitasking involved it happens sequentially: screen gets shown, load bsp, screen gets shown, load textures (which takes a while), screen gets shown, etc. This same problem prevents maps from being streamed in/out.

UE3 supports level streaming. From what I understand, the whole level is split up into a grid, and each grid cell is streamed in as you get near to it, and streamed out as you get further away. This happens in the background, so you don't notice the loading (at least in theory). It would take quite a lot of effort I think to get this kind of support in JKA, and the .bsp format isn't really suited to efficient level streaming either. There's probably ways to fake an open world (within reason), like making a REALLY huge map but then you run into problems with poor frame rate.

Have you updated your graphics drivers recently?

Would you mind posting your solution so other people with a similar problem can benefit?

Q3mp2 has always used all available cores and CPUs

There's a few small bugs lying around like when you try to connect to a server using a different mod from the one used to start up JKA, and it doesn't load the animations/string/menu files properly. I guess it's not really noticeable but it's still there We don't plan on changing how everything works if you're worried about that.

I find it difficult to believe that increasing available memory alone could give such a huge performance increase but that's still really good nonetheless

When I say we should cater for players, I don't mean to add extra features. I'm referring to what they actually see when they run OJK. So this means, whether it crashes, whether there are noticeable bugs, and so on. The problem that @@eezstreet mentioned where animations/menu files aren't loaded properly.It must be fixable some how

This should probably go in a separate discussion thread. I'll see if i can get a staff member to split the topic. Anyhow, there's two kinds of people we need to consider when prioritising tasks: the coders, cause they want a working and clean code base to work from; and the player, who I think we're completely forgetting about, and who would inevitably be running it and wants to have a working game. From the players' point of view, I don't think any of the changes you mentioned, apart from the mod loading problems, would impact how the game runs (in terms of stability and usability). Almost completely orthogonal/separate to this is the need to tidy up the code and make it easier for coders to work with, and to make it less of a mess. Things like VOIP, OpenAL, etc are nice things to have but don't really immediately benefit either of the two parties. At the moment, my line of thinking is the first milestone will include fixing the mod loading problems, and possibly a fix for shaders with # characters in them, but as far as I know it's only Szico's maps which have these problems. I still need to go through the other issues that need addressing, and then probably run it by a few other people to see if they agree. I don't think even x64, Linux or Mac support are really a priority at the moment, but obviously should be worked on. Code-wise, I'm not exactly sure what needs doing... All of the Ghoul2 and EFX code at the moment is in a pretty dire state, and it would be nice to have a unified code path for sound so it only uses OpenAL. I guess we can just pick random tasks for those and have one or two of them for the second milestone.

A road map is a plan of what is hoped to be achieved at specific milestones in the development. Bug fixes and new features are placed in milestones based on their priority and importance to OpenJK. Not only does this allow you to see the progress that we are making, but it also allows us to see where we are heading and what we need to aim for in the next milestones. There are currently no planned milestones as we are still deciding on what should be prioritised.

I never said there were a ton of junk issues on GitHub :| I was saying that not everyone is familiar enough with GitHub to find all the issues we've fixed and are currently working on. In case you didn't realise, please note that by using OpenJK's code, you need to license your code under the GNU GPLv2 As far as I'm aware, the majority of the changes made so far are aimed at improving the existing engine. One of the more controversial and major changes like moving the location of where the config and PK3s are loaded from allow JKA to be installed in a multi-user environment without requiring administrator rights to add new mods. While it's not so necessary for Windows, this is more common on Linux and Mac. I'm currently in the progress of removing the majority of the compiler warnings in GCC and Clang. When I've finished that I'll be looking at clearing up warnings produced by Visual Studio.

I talked to Archangel about it a few days ago, and came up with a possible solution. It would involve adding a "cloth" keyword (and probably a few others to specify its physical properties) to your texture shader. The engine would recognise this as a surface which would need to be simulated as cloth, and would then simulate the surface as if it was cloth. It would do collision detection and stuff with the world/model it's attached to. There would most likely be a high performance hit - models in JKA aren't suited to doing physics cheaply as there is no way to specify a simplified collision hull for a model. How much of a performance hit, I don't know and until it's added, it's difficult to tell. A potential problem that occurred to me, is if the cloth physics were to be made optional, then would the surface marked as cloth do? I should add that at the moment cloth physics is very low priority in OpenJK and will not be considered for a good few weeks or possibly months while we improve the stability of the engine, and take care of more pressing issues.

I'm sorry you feel that way, and I understand that not everyone working on OpenJK is exactly "graceful" in their responses, let's say. Personally, I want to see people making suggestions, and I welcome them with open arms. This is probably why you see the divide between discouragement and encouragement of suggestions I requested these forums to be set up for the purpose of making suggestions easier, and I also want to make it clearer to people the progress we're making without them having to trawl through our GitHub page which they might not be familiar with. So basically, I'm currently running these sub-forums, but not having moderator privileges here (solely for these sub forums) is making things a little tricky.

Didn't the Darth Vader model from JK2 have some form of simulated cloth physics baked into the animation for his cape? I can't remember who made it off the top of my head though.

I think what DT is trying to say is that existing textures already have extra shadowing and highlights added to them to give them some depth to account for the lack of any form of bump mapping (i use this term to include normal, parallax, displacement, etc. mapping). By introducing bump mapping, these textures would need to have this simulated lighting/shadowing taken out to look good. For example, in the case that a player moves their lightsaber near the texture, the lighting conditions would change.

Right, about time this topic was locked I think... *waits*

HI

Who votes we lock this topic? Otherwise new topics are never going to be made in the rest of this forum.