MGummelt

It should be possible, with some coding, to allow this to work on NPCs because NPCs use forwardmove just like clients do (this is how a player can take over an NPC - like with vehicles like the AT-ST). You could just store the force_forwardmove on the NPC struct (NPC->force_forwardmove) and then read that later to override the NPC's ucmd->forwardmove. Much of the navigation of AI was rewritten by Chris Reed between Jedi Outcast and Jedi Academy (where you see stuff like NAV:: and STEER::, that's Chris Reed). So I'm not as intimately familiar with how it pushes the NPCs around in Jedi Academy (in SP, in MP I'm pretty sure it's all ucmds), but I'm pretty sure that NPCs still go through Pmove()? So you should be able to check the force_forwardmove in there for NPCs and override the pm->cmd.forwardmove right there at the last second... Something like this: void Pmove( pmove_t *pmove ) { . . . if ( pm->gent && pm->gent->NPC && pm->gent->NPC->force_forwardmove != 0 ) { pm->cmd.forwardmove = pm->gent->NPC->force_forwardmove; }

Well, you can just have the player "become" an NPC - like we do when you take over the droid in Jedi Outcast or when you drive a vehicle. Changing the player's size dynamically isn't really supported. You'd have to change these defines in g_client.cpp: float DEFAULT_MINS_0 = -16; float DEFAULT_MINS_1 = -16; float DEFAULT_MAXS_0 = 16; float DEFAULT_MAXS_1 = 16; float DEFAULT_PLAYER_RADIUS = sqrt((DEFAULT_MAXS_0*DEFAULT_MAXS_0) + (DEFAULT_MAXS_1*DEFAULT_MAXS_1)); vec3_t playerMins = {DEFAULT_MINS_0, DEFAULT_MINS_1, DEFAULT_MINS_2}; vec3_t playerMinsStep = {DEFAULT_MINS_0, DEFAULT_MINS_1, DEFAULT_MINS_2+STEPSIZE}; vec3_t playerMaxs = {DEFAULT_MAXS_0, DEFAULT_MAXS_1, DEFAULT_MAXS_2}; And bg_public.h: #define DEFAULT_MINS_2 -24 #define DEFAULT_MAXS_2 40// was 32, but too short for player #define CROUCH_MAXS_2 16Even then, there may be some places in code that make some assumptions about the player's size (especially their width). Height can and does vary dynamically (when you crouch and stand back up), so it should handle dynamic changes in height, but I don't know about size. Really, your best option might be to just have the player take over an NPC (the player's input just gets sent to the NPC instead of the player and the player's camera gets attached to that NPC).

Nice work! Unfortunately, I know nothing about the rendering, direct input and localization code... That's more a tech programmer's side - like James Monroe.

Sure, it's possible. First you'd need to stop passing the owner of the saber as the "ignore" entity in the lightsaber damage traces, for example (line 4175 of WP_Saber.cpp): gi.trace( &trace, ent->currentOrigin, vec3_origin, vec3_origin, mp1, ent->s.number, (MASK_SHOT&~(CONTENTS_CORPSE|CONTENTS_ITEM)) ); You can see in the definition below of the "trace" function it's calling that the 6th parameter is the "passEntityNum", which tells the trace to ignore that entity when doing the trace (pass right through it as if it's not there): void (*trace)( trace_t *results, const vec3_t start, const vec3_t mins, const vec3_t maxs, const vec3_t end, const int passEntityNum, const int contentmask , const EG2_Collision eG2TraceType = (EG2_Collision)0, const int useLod = 0); If you pass nothing there instead, it should hit the owner (pass ENTITYNUM_NONE insteadf of ent->s.number). After that, you may need to remove all the checks that try to prevent an entity from damaging itself? I don't see any offhand, but there may be some? And you'll have to do the same with places that make sure an entity (player/NPC) doesn't damage people on their own team, like here (WP_Saber.cpp, line 4186): && traceEnt->client->playerTeam != ent->client->playerTeam You'd have to do something like this: && (traceEnt->client->playerTeam != ent->client->playerTeam || traceEnt == ent ) Which would still stop you from damaging teammates, but allow you to hurt yourself. I quickly looked through G_Damage() in g_combat.cpp and I didn't see anything that should stop a player or NPC from damaging themselves, so I think it might be fine after that. So you may only need to make the above changes in WP_SaberDamageTrace() and it might work? If not, look for similar cases in the wp_saber.cpp file or lower down in the G_Damage() code.

