Raz0r

Stop comparing visuals. Client visuals do not match 1:1 what is simulated on the server. This is especially true across mods. I'd be curious as to what happens on JA++, I did normalise a bunch of things like this when allowing client visual overrides. Can't check into this too much atm, at work. Tags on the saber model and rhand on the player model are both important. Inconsistent results generally means an unreliable test. Recording a demo of an unreliable test does not make it reliable.

That would not fix it. That variable is only ever used for printing your current scale on /modelscale. It's not used for setting the scale.

If you were indeed playing on a JA+ server, then the client-side code part (cgamex86.dll) of JA+ was not being loaded. Make sure you followed the installation instructions to the letter, and launch with +set fs_game "japlus" Can't offer much more help than that, the mod works when installed properly and there really isn't much that would prevent cgamex86.dll from being loaded.

I can't imagine this being specific to OS or hardware. There must be an ingame contributing factor. I wonder if using a lower framerate would affect this drastically :^) @@eezstreet can you spot anything funky in the seeker spawn/think code? (JO)

It belongs on the server in the same folder structure as in the repo. japlus/lua/sv/modelscale/plugin.lua - no clients need to download it at all. It doesn't have to be inside a .pk3 (but it can be) It will read a file named modelscale.cfg inside the japlus folder: sample After that you can enable japp_modelScaleCmd 1 on the server if you wish clients to be able to set their own modelscale with modelscale <percent> so long as percent is within the range specified by japp_modelScaleRange on the server (default is "80 120" so 100 is regular size) Using modelscale command with no argument will show your current modelscale (from .cfg or overridden) Using modelscales command (in server console) will show the list of predefined modelscales (from .cfg)

Hullo :> The only files required from the original installation are the base/assets*.pk3 files, just copy these to e.g. ~/jka/base/assets*.pk4 for our example Sounds like a fresh Debian install won't have a matching libjpeg version and it's not statically linked. You'll have to find the relevant package or compile it yourself - or compile a "universal" version that statically links it. Nice, this should install *at-least* openjk.x86_64 (replaces jamp.exe) and rd-vanilla_x86_64.so (renderer library) to the ~/jka folder. JA++ was built with the intention of being used on JA+ servers, though it obviously also works on JA++ servers. It sounds like you had the assets installed correctly, but the code portion of JA++ (~/jka/japlus/cgamex86_64.so, ~/jka/japlus/uix86_64.so) was not being loaded. I suggest scrolling back in the console for any "dlopen" or "VM_Create" errors as soon as you get past the splash screen and again when you connect to a server. I don't believe so, it sounds like your archive manager is extracting them and trying to preserve the folder structure / keeping them together. They should just be .so files next to eachother in the .zip intended to be extracted to ~/jka/japlus/ Huh ? Not having them being loaded is 100% of your JA++ issue.

You need to modify admin_strings.json in that case. Use an empty string for that entry.

Oops, seems I missed this topic. You will want to play around with japp_teleportBits. It's a bit-field with the current values: 1 = silent 2 = no slick 4 = keep velocity 8 = keep angles 16 = no telefrag Currently no cloak option, but you can use the silent option as an alternative. No immediate plans to add holstering personally. If someone else wants to add it and can do it somewhat cleanly, I'm all for it. Same for grapple hook cutting. It's just not a major feature I can invest in. There's a new website on the way (thanks to @@Sentra for doing a mockup ages ago)

Hnng. It's cg_fov

Interesting. The engine source code was only released 3 years ago

mrwonko is a pro http://mrwonko.de/blog/2010/roff-the-raven-object-file-format-reverse-engineered.html

Right, that's what I meant.

/cg_deferPlayers 0 The downside of this is that you will get shorter freezes whenever someone changes skin, connects, etc.

This has tripped up so many people. I know this because reasons and I totally have never been caught out by it...

Sure, I'll bite. Here are the most likely places such a feature was taken from: 1. Quake 3's grappling hook weapon + the numerous mods that extended it (source code available) 2. Jedimod 1.2 (source code available) 3. JA++ (source code available) And that's fine, but don't go proclaiming their god-like technical prowess without fact-checking. That's not cool. The speed of the hook can be changed.

Sounds like that will only show which processes are listening on ports, not able to show if there are any firewalls or routers allowing traffic from the interwebs. Linux equivalent would be: netstat -ntulp

What's wrong with ./openjkded.x86_64 +set dedicated "2" +set fs_game "mymod"?

+1 +10 if someone can do it in lua / let me know exactly what you need code-wise for it to be done in lua

I have the same issue with OpenJK and El Capitan. Macbook Air mid 2013 IIRC

This makes me all warm and fuzzy inside

For multiplayer, Clientthink is called whenever a packet arrives. It could be called multiple times per server frame (unless g_synchronousClients is set to 1) Only the G_RunFrame call tree is once per server frame.

Works fine for me. Probably related to a broken mod or having too many mods.

Resolution != aspect ratio. 16:9 isn't the only non-4:3 ratio

Seems to be Windows 10 specific. What a top notch OS with no issues :^)

It's still the third JKE.