MGummelt

Thanks, man! It's pretty cool when we hire someone new at Raven and it turned out they used to mod Jedi... Full circle moment.

Yeah, if the blend time is longer than the animation, it wouldn't surprise me that it snaps to the last frame prematurely.

Blocked_top probably is a really short animation, may not be able to blend to it? Though I suppose you could blend out of the old and and into the single frame of the new anim. I don't really remember much about the inner workings of the anim system when it gets down into Ghoul blending them, etc. I know we had a few commands to play specific animations in JKA, like crouch, spin your saber, taunt, etc. Look at the G_SetTauntAnim() function in g_cmds.cpp. You'll see it's called by ClientCommand when you enter a command on the console (or bound to a key) like "taunt", "bow", "meditate", "flourish", "gloat". You should be able to just add your own command that calls G_SetTauntAnim() with a different animation of your choosing.

Perhaps you're hitting another limit. How many .npc files are you trying to load? Look in NPC_LoadParms() in NPC_stats.cpp. void NPC_LoadParms( void ) { int len, totallen, npcExtFNLen, fileCnt, i; char *buffer, *holdChar, *marker; char npcExtensionListBuf[2048]; // The list of file names read in See that last one? That's a string buffer 2048 characters long. That means the list of files it will read in can only be 2048 characters long. If you have a ton of separate .npc files (instead of putting multiple ones in a single .npc file), and you have a long path to your .npc files (that really shouldn't be an issue) and/or long .npc file names - *maybe* you're hitting that limit instead. Try increasing that to 4096 or 8192. Or put all your npcs in one .npc file. Other than that, I don't see what else could be your problem. Are you actually getting the "NPC_LoadParms: ran out of space" error when reading in your NPCs? Or does it just stop? If it's the former, then increasing MAX_NPC_DATA_SIZE is the solution. If it's the latter, my above suggestion is the solution. At your other topic, I posted an explanation of hexidecimals and how that relates to the more common base 10 and binary counting systems.

No code, never made it past the pitch phase. :/

Not sure what you're asking - did KOTOR borrow anything from Jedi? No, completely different studios, completely different engines. Their lightsaber combat was based entirely on standing in place and playing canned animations while rolling "invisible dice" to see if you hit or not. Ours was dynamic, player-controlled and relied on hitscans to see where the lightsaber actually hit. Not that one was better than the other - that's just the difference between an RPG and an action game (though later RPGs would blur those lines to make them more appealing to the mass market of gamers).

Yeah, sounds good! My idea was deeper than the KOTOR workbench - it was to have you actually assemble it yourself build it by manipulating the pieces, aligning it just right and tuning it until it "resonated" just right. By feel - use the "force" to feel when it was done correctly, etc. That would be interesting if you had a mission where you had to collect and cook (or, in my original idea: meditate over) the crystals first to prepare them.

Sorry I didn't respond sooner - work has been pretty busy this last week. Sounds like you figured it out, though - nice work! -Mike

Heh, this is probably not going to be the answer you expected, but... I wanted the player to build their own lightsaber in Jedi Outcast. I had designed a small interactive experience/game to challenge the player to pick their hilt pieces and crystal and assemble them as part of their training. It would have required concentration and precision and some creativity from the player. Then that becomes your lightsaber for the rest of the game. Aside from that, I can't really think of a lightsaber feature I wanted to include but we couldn't. We had a really well-oiled machine between myself, the animators and our tech guys, so we got to do pretty much everything we wanted to do. There were things I experimented with just to see how it played (like manual blocking, grappling moves, etc.) but I can't think of any feature we cut for tech or time reasons. I remember that, after doing the "saber lock" feature in Outcast, I wanted to try more of the "paired animation" interactions in Jedi Academy (where you, for example, kick two enemies next to you at the same time). I did some of those and that was fun - I had to detect the possibility of pulling off the move based on the number and position of enemies, then make them take their places (like stunt men) and then play all the animations. That was the beginning of a feature called "combat nodes" and "fightstyles" that I ended up writing for X-Men Legends and that I really expanded upon in our Wolverine game. I remember right after Jedi Academy came out, the first of the new Prince of Persia games came out from Ubisoft Montreal (they would go on to do the Assassin's Creed series) and I was so jealous of how well they did their own paired animation interactions with enemies. It made me want to go back to Jedi and do the system right, but we moved on. An ambitious programmer could do that now, if they wanted. But those don't really work or belong in MP and so much of the longevity of the Jedi games has been in the MP scene.

