eezstreet

it would emulate bump mapping

Not even. Emboss is just the equivalent of doing an Emboss filter in Photoshop.

I hear the lead coder over at JKG has some sort of Parallax Mapping one though, which is sorta similar I guess.

Coding would be useful, especially for Mac ports.

PS3 Controller support added.

Note that you need to change the default configuration in MotionInJoy around a little bit.

You need to change Axis Rz to "Right Stick X" and Axis Slider to "Right Stick Y" in order for it to work properly. This is because the Sixaxis tilt sensors are in place of what the Right Stick should be, and the game can't access that. The difference should be the same regardless of whether you're using Sixaxis or Dualshock (in Dualshock's case, those axes are just not used at all).

Control mapping should be virtually identical to the XBOX 360's, just with obvious name changes of the buttons.

A word of warning however: the menu navigation is still broken, and it's worse with the PS3 controller as you have to fight the controller feedback when navigating menus. It isn't too bad though.

qcommon/disablewarnings.h:

This line should read:

#include "../qcommon/disablewarnings.h"

windows.h

This line should read:

#include <windows.h>

Make sure they're typed like that.

4096 PK3s appears to be the limit in Quake 3. It wouldn't surprise me if the limit in JA is higher.

Porno.

Oh wait, we're talking about JKA/2...

Still porno.

(inb4 someone takes me seriously)

Part of the mod itself is the cut content (cut SP mission and cut MP map), so I suppose you're referring to the code changes. As for those, they may or may not impact the balance of JA negatively. All I can conclusively say is that porting it to JKA or earlier versions of JK2 isn't going to be a totally difficult task, all things considered. Mostly just annoying and time consuming.

I still haven't gotten an email from MotionInJoy yet, in case you're wondering. Been a day or two I think.

These are particularly complex tasks for a beginner, so take note of this.

Assuming you want the Dual Wielding bits first, here's some things I can recommend.

If you're going for only one or two weapons to be dual-wieldable, and assuming you don't want that to be too interchangeable (unlike say Gunslinger's Academy), then this isn't too bad to do, but it involves some rather complex knowledge of the way the engine works.

The game networks stuff about the current player in the use of the player state (playerState_t). On the client, you only have access to (emphasis on only) your player state. The server has information about all the clients' player state. Each player state is stored in their gclient_t variable, which is in turn part of their gentity_t variable. This makes sense because: a player is a controlled entity (/ client), and it's an entity (gentity_t). In most functions that you find in the server when you're dealing with an entity, you'll find those in function parameters as simply ent. So the easiest way to access variables is simply:

ent->client->ps.*

You'll find a lot of useful information here, such as what weapon the player has currently equipped (ps.weapon), what weapons they have (ps.stats[sTAT_WEAPONS]), what ammo they have (for instance, ps.ammo[AMMO_BLASTER]), and so on.

So how do we access this on the client?

We have two different options. They're slightly different in terms of how they're managed, so it's important to understand the concept of prediction and snapshots.

Quake 3 (and therefore, JA MP) sends stuff to the clients in the form of snapshots. Each snapshot contains all the entity states (not important atm for what you're dealing with) and your player state, as well as the server time for calculations, and some other things. The current snapshot is stored in:

cg.snap

And to access the current snapshot's playerstate, we use:

cg.snap->ps

So that's one option that you have at your disposal.

The other one involves a little-understood concept called prediction. Prediction involves processing the snapshots and predicting what will occur from them. Prediction results in smoother animations, and rounded out sleekness that would otherwise not be possible with networking alone.

Consider points on a graph. Each snapshot would be considered a point on a graph, and if we were to simply use the points on a graph, without anything else taken into account, this would be perfectly fine. But as with all aspects of life, there are tons of little complications. For instance, lag. Lag will be a problem, since it will delay what information gets sent to the client. This is already a problem, as it throws off the whole formula for prediction (I won't bore you more than I probably already am with tons of mathematical equations, and I don't totally understand the method behind it myself anyway). There's also a pretty gaping flaw here: the clients run on a different frame rate than the server does (as to be expected, since different clients run different machines, but also take into account that servers are usually capped at around 20-30 FPS, while clients can go as high as 120, if not more!)

In my humble opinion, you should be dealing with the raw snapshots in this case, as there's physically no real need for prediction. So that means that you'll be dealing with cg.snap->ps, on the client.

Again, why does this all matter? Well, what you're basically going to probably want to do here is store some kind of value on the playerState that tells you whether or not you're currently dual wielding your current weapon. That's about the simplest way to do it. Since all the fields in the playerstate are more or less hardcoded, there's a few extra fields at the end of the playerState and entityState that Rich Whitehouse was kind enough to program into the game. You can do some complex stuff with these fields later on, as with the rest of the playerstate, that allows you to add more fields, but I won't get into that right now, as that also involves some complicated math.

Anyway, you'll be wanting to deal with the userInts. So I recommend changing:

int userInt1;

(in q_shared.h)

to

qboolean currentlyDualWielding;

For clarity's sake anyway. Your next task would be to figure out how and when you want to set your stuff to be currently dual wielding. I'll leave this info here, as I feel like I've posted way too much information anyway. If you read all this, and understood all that, congratulations, you win one free eezstreet point, redeemable at any time for more free advice.*

*Additional restrictions may apply to residents of Hawaii and Alaska, because fuck islands and fuck cold

I'm not sure what it is that you're asking me to port here :!:

If you're talking about porting the JK2 campaign to JKA, I don't think our contacts at Raven would much appreciate that, but I don't really know as I haven't asked them specifically. If you're talking about the features, as in the controller adjustments, that's all a simple hook and really a minor thing in comparison to the others. Anyway, I highly recommend JK2, as the story itself is fairly good, and honestly the best in the series when it comes to story (sans characterization, which DF1 did best imo). Gameplay is also better in my opinion, as it isn't riddled with special moves and silly gimmicks.

Impressive work, though I am curious...

"Raven helped us to make this mod in various indirect ways."

 

Who is us?

That information is classified. Whoever has worked on this will come out of the woodwork and proclaim that they've worked on it. I only say this because at least one of the people involved asked that I keep their information anonymous in some form or another.

I've always believed in going native or going home. But yeah, I'll let you know if that goes any farther. I couldn't get the PS3 controller to work on MP because DirectInput simply refused to work. But, we'll see.

Is this your JK2 Uncut mod?

No. Well, sort of.

Optimized for controllers how? I've been using a PS3 controller for JO and JA forever since I originally owned them on consoles but could never get used to mouse and keyboard for saber fighting. The main thing that was missing was joystick sensetivity. The game treats up, down, left and right as buttons, leaving out diagonals. If you could get full functionality with a program like MotionJoy that would be awesome.

Yes, precisely. I've been spending some time with XInput -- the API for XBOX 360 controllers. Essentially what I did was what you mentioned -> the game now treats the sticks properly, and doesn't treat them like buttons anymore. This functionality so far is restricted to XInput, but I've been working on contacting the MotionInJoy developers (I own a PS3 controller, XBOX 360 controller, and Wii controller, which I use for various...hacks) to see if they could offer some assistance for the PS3 controller support.

Unfortunately this comes with a restriction attached for the XInput devices. You can't change the button layout for them via the menus unfortunately. I've rebound the buttons to be more sensible than the XBOX/Gamecube interface after extensive playtesting with the controller. One of the things I'd like to implement is aim assist, as it's a bit challenging to aim atm (and JK2 had aim assist on the consoles anyway, so consistency++), and rumble via the onboard Force Feedback stuff that JK2 has built into the singleplayer aspect.

Interestingly enough, this only required slight modifications to the JKG joystick controls in order to implement properly.

On the TODO list:

• Assign Y to be an instant lightsaber switch-to button when using guns, and make it into a stance change button when in saber
• Assign left and right shoulder buttons to be force power selection when in sabers (currently they're assigned to Lean, which I will be tweaking also to be more useful)
• Improve the animations. Right now, the animations play at the same speed regardless of your movement, which looks a bit silly in some circumstances (like barely moving the sticks at all)
• Rumble
• Aim Assist
• Adjust threshold via menu (it's a static limit of about 15% input required on both left and right sticks for input to take place)

But yeah, I gotta upload some sort of gameplay footage of me playing with this, so you can get a better idea as to what's changed. Generally it plays a LOT better now and the joystick option is actually quite viable, if not my preferred method of playing now, because it's such a contextual interface.

Only one downside to all of this though is that there's absolutely no way to control menus at all with this. Sorry You'll need to use the mouse in order to navigate the menus.

All that I can definitively confirm:

• Everything you see and hear is heavily WIP.
• This is all for JK2, SP versions 1.03 and 1.04.
• It involves reverse engineering.
• The game has been optimized to run on controllers. XBOX 360 and Playstation 3 controller support added.
• Inspirations are drawn from mods such as Brutal Doom, FakeFactory, and sikkmod.
• QEffects is used, with modifications.
• Several balance modifications were made, and several new features are added, as well as continuity fixes to the main game.
• The mod contains a singleplayer mission which was originally cut from Jedi Knight 2. It was restored and improved upon from the original source files that we received.
• The mod contains a multiplayer map that was originally cut from Jedi Knight 2, with missing textures replaced and several errors fixed.
• Raven helped us to make this mod in various indirect ways.

Is there an entry fee?

The easiest way I've found to do ent modding is to decompile the original BSP, rename the .map file to be the same name as the .bsp, modify the .map to your liking (only editing ents...triggers and doors cannot be added/edited, unless you're cloning an existing one!), and then do an -onlyents compile, using the .map file as the .ent file (no need to rename). It is by far the easiest way to map mod efficiently.

Change all references in the SDK of "powf" to "q_powf" <- this usually fixes it.

Any errors in the output? Have you searched EVERYWHERE for the DLL?

Those chicks you mentioned are just famous white chicks, Jan is asian.

 

Linda Park would be more fitting.

You're correct in this regard, yes.

I suppose you're right @@Scooper. I do have those macros and functions in the proxy DLL thing that dusty is referring to, however

I want to write up a proper guide at some point for reverse engineering SP properly.

I'm polling the people of JKHub about what sort of screen resolutions they use for their monitors. So far, I've heard of the following being used:

800x600

1024x768

1280x1024

1280x720

1440x900

1600x1200

1680x1050

1920x1080

Do you use a different monitor resolution than what is displayed here? If so, let me know. Also, wouldn't hurt to mention if you use those resolutions, since I want to know how popular they are as well.

I personally use 1440x900.

Newp. Not really. Leela Civilian is on the right track though. Needs the gear that Jan has (goggles and gloves) and a different face.

I heard @@Inyri makes nice female models and loves me a lot.

Also, I'm looking for a particular model. You know how much love there is out there for Kyle and not a whole lot for Jan? Yeah...

I've been really looking into these enhancement mods that are out there for various games, notably Brutal Doom (DOOM, DOOM II, Final DOOM), sikkmod (Prey, DOOM III, Quake 4), and FakeFactory (Half Life 2). I've been thinking about making one of my own, but there's something that's really been bugging me.

...those fucking player models.

The one thing I never understood about JK2 is why Jan's model is so...well...clearly unrealistic for starters. Her badonkadonk is as large as the moon, yet I have absolutely no difference in gravity when I get near it ingame. It's not physically possible for someone to be shaped like that, I'm telling ya! I'm almost certain that she must be a mutant also, because her hair and face is well..not really hair or a face. This is a travesty, I tell ya!

So I've been looking at what FakeFactory has done with player models. While I don't expect to get near the fidelity of the FakeFactory stuff, Mars Marshall has proven that it's possible to get models for females which don't look absurd:

http://jediknight3.filefront.com/screenshots/File/43467/1

With that in mind, if this were to be done, I have some criteria that I'd like to see met:

- Works with JK2 rigging (plays in  both JK2 and JKA)

- Has facial rigging

I don't have any real requests in terms of look. Feel free to go a bit crazy. I'd suggest a likeness to Olivia Munn or Olivia Wilde, since those both (in my opinion) seem like a good fit in terms of facial likeness. If you could make two different outfits, that'd be great, but not recommended. (I'm thinking one for Artus/Kejim/End, and one for Doomgiver/Yavin Arrival)

I don't expect this to be fulfilled, but if it is, you will bring great honor upon your family make me very happy indeed.

You still need to know how assembly code works in order to use my "tools" (it's actually mostly just a proxy). They are not a substitute for an SDK, nor are they a magic wand. It's merely a proxy with a set of plugins that can be turned on/off. I had to eventually abandon it because plugin discovery wasn't working properly. Your best bet is to talk to Mr. Wonko, since he's the last known person that I know of that dealt with this.

As far as toughness goes..I'd say it's fairly tough. I'm only just doing some basic memory patches now to change damages and fiddle around with a few things (making repeater spread vary based on standing/crouched/moving, et al). Even just that gets a bit sensitive sometimes, and I often have to use 3-5 different programming tools at the same time in order to solve problems (IDA Pro + Hex Rays plugin = not free, but well worth the money if you know what you're doing; OllyDBG for debugging; Microsoft Visual C++ for the code compilation; the list goes on). When it comes to the code you've written, I wouldn't say it's exactly easy to do, perhaps not even on an MP level (from my standpoint anyway, simply because the only code involving sabers was my more or less from-scratch creation of JKG's saber system). That's subjective though.

Basically, if you have no idea how to program for the MP code, you're better off not trying to start SP until a SP SDK is being released, since code edits are honestly about 20x harder once you introduce the factor of reverse engineering into the mix. I recommend doing these kind of code edits on an MP testbed to see what exactly you need to inject, and then rewrite this in either an ASM naked function wrapper hook (which is probably the easiest way, as BobaFett tells me) or a naked function that contains only ASM. Either way, you're going to have to get your hands dirty.

Though I will admit, not all changes involve hooks. If you want to change one line of code, say:

200C2C8F                 mov     [esp+50h+damage], 2Dh   ; Damage for bowcaster = 0x2D = 45

You could patch this using some code similar to this:

// note: unlockmemory and lockmemory are pseudocode, I can't give out code to these functions directly
UnlockMemory( DLLA(jagamex86, 0xC2CBE), 1);                // most memory is read-only. If you don't set the memory as being writeable, you'll get a shutdown with a console box saying "writing to inaccessible memory"
*((unsigned char*)0xC2CBE) = 75; // let's up the base damage to 75 
LockMemory( DLLA(jagamex86, 0xC2CBE), 1);

DLLA is a nice little macro I invented that accounts for ASLR and prevents random crashes.

..wait, why am I going off on a tangent.

1:19AM, fock you need coffee

Beats me. It's referenced in JK2 and in JKA.

But you wanna know what else is referenced in JKA and in JK2? Howlers.

As it turns out, howlers have mostly functional AI in JK2. They don't do their howling bit, and only their death sounds work. However they're a lot more deadly because of it in all reality, because they don't just sit and spam the howl all the time. They're more like rapid charging enemies once it comes right down to it. They just need a lot more speed to really become volatile.

EDIT: As it turns out, their sounds DO work. Just have to rename animevents.cfg -> animsounds.cfg and change a few things around.

If you've been snooping around the files for a while, you might have noticed that there's a few interesting sound effects: overchargeend.wav, overchargeloop.wav, overchargefast.wav, and overchargeslow.wav. While no references exist in multiplayer, I've been able to figure out what it is that these were originally used for. A few small references in singleplayer indicate that this was originally supposed to be some sort of damage doubling powerup. The powerup in fact doesn't work and I have no idea how the mechanic was supposed to work, but there are a few small references to it in SP. The sounds for it are still loaded by the game, despite not being used.