Xycaleth

Probably a fresh new team. I think everyone that was working on it has just lost interest in it now.

I had an idea about starting another "JK series" type thing but with there not being enough hours in the day, and not wanting to feel like a potato sitting at home all day, I never got round to starting it. It should help determine if anyone's interested a little better. Get the ball rolling by creating one map. This will help in a lot of ways: it would introduce the player into a new story line, give you a better idea of just how much work goes into just creating a single map with well thought out story line, game play, level design (i.e. pacing, map flow), texturing, coding (if any), sound effects, weapons and so on. If you find you're unable to get anyone to do one of those development "areas", then you're unlikely to be able to complete an entire series. But what you do get out of it is hopefully a good looking map which you can put up for multiplayer - the level design probably won't be quite right for multiplayer, but it would probably be good for role players where game play isn't such an issue. If you do succeed in creating the first map, you can hopefully get more people interested by showing what you've done so far.

If your GPU is newer than 8 years old then it will be able to do dynamic glow without any problems whatsoever. What GPU do you have?

Yus, or just get people to use OpenJK :3 If people don't like the new folder structure, you could compile the 'portable' version which writes/reads files in the same way as vanilla exes.

Two ways I guess. 1) Provide a program which applies a patch to the jamp.exe file. But you'll hit the checksum problem like @@ensiform mentioned. 2) Provide a program to launch jamp.exe, and then patch the exe at runtime.

Antialiasing has nothing to do with OpenJK or JKA. It'll be a setting in your graphics card control panel.

I'd disagree actually. JKG had an abundance of all of those pillars but it still collapsed. The main pillar you need for a project of this size is a good team lead. This isn't necessarily the person who's best at a particular modding skill or the original idea man or even the person who thinks he knows the project best. It needs to be someone who can keep everyone focused on a single vision and to make sure everything is heading in the right direction. That's where all JK4 attempts have failed so far and it's a very common problem with large modding projects.

How much RAM do you have? It's not trying to use that much memory (by today's standards anyway).

The only thing texture compression saves is graphics card memory usage. You can get roughly 75% savings in most cases.

That's probably the worst way to deal with it. I'm sure you wouldn't appreciate it if someone stranger kept trying to call you to do something Remember that they are under no obligation to even keep the server up. I'm pretty sure James is doing this out of his own time (albeit while at work).

Looks good to me except you only need to match one # at the start of the line, not two.

That's fine. We can write specific code for shaders only.

We could add support for # comments but issue a warning when it's encountered. This way you don't over-allocate and the shader remains compatible. At the end of the day, the final result is all the players see. He/she doesn't know or care about how it's done, or even if it was intentional. Rejecting shaders with # comments would be a break in compatibility which you push for a lot in other areas of the code, so I don't see any reason to break compatibility here.

Can you check that you have anisotropic filtering set to max (16)? Should be able to find it in the game menu ("more video" I think?) Can you post a screenshot of where you set the antialiasing settings in your graphics card's control panel?

If you're debugging from the terminal, you can do something like this: gdb --args ./openjo_sp.i386 +set r_mode 5 +map ffa_bespinI wouldn't set the window to fullscreen - it makes it a pain to debug then

I think there's two reasons this can happen: Could be that texture compression is messing up the colours. Can't remember the cvar for this exactly so you'll need to hunt around. Setting r_gamma too high can cause some colours to "distort".I'm going to lean towards texture compression though. You'll notice the same kind of artifacts in dark videos where it looks all blocky and the wrong colours.

I've circled stuff in the screenshot which look kind of bad. Are the red and/or purple circles what you mean @@SecretApprentice?

The fact that vanilla JKA supported # comments was a bug rather than being by design. But I agree that OpenJK should try to keep 100% compatibility with the original where it can. If nobody else is going to look at it, I'll see about actually adding the functionality in properly, but issue a warning in the console to say that your shader is potentially problematic. This probably won't be for the first release though.

That definitely sounds wrong Will have a look at it at some point unless @@redsaurus gets to it first.

Wat

Only difference I can see if that the first screenshot has antialiasing which you should be able to enable from your graphics driver's control panel.

When you compile a map with misc_models, the model data is extracted from the model file and baked into the BSP file. The game doesn't even see that there was a model there as it's all part of the map.

Ahoy! And congrats on getting engaged

The new JKA campaign of 2015. #ScooperPlz

@@Rooxon PM'd me for some help but I thought I'd copy part of my message here in case it helps anyone else: The bit I didn't explain is the new shaders. I can give a quick overview here. I'll post it in the topic as well so others can read it. Rend2 supports another shader file called a .mtr file (short for material). Both the .shader files and .mtr files can use the new shader keywords, but if a .shader file and a .mtr file share the same name, then the .mtr file will be used. This let's you keep compatibility with the base renderer. For example, if you have rooxon.shader and rooxon.mtr, then rooxon.mtr will be loaded, and rooxon.shader will be ignored. Since rend2 supports normal maps, specular maps, etc, you need a way to tell the game that your texture uses these. Take a look at the example below: textures/rooxon/head { q3map_nolightmap { stage diffuseMap // This line isn't strictly necessary. The stage is "diffuseMap" if you don't specify it. map textures/rooxon/head_d rgbgen lightingDiffuseEntity } { stage normalMap map textures/rooxon/head_n } { stage specularMap map textures/rooxon/head_s } }This is a really basic example, but is usually all you will need for a character model. There's some more fancy stuff you can do with the 'shininess' of the material but that is all you should need for now. One thing to note is that the new keywords are very much likely to change at some point in the future as rend2 progresses a bit further.