Sorry I didn't respond sooner - but sounds like you found another way.

No, sorry, had nothing to do with any of that.

Yeah that won't do anything but allow you to set a higher aggression stat in the .npc file. Also, if I recall, I think the aggression stat is just used to set the initial aggression of an AI? The actual, current aggression goes up and down dynamically as they detect enemies, fight and take damage, I think.

True. I think we did it anyway if for no other reason than knowing by looking at the declaration whether it was actually defined in that file or not.

Stoiss, on 02 Mar 2017 - 2:08 PM, said: Actually, increasing those values will make them tougher enemies. In fact, that's how I make the enemies more difficult in higher difficulty levels of the game (I hate when games just make the enemies have more health). If you play on higher difficulty levels, we spawn tougher enemies with more abilities, more aggression and who are better at using them. Look in NPC_Spawn.cpp for all references to the g_spskill cvar. It's used to increase some of their stats like aim, speed, health, turning speed. It's also checked all over the AI code to make the enemies smarter and faster. So if you just want enemies more dangerous, play on the highest difficulty levels. If you want them even more dangerous, use higher values in the .npc files (or add to their stats on load in NPC_Spawn - maybe based on difficulty level) -Mike

Sorry, graphics were not my area in Jedi. You'd have to ask James Monroe.

What is it you're trying to accomplish? Do you want to make them more aggressive, move faster, aim better, evade more, react quicker and have more options available? Or do you want more granularity? Keep in mind that many of these values are checked in many different places in the AI code and if you're changing the scale of them, you'll have to change all the sites that check them. Like stats.aggression - some actions check for a relatively low number, like just checking to see if they should attack at the given moment. Others may check for a very high aggression (75-125 to go berzerk, for example). So it depends on what you're trying to accomplish by "increasing them to 1-20". If you just want to make NPCs more dangerous, increasing them in the .npc file is enough. But if you are trying to change the scale of the range to add more granularity, you'll need to modify all the code that increments, decrements and checks those stats. -Mike

You don't need to create an attacker variable (it won't be initialized to anything - just random memory or NULL). "ent" is the attacker in this case (the character who's swinging the lightsaber). You can just pass "ent" in for the attacker. Or initialize your attacker variable to be ent, like so: gentity_t *attacker = ent; That's all.

Wait, hold on. What do you mean "it doesn't work". How does it not work? What's the error? Show me what you did. Did you try to move the whole function definition higher up (you can't do that) or did you just declare it at the top like I showed (that should absolutely work). To clarify the terms I'm using, just in case you're not familiar: http://www.cprogramming.com/declare_vs_define.html

BTW, sorry if I disappear for several days at a time. This weekend we had company and a party to host, so I didn't have time to sit down for a couple hours and do this. And this week we have some important big-wigs visiting Raven and I need to get a mode I'm working on in perfect shape and a stable build together before they get here. Thanks for understanding!

Nice catch - though, of course, inside SaberBlock() there are multiple calls to rand(), so that doesn't quite work out the way you said.

