Xycaleth

I'll have another look at it in the new year Can't get to my PC until then.

Would be good if this could be moved to the OpenJK forum *hint hint at mods* Preferably with a redirect from this forum so OP can still find it. The easiest way to get rend2 up and running is by using a prebuilt DLL. Steps are as follows: Download the VC++ 2013 Redistributable (make sure you choose x86): http://www.microsoft.com/en-gb/download/details.aspx?id=40784 Download the rend2 DLL: https://dl.dropboxusercontent.com/u/874909/rd-rend2_x86.zip Copy the DLL into your GameData/ folder. Start up OpenJK. In the console, type "/cl_renderer rd-rend2; vid_restart"If everything worked, it should all look the same in the main menu. Type "/cl_renderer" in the console again to check that rend2 is running. Commands and cvars can be found here: https://github.com/ioquake/ioq3/blob/c04d05fd8f64b62201b100d410da52e1ab3eec17/opengl2-readme.txt rend2 is based on the one in ioq3 so the readme is fairly accurate.

Right, I'm hoping to redo a lot of the code so the changes probably won't be applicable anymore.

You'll need to attach a debugger and find out why it's crashing

I'm not seeing those problems on my end :/ Have you tried clearing the cache for the website?

I've added a code comment inline. You need to add your check before the return. So, like this: if (Q_stricmp("stcommander", NPC_type) == 0) { if (NPC->client->ps.weapon == WP_NONE) { return (1 << WP_BLASTER_PISTOL); //Stormtrooper Commander should whip out his sidearm after weapon is pulled... } return (1 << WP_REPEATER); }

Sounds about right!

I believe engines these days use maps which are essentially a collection of models, with a separate collision mesh (usually a simplified version of the map). This has benefits for collision and rendering - you don't have unnecessary collision data, and your rendering can potentially be faster. Where models are used more than once, GPUs nowadays can draw them in one go, even if they are in different positions, different sizes, etc. So yes, it probably is better After a quick talk with @@Didz, caulk is still necessary for calculating vis. nodraw doesn't block visibility (from the vis stage's point of view), nor is it solid (so no collision data is generated for it). There's also nodraw_solid apparently, which is solid, but it still doesn't block visibility.

Sounds like OpenJK (which already looks at JKHub's server list in addition to Raven's).

The problem with "fixing" the crosshair is that the crosshair would no longer be where your shot would end up. You would just have a thing that shows you where the centre of your screen is.

Something for @@Didz to look at?

What do you mean by the start/end?

The Stargate and the Fallout vault door Biggest waste of time ever. But very cool nonetheless.

I think everyone who was involved can take away something from the experience. It was without a doubt a failure of sorts, which I put down mainly to bad team management and laying down goals which were attainable as being able to make an elephant fly on a duck;s back. I think we kind of backed ourselves into a corner as well by over-hyping everything, finding ourselves not being able to achieve the things we said we would due to lack of people or just because we didn't know how, and then not wanting to make JKG look bad by saying we messed up. After it all died down for about a year before the first 'alpha' release, I think that was the best chance of getting things going again. JKG had kind of dropped of people's radars, there wasn't so much pressure to get everything done, and because of that the ideas got scaled back to a manageable level. But then the ideas came back, things got out of hand, and even more people left. But nevermind It was fun while it lasted.

Blob shadows are done by the cgame module. They're completely separate from the renderer. For projected shadows (r_shadow 2) to work, it looks like you need to set the shadowPlane field on the object's refEntity_t. This is usually done in cgame as well (CG_PlayerShadow in cg_players.c) so you could do this for misc_model_ghouls as well. I'm going to guess that misc_model_ghouls are ET_GENERAL entities, so take a look perhaps at setting the shadowPlane in CG_General in cg_ents.c

Sounds like basic linking problems You're going to get those problems with any library unless you have a better understanding of what the linker does and how it searches for the .lib files.

What wouldn't? And in which case?

Could be one of two reasons I think: EFX was added to SoF2 as well, and I believe SoF2 and JK2 were being worked on in parallel. It might have been that the code for drawing the saber blade was done before the EFX code was added. They couldn't achieve the same look with EFX It does kind of make sense to do the saber blade as an EFX. The code would be a lot simpler anyway

Any "func_breakable" map entity is breakable in the way you describe. This is handled in the g_* files, but I can't remember exactly which file. Just search around for "func_breakable".

I can't remember exactly. I think it was something along the lines of: The game allocates a fixed amount of memory for each GLM surface (or model?) for when it's animating the model. Even a static GLM model has a single bone, and the animated version will look identical to the original. If you have too many vertices on a single surface (or model?), then the amount of memory that was allocated isn't enough and you get that error.

Not without extra supporting code.

That paper seems mostly irrelevant to a programmer in computer graphics. The majority of the paper talks about scene direction which is really up to the artists. Unless of course, the paper is meant for artists, in which case it's all fine and dandy

It's nowhere near finished.

How about a working renderer first

Ya