Xycaleth

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.

As far as I understand, the only part of the online service that requires a subscription is the online multiplayer part (apparently with the exception of f2p games). Every other online service is free to use.

Icarus works for MP too (in JKA).

What is OpenJK? OpenJK (short for Open Jedi Knight) is a community effort to maintain and improve upon the Jedi Academy and Jedi Outcast source, released by Raven Software under the GNU General Public License v2. Our main goal is to provide the perfect engine for JA and JO modders alike with improved features, as well as keeping backwards compatibility with the retail versions of JA/JO, so that all the work of previous modders are not wasted! If you want to talk to us more about OpenJK, you can find most of the main developers on IRC, server irc.arloria.net, channel #jacoders. Where can I download OpenJK? While there is not a solid release for OpenJK just yet, you can find weekly unstable builds for Microsoft Windows, Linux and OS X here: http://builds.openjk.org. These are automatically created every week so that they have the latest changes made in the source code. These builds are still experimental and are not guaranteed to run without problems on your computer. However, if you do come across any problems when using them, please feel free to file a bug report! What do I need to run OpenJK? You firstly need an original copy of the game. Downloading OpenJK does not mean you can play JO or JA without buying them first, as they contain all of the assets (maps, models, textures and so on) required for the game to play (the assets are what make up the game). A few places you can find a copy of JO or JA are Steam, Amazon and Play.com. Can you add feature XXX to OpenJK? Please post any feature requests to these forums! Feature requests are a little more difficult as we want to maintain backwards compatibility with the retail version of JA, but a lot of the requests we've had in the past have been for gameplay changes (e.g., Can you add poison darts?, or Can you make Lightsabers less powerful?) instead of engine changes (e.g., Can you add multimonitor support? or Can you add normal mapping to the renderer?) We understand that not everyone sees the difference between the two types of changes so a bit more discussion is needed How do I report a bug? You can report any bugs to by creating a new thread in this sub-forum, or by using our issue tracker - please remember to provide enough detail for someone to reproduce the bug. At the very least, we expect you to provide the operating system you were using, whether it was in single player or multiplayer, what the bug is, and what you expected to happen. Remember, if we can't make the bug happen, then we can't fix it! Here's a basic example of a bug report. Operating System: Ubuntu Linux 12.04 64-bit SP/MP: SP What the problem is: Lightsabers are able to deflect rockets fired by ATSTs. What I expected to happen: I expected the Lightsaber not to deflect the rockets, and for it to hit me! If you really don't know what caused the bug to happen, try and remember the last few things you did before the bug happened, and list these in your report. How does the licensing work for mods which used the original SDK code?* If your mod was created using the original SDK code and does not depend on any additions or changes made by OpenJK, then your code remains licensed under the EULA provided with the SDK. Your mod will still work on OpenJK! If your mod was created using the original SDK code, but does depend on any additions or changes made by OpenJK, then you will need to license all of your source code under the GNU General Public License v2. The same applies if your mod is created using the code in OpenJK. * We are not lawyers, and this cannot be considered as legal advice. This is just our understanding of the way it works. If you're really worried about it, you should get in touch with a solicitor/lawyer. Why doesn't <insert mod name here> work in OpenJK? In recent years, mods such as Movie Battles II, Jedi Knight Galaxies and Makermod have started to be more inventive with developing their mods, making use of a technique called hooking. This allows them to provide additional functionality which wouldn't ordinarily be possible. The downside is it relies on a specific version of the engine that to run the mod (i.e. the retail version of JA). As OpenJK is a different version of the engine, these mods will crash unless they are updated to check the engine being used. How can I contribute to OpenJK? The OpenJK GitHub project can be found over at https://github.com/JACoders/OpenJK. Although OpenJK is purely a source code project, that doesn't mean you have to be able to code to contribute. Here are ways you can help us: Reporting bugs so that we can improve usability and stability Post suggestions or ideas. We want to know what you think and what we can do to make OpenJK better. Write documentation for OpenJK - tutorials, how-tos, troubleshooting guides, anything like that which will make OpenJK easier to use. Reply to help topics in this forum. If you know how to solve someone's problem, then please do help them. If you're a programmer, you can contribute to improving the source code by tidying the code up or picking tasks off of our issues list. The best way to submit source code improvements is by making the changes in your own fork of OpenJK in a new branch, and then submitting a pull request. This lets us review your code changes, making sure it looks good and that the code style generally conforms to the rest of the code base. If everything looks good, we'll merge your changes in I can't open the console! OpenJK uses SDL as a window and input manager. A side effect of this is that on certain international keyboard formats, the original console keybind does not work correctly. As a workaround, we have implemented SHIFT+ESC as an alternative. On standard keyboard formats, the original ` (~ key) still works - the SHIFT is no longer required for this keybind. If you don't like this, you can adjust it with the cl_consoleKeys cvar.

Fixing broken stuff is good What's the problem with it? Does it simply not work, or does it give you errors?

The coop branch doesn't get updated by the master branch. Whoever decides to work on it needs to merge the changes from master into coop every so often. It's considered good practice to add new features or even just bug fixes into separate branches, and then merge these changes into master when it's done. There's two reasons for this: 1) it prevents half finished work being in the master branch - it ideally should always be a complete working copy of the code, though this isn't always the case. 2) It makes removing these changes very easy and you can simply diff with the branch, and then undo the changes made by that branch. EDIT: We have a new shiny OpenJK subforum, so any OpenJK talk can go there *hint hint, staff please move this? *