Nothing more for defense. Nowhere in the code does it check for saber defense to be anything higher than 3. And if you try to set it higher than that on the console, it tries to clamp it at a max of 3. This is because saber defense is used in calculations that compare the relative offense/defense skill/strength of two sabers when they come together, to figure out if one should break the block of another, or parry the other one or go into a saberlock. Allowing defense to go out of range would break those calculations and cause unwanted behavior.

Ah, good to know, thanks.

3

I typed a whole, long response about what g_spskill does, but this board erased it all when it went to post it. It's been doing this to me for a month, now, in posts and DMs. After the post auto-delete, I have to edit the post and type it all again. I don't think I'll be bothering to comment here anymore until this is fixed. Here's the short version: Yes, search for the g_spskill cvar and you'll find that it ups health and a whole lot more (spawning more/different enemies, making them faster, have better reactions, do more damage, gain new abilities, etc.) I never liked the "damage sponge" approach to difficulty, it ruins the balance of the game, IMO. Specifically, look in the NPC_Begin() function in the NPC_Spawn.cpp: else if ( ent->NPC->stats.health ) // Was health supplied in NPC.cfg? { if ( ent->client->NPC_class != CLASS_REBORN && ent->client->NPC_class != CLASS_SHADOWTROOPER //&& ent->client->NPC_class != CLASS_TAVION //&& ent->client->NPC_class != CLASS_DESANN && ent->client->NPC_class != CLASS_JEDI ) {// up everyone except jedi if ( !Q_stricmp("tavion_sith_sword", ent->NPC_type ) || !Q_stricmp("tavion_scepter", ent->NPC_type ) || !Q_stricmp("kyle_boss", ent->NPC_type ) || !Q_stricmp("alora_dual", ent->NPC_type ) || !Q_stricmp("alora_boss", ent->NPC_type ) ) {//bosses are a bit different ent->NPC->stats.health = ceil((float)ent->NPC->stats.health*0.75f + ((float)ent->NPC->stats.health/4.0f*g_spskill->value)); // 75% on easy, 100% on medium, 125% on hard } else { ent->NPC->stats.health += ent->NPC->stats.health/4 * g_spskill->integer; // 100% on easy, 125% on medium, 150% on hard } } ent->max_health = client->pers.maxHealth = client->ps.stats[STAT_MAX_HEALTH] = ent->NPC->stats.health; } Note that the Reborn are not scaled - again, instead of making them just take more saber hits to kill, I made it harder to outwit and outduel them.

