Cerez

I'll try this again.

I have a question: how does the game decide which waypoints are linked to which navgoal? At the moment is seems to be choosing them random, based on their proximity and some other, to me unknown factors. :/ This is starting to drive me insane, by the way. No matter how many waypoints I place in-between, the NPC just decides to go random and accept only certain waypoints, and ignore others. When told to go to a navgoal on the far side, it just sits there like a dumbass, ignoring all the waypoints that I've placed leading there. So frustrating!

This would be fine if simply placing two navgoal waypoints, and a connecting standard waypoint between them would be sufficient. But as it stands, the NPC requires a new waypoint every five steps, which is quite ridiculous! If I wanted to script a detailed NPC movement environment, I'd need to place thousands of these waypoints all over this room. Is there any way to increase the range of waypoint visibility for NPCs here?

Explain -- lol! How does having to place hundreds of waypoints benefit anyone? What controls the distance between waypoints sought by the NPC in the code?

@@mrwonko, is there any way to increase the range of visibility for waypoints to NPCs -- whether through ICARUS or by changing the code? It doesn't make sense to me to have to litter the map with so many waypoints. It'd be a much better course of action to increase the range of visibility for NPCs and use only as many waypoints as is absolutely necessary.

Could you elaborate on this, @@mrwonko? A waypoint network? o.O You're right! Moving the "waypoint_navgoal" closer has made it work, and the NPC walks to that point now. I wonder if there's a way to increase this programmed vision cap on them through ICARUS. I've tried applying an increased "SET_VISRANGE", but that doesn't seem to affect it.

Thanks @@therfiles. Yeah, I've tried that. It didn't seem to make a difference. I'm wondering whether "waypoint_navgoal" is an entity with a brush unknown to me... but since the NPC is responding to the location, I get the feeling that something in my script is missing. Is the NPC waypoint walking buggy in this engine? Should I be trying to move the waypoint around to a different location?

I just can't seem to get my NPC to start walking. It's even acknowledged the position of my navpoint evidently by turning and facing its direction, but for some reason it just refuses to take even a single step towards it. I don't understand. What am I missing (or doing wrong) here? affect ( "walker", FLUSH ) { set ( "SET_WEAPON", "WP_NONE" ); set ( "SET_WALKSPEED", 200 ); set ( "SET_PLAYER_TEAM", "TEAM_PLAYER" ); set ( "SET_ENEMY_TEAM", "TEAM_ENEMY" ); set ( "SET_BEHAVIOR_STATE", "BS_DEFAULT" ); set ( "SET_CHASE_ENEMIES", "true" ); set ( "SET_LOOK_FOR_ENEMIES", "true" ); set ( "SET_IGNOREALERTS", "false" ); set ( "SET_WALKING", "true" ); set ( "SET_RUNNING", "true" ); wait ( 4000.000 ); task ( "walkmofo" ) { set ( "SET_NAVGOAL", "point1" ); } dowait ( "walkmofo" ); remove ( "walkmofo" ); } { "classname" "NPC_spawner" "origin" "-430 -3442 488" "NPC_type" "luke" "spawnflags" "32" "angle" "2" "npc_targetname" "walker" } { "classname" "waypoint_navgoal" "origin" "757 -3385 488" "angle" "246" "targetname" "point1" }

The MBII one is exactly that, you big-floppy-eared baby elephant. A remake of the JO map for JA.

Eesh, Intel HD! It's making me cringe... >.<' But it should work, nonetheless...

You can easily add a spawn point with entity modding. Simply save the entities out of the BSP (search for "worldspawn" in a text editor), paste them into an ENT extension text file, and add a spawn point entity to them. Then name the ENT file the same name as the BSP, and put it in the same location. Use the latest version of OpenJK to load the map, and voila, you'll have added a working spawnpoint to an MBII map.

Have you tried removing them temporarily and seeing if the model shows up then?

http://jkhub.org/files/file/535-emperors-throne-room/ http://jkhub.org/files/file/1246-death-star-hangar-duel-jka/ Movie Battles II also has a larger Death Star map.

Also, make sure that shaders are removed for the model if you have copied them into ModView's base. Shader support is still buggy in ModView, and this could be why the model fails to display.

What happens on your rig when you try to set the custom fov, @@Paullik74? cg_fov is a client-side setting, and it shouldn't matter whether you're on a pure server or not.

Really? Without cheats active? Are you sure? Then how come he can't set it on a pure server?

My bad. I missed that part. Pure servers are asking for the retail DLL, and the retail DLL does not support changing the field of view without cheats enabled, I think. So no, I don't think this is possible. OpenJK will default to the vanilla DLLs when joining a pure server, in order to keep you connected and playing, as far as I know. Otherwise the server would drop you for not being "pure". And if I understand correctly, what @@Raz0r is saying is that when it happened in Linux that you could do this, that was an anomaly rather than the rule. The normal behaviour is that a pure server will force the client to revert to its retail library, otherwise it will drop the client.

Depending on what version of OpenJK you have, the loading priority may be set different. Try either of the following. Make sure openjk.pk3 (containing cgamex86.dll, jampgamex86.dll, and uix86.dll) is located in: 1. GameData/OpenJK/ 2. ~/Documents/My Games/OpenJK/base/ and ~/Documents/My Games/OpenJK/japlus/ (or any other MP mod if available). I've found that the second method works better for me.

Not at all, DT. Thanks for contributing to the discussion, and getting the right thought-process started for us all to track this down. Well, I'm surprised so little broke, actually, considering the extent of the rewrite. Everything else seems to be working just dandy. https://github.com/JACoders/OpenJK/commit/883109ef40022ba93363bd33e1ebe61665361e49 Hahaha! The "ugly waterfall". We'll call it that from now on. Thanks @@mrwonko.

Update: Fortunately the rest of the effects seem fine. Fire, smoke, sparks, beams, explosions, water ripples, smoke, dust all seem to be showing properly. Curiously, it seems only this one waterfall was negatively affected by the changes. It must be doing something unique.

It's definitely not this, as this is for the first waterfall on the map, which is indeed a 3D plane with this animated shader running on it. This sounds much more like it. That second waterfall looks like it's comprised of particles. Bingo! I'm pretty sure this is it. I will check the other particle-based visual effects in-game today, and let you know.

I would assume so. I think if the ENT file is present, the game will read it instead of what is in the BSP. Though it may read both with a preference on the ENT file's contents -- I'm not sure. @@ensiform?

And here I came, thinking that this was a legitimate and heartfelt request. Boy, was I wrong! I want my money back! XD Also, what makes you think you're at all desirable to me? Edit: Jokes aside, this request has been filled twice: once by Raven Software, and once by Major Clod, with an improved player model. What makes Hoar any different to these models?

True, I'm not aiming for miracles here, but within JKA's current limits. However, I will be using the extra facial expressions we've added to OpenJK, which should help with the acting somewhat. That, and the right composition, angle, framing, and animations to tell the tale.