Awesome, thanks for sharing your experience! I have to say, I have been constantly impressed with the Jedi community since before we released Outcast (how they would react to our early screenshots and point stuff out that needed to be fixed - like additive saber trails instead of normal blending) to how they behaved in Duel mode to the incredible modding scene that made me want to make Academy easier to mod to the constant modding and playing that's gone on since then! I'm proud to have been a part of a game that's brought so much enjoyment and elicited so much creative passion for so many... Here's a little list I wrote up recently of slightly more obscure console commands/cvars. Maybe there's one in there you didn't know about? setmindtrick 4 - makes mind trick take over an NPC when you use it on them - you have full control over the NPC, you can even make them kill other NPC or jump to their deaths iknowkungfu I added so I could test the slow-mo camera spin that plays automatically when you defeat the last enemy in the room. That slow-mo spin is on a console variable, too - you can disable it, make it do it on every kill and even make it do it on dodges/flips/rolls. G_saberautoblocking is one I made to try out a manual blocking system. If you set that to 0, then bind a key/button to +block, then you will only block when you actually actively do so. We left autoblocking on to be more player-friendly, but I kinda liked the extra level of skill it took. Helpusobi 1 was our replacement for sv_cheats. I think James Monroe came up with that one. There were a bunch of dismemberment console variables that I made to test our dismemberment system. The ESRB found out about them *after* they rated the game and we’d already shipped it. They threatened to change our rating to M unless we removed it from the game (never mind the fact that people get dismembered in every single Star Wars movie). First we obfuscated it, but ultimately we had to disable it altogether. set g_debugMelee to 1 to be able to do an extended set of melee moves - kicks, punches, grapples and throws. g_gravity - changes gravity, obvs g_timescale - slow or fast mo playermodel <whatever NPC you want> - lets you play as any NPC, even an AT-ST, droid or Boba Fett (with flamethrower, rockets, jetpack, etc.) g_saberAutoAim - aims your sabers at enemies so when you swing, it just intelligently swings in the right direction g_saberNewControlScheme use +forcefocus to pull off all the special moves g_saberLockRandomNess controls frequency of saberlocks g_debugSaberLock makes saberlocks happen all the time g_saberPickuppableDroppedSabers lets you pick up sabers that are dropped g_AIsurrender - enable/disable AI surrendering to the player if outmatched npc spawn <NPC> spawn any NPC runscript <.ibi file> lets you run any .ibi file from the console playerteam free, player, enemy, neutral - change you team (as if you turned to the dark side - Luke, Kyle, etc would attack you, bad guys would be on your side) control <targetname> - take over an NPC by targetname (or it will pick whoever you’re looking at grab <targetname> grapple the NPC you’re looking at or by targetname knockdown - knock yourself down

No, if I recall we didn't want to give designers the ability to access any cvar they wanted - that would just be chaos. It would open up a bunch of features to them that we didn't intend, they didn't need and which they wouldn't entirely know the effects of. And some would work in development (like cheats) but not release. Instead if they needed a specific command to do something a cvar or console command could do, we wrote an ICARUS command for it. However, I imagine something like this could fairly easily be written. At least, someone could probably write a function to stuff a command to the console (like "\set g_sex f") or call Cvar_Set and Cvar_Get...

Yeah, I mean - if you don't like how you're doing it now, I suppose you could add another field to the .sab file and parse it in WP_SaberParseParms(), then store it on the saberInfo_t struct in q_shared.h (keep in mind that changing this struct will invalidate old save data). So you could add a methodOfDamage field to saberInfo_t and then check that instead of fullName.

So I'm guessing your problem is that your NPC's .npc def doesn't have a saber declared as his weapon? If not, he will never create a saber in his ent->client->ps.saber, never initialize any of that data, never create the G2 models or anything. You probably need to give him a saber as a weapon in his .npc. This this bit of code in NPC_SetMiscDefaultData() in NPC_spawn.cpp will initialize it all: if ( ent->client->ps.saber[0].type != SABER_NONE && (!(ent->NPC->aiFlags&NPCAI_MATCHPLAYERWEAPON)||!ent->weaponModel[0]) ) {//if I'm equipped with a saber, initialize it (them) ent->client->ps.SaberDeactivate(); ent->client->ps.SetSaberLength( 0 ); WP_SaberInitBladeData( ent ); if ( ent->client->ps.weapon == WP_SABER ) {//this is our current weapon, add the models now WP_SaberAddG2SaberModels( ent ); } Jedi_ClearTimers( ent ); } Alternatively, you could try calling WP_SetSaber() in WP_SaberLoad.cpp before calling NPC_ChangeWeapon(). That's what's called when you use the saber console command or ICARUS command to give someone a saber. That might work, too.

Yeah, that's basically short-cutting all the parry logic that picks the right parry animation for you based on what's happening. You should be able to call WP_SaberParry() itself if you just declare it at the top of the file like I showed above.