Jump to content

Xycaleth

Members
  • Posts

    1,458
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    UK
  • Modding Interests
    Coder
  • Gaming Specialty
    Competitive Play
    TFFA
    Speedrunning

Recent Profile Visitors

8,582 profile views

Xycaleth's Achievements

  1. 185 downloads

    This is the original ModView provided in the Jedi Academy SDK Tools with a patch to fix gamma issues on computers with Nvidia graphics cards.
  2. 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.
  3. 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.
  4. That's very strange. I'd be interested in hearing about your findings when you do make fixes
  5. 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.
  6. 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
  7. The red text you’re seeing is a warning. It’s safe to ignore
  8. Does the file exist? It's referring to "C:/Program Files/GtkRadiant-1.4/q3map2/q3map2.exe"
  9. 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/
  10. 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
  11. 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.
  12. Do you have graphics drivers installed? Have you tried using OpenJK?
  13. @@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).
  14. 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?
  15. 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.
×
×
  • Create New...