Cerez

Just thoroughly tested it in-game -- it works flawlessly in both SP and MP (even on joined servers). If only we had a longer turn animation to inject, it would be ideal. But it works beautifully just as is. I've cleaned it up a bit, just to keep things unaffected on all fronts (user setups): "-speed ; cl_yawspeed -7200 ; com_maxfps 40 ; wait 2 ; +left ; wait 2 ; -left ; reset com_maxfps ; reset cl_yawspeed" Bind it to a key, (then assign that key to a gamepad button) and voila!

Champion!

"I'm no Jedi. But you want a worthy adversary... I'll give you a worthy adversary!" <3 Love the 3rd and 4th ones. The ending theme of the 4th is brilliant -- IMHO that's what Rogue One should have been. (Brave, beaten individual vs. a greater power. The message: you don't need to be a superhero, you don't even need to be flawless to be strong.)

Not if done right. A quickturn by its definition is a really quick (we're talking a fraction of a second) animation/move to spin you around, and cause you to face the opposite direction. You don't lose mouselook in the process. It's practically a flip of the camera -- in a similar way to how it happens when the character jumps overhead and over a fixed camera/perspective in the game -- accompanied by a very short animation that doesn't obstruct mobility. I really don't see how turning completely around using the mouse can be any faster, more visually pleasing, or more effective.

I was playing around with the CVARs today, and I came across an interesting feature: a setting that allows characters and objects to stand out from the background more, to your liking. For any Clone Wars and/or Rebels fan, or any old-school type gamer, who prefers a clear contrast between graphic elements on the screen, this hidden setting is a welcome change in visual perspective. You'll see what I mean... Stick this line into your autoexec.cfg (for SP): //Enhance Character/Object Contrast set r_ambientScale 1.3You can tweak the value. The higher, the less the characters and objects will be affected by the map's darkness/lighting, and the more they will stand out in comparison to the terrain details. Around 1.3 seems to be the middle value where they are still visually similar to the background, but independent enough to be highlighted, to stand out. Unfortunately, it only seems to work for SP, as in MP this setting seems to be hardcoded, and overwritten by the default value at game load. You can still use it in MP as well (by directly entering it into the console) if cheats are enabled. Feel free to upload and post a screenshot here of the look of your chosen personal settings if you've found this discovery useful! <3 Enjoy!

It's pretty common in FPS games that allow for 3rd person as well as 1st person view. For some reason, the same as @@Ramikad, I can't think of any right now other than the Resident Evil series -- did Dead Space have it? Or Ghostbusters? But they're out there, and, what's more important, there is a lot of discussion around the net about more FPS games needing to have this 180 degree turn feature (all we need is Google). There are a lot of players who dislike having to use extremely high sensitivity on their mice (to be able to quickly turn 180 with the mouse), are bothered by the spinning visuals of the constant turning, and/or would just prefer a more free and natural movement in the game. A 180 turn that's coded/scripted can be executed a lot more gracefully than when you have to rely on the mouse to "simulate" the quick turn as well as to aim. It also makes aiming more effective because of the lack of disorientation (allowing for better split-second focus). After all, if you were out on a mission by yourself, and had to watch your own back, to spin back with your body like this if you expected an attack from behind would be a frequent natural movement. It surprises me that most FPS gaming mechanics in today's big titles are still so old-school not to have thought of enhancing the gameplay experience with this feature. @@ensiform, I think you can see from what I've said here that this is not a gamepad-only use feature. Is there a technical reason we cannot code the already existing animation into the game to try to develop this feature in a fork? I don't see why it would be a visual problem in MP if the animation it is referencing already exists in all releases of the game, or why it would have anything messy to do with the existing save method/files in SP.

I'm not just paranoid, I'm traumatised! Instead of facing me, these bots keep running around me and attacking my behind! When playing JKA with a gamepad (with reduced/realistic turn sensitivity), as well as for a more natural feel FPS experience, a feature like this would come in mighty handy. What I'm thinking is something like what @@Xycaleth mentioned there is an unused animation for in JKA: a way for the player to realistically spin/turn back, as you would in real life, if you feel that an attack may be coming from behind. (No one likes to get spanked by strangers... )

Just wondering, has anyone ever worked on implementing a quick turn feature to JKA/OpenJK (that spins the player around 180 degrees at the press of a button)?

With entity modding you can, yes. You can change both worldspawn and local music/sound triggers to something different. But you will need to build the mod for OpenJK instead of the retail game (unless you want to have to hex edit).

I seem to remember having seen one on JK3Files. Perhaps check one of the mirrors just to make sure.

My advice would be to form the fingers in full, even if they have to be submerged in the mesh of the sleeves (covered by it). That way you'll get a nice, natural feel for the hand movement. But you *will* get some clipping of the sleeve with the lightsaber hilt the hand is holding. I don't think it's that much of a problem, though. About that much clipping is pretty standard in this game, and for the most part unavoidable. I think a good idea would be to (partially) weight the part of the sleeve that corresponds to the finger movement to the finger bones, so that it moves when the hand closes -- like having a hoodie's sleeve over your hand.

Looking great so far. I suggest you import any already released JKA model into Blender, and have a close look at how the hands have been formed. It should help you gain confidence, and give you ideas in how to approach it. It's a little challenging, but it's not that difficult in truth. The difficulty mostly comes from having to form/align the fingers to the JKA skeletal bone positions. Lucky for you, there are not that many bones in the hand for the JKA skeleton. I've found this video helpful in giving me confidence: The same thing applies to weighting it, later: open a few already done models, and have a look at what's been done to them -- the best way to learn the quirks of it.

Great choice for a first/early character model, @@Luckxzs.

Another source code (and scripting) related question comes to mind: Is it possible to set and retrieve values from CVARs in ICARUS? The following code snippet crashes the game when retrieving the value from cvar_sex (the player is female to start with): declare( STRING, "playergen" ); if ( get(STRING, "cvar_sex") = "m" ) { set( "cvar_sex", get(STRING, "playergen") ); free( "playergen" ); } else { set( "playergen", get(STRING, "cvar_sex") ); set( "cvar_sex", "m" ); }

Just copy the provided openjk.pk3 to ~/Documents/My Games/OpenJK/[modname], and you won't have any more crashes. (The reason it crashes is because it is trying to use the old base JA DLLs that have been copied there, or that the mod came with.)

It certainly does! Thank you so much! I think I know what happened, now -- it's alarmingly simple: My script is set to wait for the "casualwalk" task to finish. This is fine for when a character is moving to a navgoal, but what if he's already at the navgoal he's supposed to go to? That means the "casualwalk" task never returns the finished state, and my script is kept hanging in a wait. Hence why my character randomly stopped after reaching a navgoal, and didn't ever move again -- regardless of how much time passed. It was waiting to reach a navgoal it was already at, and never going to reach walking to (technically speaking). The fix is to make sure that every time a different navgoal is picked by the random script, and never the same one.

https://github.com/JACoders/OpenJK/wiki/Compilation-guide Not sure what was done to the source since December 2015, but I've been using a custom build based on that source for years now, and I have nothing to complain about -- it's as stable as the original game: https://www.dropbox.com/s/7bz6a1szn1w36j5/OpenJK-Cerez-Dec-2015.zip?dl=0 If you ask me, it should have gone stable years ago, but I'm not deeply involved in the development... Anyway, if you follow the guide in the wiki, it's quite simple to compile the source and build for Windows. Just make sure your version of MS Visual Studio matches the time the source is from (i.e. it is the version/year before it).

But what about her personal experiences with Kyle? Surely she'd trust a student of Kyle (and Luke) -- this much at least? Or is this plot better suited to Jan?

Sometime shortly after the mission on Hoth: "Hi Jaden, this is Mara. Kyle's told me about your heroics. I need you to assist me in the retrieval of some crucial data from a small, Imperial cruiser. Are you up for the task?" If accepted: "Alright. Hopefully we won't attract too much attention..." Otherwise: 'Return to the academy.' That's all there needed to be -- just one level! P.S. I'm entertaining the thought of creating it (modding it in). (Adding Jan in would be a little more difficult... -- because of the voiceover...)

I believe that's a spaceship...

They've got to be the scariest looking alien species in Star Wars. Even with the human limbs, this character terrifies me...

Why not have his bottom arms folded? He's too good for you to have to need to use 4 arms -- he can take you on with just two. (Goes with his character. )

@@MGummelt, I do have a specific question regarding the NPC waypointing system and ICARUS -- if you can help shed any light on this long bugging mystery: Discussion thread: https://jkhub.org/topic/6594-walking-an-npc/ When assigning 3 waypoints, and giving an NPC the task of randomly walking between them in an endless loop, the walking behaviour sporadically breaks, with the NPC either changing direction midway, or walking to a waypoint, and then stopping. What are the requirements for an NPC to be able to pick and follow a set of waypoints reliably? Do the waypoints need to be daisy chained ("targeted") to one another, or is it enough to define the movement behaviour in script? Do there need to be physical brushes (not just entities) for the waypoints? How does the waypointing system work (with ICARUS)? Related, is there any way to increase the distance that NPCs are able to see waypoints from? The default distance seems to be rather short/limited. On a side note (as trivia), who programmed ICARUS, and what language(s), if any, were used as the basis for it?