MGummelt

Sorry, I don't really know much about the tech details of how our terrain was made. I could ask around, though.

It only works with damage from a lightsaber. In G_GetHitLocFromSurfName() inside g_combat.cpp: else if ( mod == MOD_SABER && WP_BreakSaber( ent, surfName, saberType ) ){//saber hit and broken*hitLoc = HL_HAND_RT;} You could change that to ( mod == MOD_SABER || mod == MOD_MELEE ), or add whatever other damage types you want (MOD_ = "method of damage/death"). However, I'm not sure our melee damage traces look for specific body parts as that is a more expensive trace to do. I think our melee traces (like kicks) only check to see if they hit the player/NPC's bounding box, not where on their actual model they hit. But you could change that if you want. Alternatively, you could fake it. Detect when someone has been kicked in the front when idling and use a probability to decide if the hit broke their saber (you could do a distance check between the attacker's foot bone and the victim's saber origin). Look in G_KickTrace() inside g_active.cpp. When it calls G_Damage() in there, you can check to see if you should break their saber, then call WP_BreakSaber and pass in the surfName of the saber (you can just fake the surfName by passing in "saber"). BTW, set g_debugMelee to 1 to be able to do an extended set of melee moves any time you want - kicks, punches, grapples and throws. I think you press the activate/use key and a direction at the same time?

Hmm, yeah, the way the code was written, the lightsaber's contents are disabled only when the lightsaber is turned off or when it's thrown (a thrown saber is a different entity than the one you're holding). So if the saber is on and another saber or blaster bolt hits it, it will impact it. You could set the saberent->contents = 0 whenever you're not actively blocking. But, yes, that means other lightsabers will pass through it when you're just idling.

1 - if they have into .NPC file multiple weapons example "weapon WP_CONCUSSION , weapon WP_BLASTER, i desire that NPC randomly switch between the two weapons. Give an NPC multiple weapons by listing more than one weapon in their .npc file (text file in ext_data folder). For example, the ATST: atst{playerModel atstweapon WP_ATST_MAINweapon WP_ATST_SIDE....} To make them switch, you just call NPC_ChangeWeapon( <weapon index> ), the <weapon index> being one of the weapons you set up in the .npc file.Multiple NPCs do this already, not just Boba Fett. The AT-ST does it, the Galak Mech does it, the Grenadiers do it (Gran), Snipers do it and even Stormtroopers can do it (switching between alt fire and normal fire). Like so (grenadier switching to melee if player is too close): //See if we should switch to melee attackif ( enemyDist < 16384 && (!NPC->enemy->client||NPC->enemy->client->ps.weapon != WP_SABER||(!NPC->enemy->client->ps.SaberActive())) )//128{//enemy is close and not using saberif ( NPC->client->ps.weapon == WP_THERMAL ){//grenadiertrace_t trace;gi.trace ( &trace, NPC->currentOrigin, NPC->enemy->mins, NPC->enemy->maxs, NPC->enemy->currentOrigin, NPC->s.number, NPC->enemy->clipmask );if ( !trace.allsolid && !trace.startsolid && (trace.fraction == 1.0 || trace.entityNum == NPC->enemy->s.number ) ){//I can get right to him//reset fire-timing variablesNPC_ChangeWeapon( WP_MELEE );if ( !(NPCInfo->scriptFlags&SCF_CHASE_ENEMIES) )//NPCInfo->behaviorState == BS_STAND_AND_SHOOT ){//FIXME: should we be overriding scriptFlags?NPCInfo->scriptFlags |= SCF_CHASE_ENEMIES;//NPCInfo->behaviorState = BS_HUNT_AND_KILL;}}}} You can write any logic you want to make them switch weapons. It can be random if you like. You can even do this without coding if you do it in BehavEd using the SET_WEAPON command and run your script on an AI. 2 - if they lost a weapon because gripped or dropped with force pull, they not surrender, but equip another weapon of they inventory. In NPC_Behavior.cpp, there's a function called qboolean NPC_CheckSurrender( void ). Inside there, there's a part that checks to see if an NPC's current weapon is WP_NONE. You could check to see if the NPC has another weapon they could switch to, then switch to that weapon (as I described in #1 above) instead of surrendering. This is the chunk of code I'm referring to:if ( !NPCInfo->group || (NPCInfo->group && NPCInfo->group->numGroup <= 1) ){//I'm alone but I was in a group//FIXME: surrender anyway if just melee or no weap?if ( NPC->s.weapon == WP_NONE //NPC has a weapon|| NPC->enemy == player|| (NPC->enemy->s.weapon == WP_SABER&&NPC->enemy->client&&NPC->enemy->client->ps.SaberActive())|| (NPC->enemy->NPC && NPC->enemy->NPC->group && NPC->enemy->NPC->group->numGroup > 2) ){//surrender only if have no weapon or fighting a player or jedi or if we are outnumbered at least 3 to 1 Better yet, you could change what happens when an NPC drops their weapon. In wp_saber.cpp there's a function called: void WP_DropWeapon( gentity_t *dropper, vec3_t velocity ){if ( !dropper || !dropper->client ){return;} int replaceWeap = WP_NONE;int oldWeap = dropper->s.weapon; gentity_t *weapon = TossClientItems( dropper ); if ( oldWeap == WP_THERMAL && dropper->NPC ){//Hmm, maybe all NPCs should go into melee? Not too many, though, or they mob you and look sillyreplaceWeap = WP_MELEE;}. . . } You can see there that, by default, when an NPC drops their weapon, they will set their current weapon to WP_NONE (triggering the surrender code described above). If, instead, you had them switch to their other weapon in this function, then they would not surrender. You can tell what other weapons an NPC has by looking at this: NPC->client->ps.stats[sTAT_WEAPONS] You'll need to loop through all the possible WP_ weapons and see what they own, like so: for (i=0;i< WP_NUM_WEAPONS; i++){if ( (NPC->client->ps.stats[sTAT_WEAPONS]&(1<<i)){//NPC has this weapon}} 3 - they randomly alternate main fire and alt fire. maybe using altfire if player are far, and main fire if is relatively near. Sure, just look at the example for the Grenadier I gave in #1 above - that's exactly what they do to decide if they should use the thermals or melee. AT-STs and Galak Mech also have logic for switching weapons based on various conditions. 4 - optionally if you try to kill they with a saber or shoot to themself, they act like boba, so they try to dodge the saber, or jump, or rools, or flee. This is a bit trickier, but not impossible. You'll probably want to copy some of the evasive logic/functions from the AI_BobaFett.cpp for your new AI (or the AI you want to add this too) and it should work. Most of that logic is in here: Boba_StopKnockdown() What that does is make Boba input the same commands a player uses to dodge, roll and flip (all the AI move the same way the player does - this is why a player can take over any NPC - they're all driven by the same input commands. AI just simulate them). So a jump + direction will do a flip, a duck + direction will do a roll, etc. Hope this helps and good luck!

Sure, fine by me. I was going to upload a photo to this thread as proof, but I can't for the life of me figure out where this board lets me upload to "my media". And I don't want to upload a personal photo like that to an outside site.

No, I added fully flyable vehicles to Jedi Academy completely on my own, just because I thought it would be fun. That lead to the Asteroids and Star Destroyer Siege MP modes/maps that we released post-launch. This is going to require a long, involved answer. I'll have to respond to this later tonight, but I will try to respond.

No, we actually finished Jedi Outcast in 10 months. Academy took 14 months. The reason for Academy's story was: 1) we didn't want to start Kyle without powers again 2) we wanted to give players choice, a more interactive story Story-wise, it probably would have been better to just tell another Katarn story and let him start with all his powers, then maybe introduce the new ones and the new saber styles. That probably would have been enough progression. There may have been other story ideas, but none that I can remember now. I could ask the project lead.

Thanks! Yeah, I worked on Jedi Outcast and Academy. On Outcast I designed and programmed the light saber combat, force powers and Jedi/Reborn AI. On Academy, I added the dual sabers, saber staff, new Force powers and dark Jedi, flyable/drivable vehicles and worked on MP. I also worked on the Melee mod, Asteroids mod, the Siege mode and the ladder map. @@Boothand, lot to reply to and late here. I'll reply tomorrow.

You're right, it only breaks the lightsaber if: 1) The .saber ext_data file specifies a "brokensaber" for the saber you hit AND 2) They're not in a transition animation or in the middle of an attack AND 3) You hit their lightsaber model If all are true, it's 100% from WP_BreakSaber(): if ( !ent->client->ps.saber[0].brokenSaber1 ) {//not breakable into another type of saber return qfalse;} if ( PM_SaberInStart( ent->client->ps.saberMove ) //in a start|| PM_SaberInTransition( ent->client->ps.saberMove ) //in a transition|| PM_SaberInAttack( ent->client->ps.saberMove ) )//in an attack{//don't break when in the middle of an attack return qfalse;} if ( Q_stricmpn( "w_", surfName, 2 ) && Q_stricmpn( "saber", surfName, 5 ) //hack because using mod-community made saber&& Q_stricmp( "cylinder01", surfName ) )//hack because using mod-community made saber{//didn't hit my weapon return qfalse;}

Sure, love to!

Yep! 20 years April 3rd.

Interesting idea. You could have a probability that starts at 100% and drops for each shot blocked. Then have that probability constantly refreshing itself, back up towards 100% at a constant rate. Like, say each shot deflected takes 5% off of the block %, and it goes back up by 1%/server frame. So as long as you're only blocking 2 shots per second, you're blocking % stays high. So blocking one guy or slow-firing weapons is a sure thing. But a very rapid fire weapon or many, many enemies quickly exhausts your ability to accurately block and some will start to get through the longer you block. Combine this with the manual g_saberAutoBlocking 0 feature and the +block key binding and that could be pretty cool.

Thanks! It really was a passion project for all of us. I used to take the game home with me on weeknights and weekends (if I wasn't working then) and play it endlessly, taking notes on all the little things I wanted to fix. I'd come back to work with pages of notes.

G_saberAutoBlocking makes it so you have to manually block by binding a key to +block

Hey, just made an account for JKHub to respond to a thread about manual saber blocking and figured I'd offer up my insights if anyone had any questions about the Jedi Outcast or Jedi Academy source code (SP or MP). It's been almost 15 years since I've written or even seen most of it, but hopefully if you ask me a specific question about a specific chunk of code (copy/paste a chunk or gimme a file name and line number) I can at least try to jog my memory and speak intelligently about it. I'll try to check back if people have questions.

Hi, just stumbled across this thread while looking for a reference to the console variable I made to do exactly what you're asking for back when I wrote the lightsaber code for the Jedi games. Set g_saberAutoBlocking to 0, then bind a key to +block and you have exactly what you're looking for. Let me know if it's what you wanted!