Well, that doesn't make any sense. MAX_SABER_VICTIMS is 16 in the vanilla code, it's not 100. I don't know what codebase you're using. It that OpenJK or something? The victimEntityNum array exists just to prevent a single saber damage check from hitting more than 16 entities in a single frame. It gets reset at the start of every call to saber damage checking (so for each blade, it's reset each frame, basically). There's no way you should be hitting that limit - if you need to raise it over 16, something is going very wrong in your code. 100 is insane, much less 600! Do you still have this bit that clears the victimEntityNum array at the top of WP_SaberDamageTrace()? void WP_SaberDamageTrace( gentity_t *ent, int saberNum, int bladeNum ) { vec3_t mp1, mp2, md1, md2, baseOld, baseNew, baseDiff, endOld, endNew, bladePointOld, bladePointNew; float tipDmgMod = 1.0f; float baseDamage; int baseDFlags = 0; qboolean hit_wall = qfalse; qboolean brokenParry = qfalse; for ( int ven = 0; ven < MAX_SABER_VICTIMS; ven++ ) { victimEntityNum[ven] = ENTITYNUM_NONE; } If not, then the victimEntityNum array could start getting filled up and it will think you already hit that ent that frame - when you really hit it some previous frame. But even that seems unlikely. Have you tried actually debug-stepping through the saber damage routine (starting at the top of WP_SaberDamageTrace) and seeing where your bad trace returns before the damage? That would be the one sure way to know what's going wrong. Also, turn on the visual saber trace lines, they can be helpful when debugging what's going on with saber traces. d_saberCombat 2 Should turn them on. I think you will need to compile a debug build for those to work though? timescale 0.1 Will slow things down enough to see the saber traces in action as you swing.

So does this only happen if you set the corpses to never remove? I had asked that earlier...

I'll have to look at the code to see if I see any issues, but I can tell you that changing the HL_NONE above to HL_MAX is not a good idea. Those lines are declaring and initializing arrays of data - basically creating an array of size MAX_G2_COLLISIONS and filling it in with blank data. By setting them to HL_MAX instead of HL_NONE, all you're doing is initializing those arrays to something other than 0, which would make the code think that every part of the array has already been filled in with a hit location, which would make it think it's out of collisions. Without looking at your code, all I can imagine is that whatever you're doing to cause hit location/dismemberment with guns is filling up this array (is MAX_G2_COLLISIONS == 20?) and somehow your code is not clearing that array for the next frame as it should. I'd look and see where those arrays are referenced and find where they are getting cleared/reset back to their default values (0, HL_NONE, HL_NONE and qfalse, respectively). That should be happening at the end or start of each frame somewhere. If those global arrays are never cleared, they will fill up and you will no longer get any more valid hitlocs or dismemberments.

Hmm, I don’t recall there being a limit to the number of dismemberments - this doesn’t happen to me when I play the Ladder map, for example - I can dismember every AI that spawns. Are you keeping the corpses or pieces around an abnormally long time? Does it stop working 100% of the time after 20 dismembered characters? If so, you should be able to debug the 21st character and see where in the code it rejects the dismemberment.

This is the correct answer. Back then, we used a height of 64 units for player height, because it divided nicely into 8 sets of 8 units each. Later games (COD, for example), players are 72 units high (because 6 feet is 72 inches, so this made a nice, neat 1 unit in radiant = 1 inch). Yes, but Kyle’s boots have a one-inch heal. Player characters are always 6 feet tall, regardless of what other sources say.

Also, in case anyone doesn't already have the Asteroids/Siege Star Destroyer official addon/mod, there is still one site that mirrors the old JK3 files website. Here's the link for the mod: http://mrwonko.de/jk3files/Jedi%20Academy/Official%20Releases/Others/23923/

Have you actually played it? I think what you're referring to is the strafing behavior. If you press left/right, your ship will juke to the left/right a bit, then recenter if you let go. It's supposed to help you dodge when someone's on your tail. Another reason we did this is because we didn't really want players to be able to easily invert themselves with a full roll (which you could put on the strafe keys instead if you want). In the movie space battles, they generally keep a consistent plane for the battle, a general up and down. For cinematic reasons and to not disorient viewers. We were trying to keep that aesthetic, make it a bit more friendly to a wider audience of players. But if you want, you can just make the strafe keys roll. In fact, if you just set the dvar bg_fighterAltControl to 1, your pitch and roll are completely unbound. So you should try that first.

DM me for more info

In bg_pmove.c, look at PM_FlyVehicleMove() That controls how vehicles move (this is run both on the server authoritatively, and on clients predictively). If you want to change how they calculate a thrust vector (wishspeed) from the player's usercmds (pml.*) apply their thrust vector to their current velocity (pm->ps->velocity), that's the function. It's important to note that player-driven vehicles are really just players using a vehicle model. Vehicles are not really separate entities - just players running vehicle "physics".

That's a pretty broad, generalized statement that could be taken a lot of ways. Do you want to do something like add momentum, make them act less like Star Wars vehicles (which behave like WWII fighter planes in an atmosphere) and more like real space vehicles would behave? Or do you just want to reduce lag and improve smoothness? Those are two very different tasks.

I'm not sure what you mean? Are the Asteroids and Star Destroyer space combat maps that we released not big enough? https://www.youtube.com/watch?v=elmOHdZOGT4 https://www.youtube.com/watch?v=ZMeiMkgK9jA How much bigger do you need to be able to make them?

A different person did the AI for the non-Jedi in Academy. Plus the map designers can script them to be stationary if they want. But, mostly, it was the new AI programmer on Jedi Academy that rewrote their AI and changed their behavior so much.

Yeah, I answered questions for about 6 weeks then stopped coming back because people stopped asking questions.

LOL! He is a little prick, isn't he? Blame the writer.

Again, totally doable. Have the force pull code pull the thrown saber to you and change the owner so that if it touches you, it gets added to your list of sabers. Might need to do some work to set the player weapons to be a dual saber user for them to catch the second saber and use it properly, but it should be doable.

This would be pretty simple to code, since you can already block a thrown saber and send it scattering away. Just have the force push code look for thrown sabers and knock them away like the saber blocking code does.

You're not talking about me, right? I offered to prove it, took a picture and everything, then everyone said not to bother and that it was obvious I was who I said I was from my answers to everyone's questions. I then I hung around for weeks answering questions - I certainly didn't "disappear" because someone asked me to prove I am who I am.