Xycaleth

It looks like that image is published using the Dockerfile from the OpenJK repo: https://github.com/JACoders/OpenJK/blob/master/Dockerfile It should be useable although we haven't tried it in a while.

I'm not sure there's much to say. Pathfinding is a means to an end and usually an NPC will have have some location that they need to reach, whether that's an explicit location (chasing a player, running into a build, investigating a sound, etc), or something implicit (a cover point, anywhere out a player's line of sight, a randomly picked location for patrolling). I'm looking into using navigation meshes instead of waypoints since it provides much better information about walkable areas compared to waypoints.

That's very strange. I'd be interested in hearing about your findings when you do make fixes

What problems do you encounter when you run OpenJK in VirtualBox? OpenJK and JKA both use OpenGL 1.2 (I think? certainly nothing GL2.0) so it should work out of the box.

OpenJK is a cleaned up/slightly modified version of the original code which was written back in 2002 which itself is built on the Quake 3 engine from 1997. C++ wasn’t so popular back then so the vast majority of the code stuck with C89. Some of the newer code written specifically for JKA is in C++ but doesn’t resemble anything you would consider “modern” by today’s standards. I would say adding/writing C++ code for the sake of writing C++ isn’t particularly useful. Unless something benefits from using C++ then there’s not really much need to do so

The red text you’re seeing is a warning. It’s safe to ignore

Does the file exist? It's referring to "C:/Program Files/GtkRadiant-1.4/q3map2/q3map2.exe"

My builds page is back up.. I did some maintenance work on my VPS a while ago and accidentally broke it. Just fixed it now. http://gandalf.acslo.com/rend2/

Looks like something went wrong with the shader parsing. Line 387 in your paste bin is actually the end of the shader. I probably forgot a null terminator somewhere. Thanks for the PR. There's a lot of things I disagree with there unfortunately, but I'll comment on it GitHub

I second ensiform here. GLDirect should only be used as a last resort (e.g. your computer is over 10 years old or something) otherwise you might have other issues. Can you post your hardware specs? JKA always reports players using P4 processor since it doesn't recognise the newer ones. Updating your graphics drivers should fix the problem better without any of the glitches you're seeing now.

Do you have graphics drivers installed? Have you tried using OpenJK?

@@AshuraDX I don't have time to go through the code right now to see exactly what it does, but this is the function that saves the .wnt file: https://github.com/JACoders/OpenJK/blob/master/codemp/game/ai_wpnav.c#L2384 And for loading (maybe one is easier to read than the other): https://github.com/JACoders/OpenJK/blob/master/codemp/game/ai_wpnav.c#L2019 Flags are here: https://github.com/JACoders/OpenJK/blob/master/codemp/game/ai_main.h#L41-L57 And looks like the data between the { } should be points that bots can force jump to (or something related to force jump).

That looks pretty wrong! Parts of the shader are missing, looking at the log. Where did you download rend2 from or did you compile it yourself?

r_dynamicLight, ent has already explained. I don't know for sure how the r_dynamicGlow cvars are used, but I do know how dynamic glow works so here's my educated guess: Any models with shader stage that has a "glow" keyword will have it's glowy portions rendered again to an off-screen image. I think r_dynamicGlowWidth and r_dynamicGlowHeight control the size of this off-screen image. Once all the glowy stages are rendered, you blur the off-screen image a few times. r_dynamicGlowPasses controls how many times, and r_dynamicGlowDelta controls how much to blur. Finally, you blend this off-screen image with what you have on the screen. r_dynamicGlowIntensity controls how strongly to blend and r_dynamicGlowSoft controls the type of blend. Like ent said, if you load a map with cheats on you can see how each of the cvars affects the size of the glow, and the quality. You don't need to run vid_restart after changing each one (except for r_dynamicGlowWidth and r_dynamicGlowHeight maybe?), they'll take effect immediately.

_minlight ?

It's less 'finding' the source code, and more 'acquiring' it from someone (Robophred). He might have given the code out to some people, but I don't think it's publicly available.

Lugormod would need to be compiled to run on an rpi. Without the source code for Lugormod, it won’t be possible to do this.

It’s the same for the vanilla (original) renderer. The codebases were developed separately at Raven so the SP and MP codebases diverged. I don’t think it will be possible to merge the two without breaking compatibility in some form...

Hi! I think many people have proposed using an existing rendering engine to fit into JKA. Personally I would choose the bgfx renderer if I were to do this. Someone else has already made some progress with this for ioq3. There's two problems though: 1. there's a lot of weird things that the Q3 engine does which would still need to be supported by a new renderer, whether or not it's hand-built or uses an existing rendering engine, 2. there's nobody who wants to take on the task Being 'Open Source' doesn't automatically mean you can start using code from another project. Doom 3 code is released with a license which is incompatible with OpenJK which means we can't use, or even write code which is based on, D3 code.

Ghoul 2 already uses skeletal animations o.O

Latest build at http://gandalf.acslo.com/rend2/b49/ should work with the latest (working) OpenJK build now... I think. If someone would like to be my guinea pig it would be much appreciated (food not included)!

@@DT85: he’s on Linux so there’s nothing to compare against @@SomaZ: x64 binaries should work fine! Even on Windows - it’s just that you don’t have access to any mods if you use the 64 bit binaries.

This is interesting - OpenJK only supports the OpenGL graphics API, but your Linux distro is providing the OpenGL ES API (similar name, but not compatible). Maybe you haven't installed the OpenGL library? Try installing the libgl-mesa-glx package and see if that helps.

I'm wondering if there's a way for you guys to create a single C++ library which each of the plugins can pull in to do what you want, instead of replicating essentially the same functionality across multiple plugins. For Blender you could write a Python wrapper around the C++ library. Just food for thought. I think you can save a lot of effort that way but it would take a bit more programming know-how.