eezstreet

Releasing this wallpaper before I feel bad for myself at trying my hand at Photoshop. Yes, I'm really quite terrible at it.

Hard. The controls are already terrible on FPSes, adding lightsaber combat would be too much. Plus I hate Objective C. Also we don't have the engine source, which is required. Would need the Mac computer required, + the SDK which runs for several thousand dollars total I believe. Nothx.

Wine isn't a porting program, its a Windows emulator. As such, it doesn't work properly for all apps. Sorta like how the Xbox 360 can't run all Xbox games (it uses an emulator). At any rate, @@Xycaleth did write a nice GLM viewer for windows that could be ported. Mac ports of JAMod/ProxyDLL/whatever is something I've been wanting to do. IDA can load Mac modules and bins, so the reverse engineering aspect should just involve porting some crap.

First unofficial beta sent to select people, with goodies/incentives for downloading.

Bumpmapping would only be relevant if JK2 actually had dynamic lights outside of sabers/entities. Otherwise, it's irrelevant and Mace's tut does exactly the same thing as what bumpmapping can help you achieve.

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.

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.

No. Well, sort of. 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 saberAssign 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)RumbleAim AssistAdjust 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?

You're correct in this regard, yes.