Dusty

How doth one createth a TGA sequence? Did you use cg_avidemo or something? That gave me poopy performance when I would try to use it.

Aww sweet thanks! Naah yeah I'll try the roq.exe thing for better quality. Does anyone know which video codecs are the best to use for JA/JK2? Like which ones give the best quality video for recording in-game and in the end product as an .roq?

Doing some SP coding in Visual Studio 2013, and trying to debug, but it stopped working recently. So, lately, debugging using breakpoints hasn't been working because of this message: http://s15.postimg.org/h1fup6ttn/error1.png (dustyspatch_sp.x86.exe is just a renamed openjk_sp.x86.exe file) The .pdb file is for debugging I know, but what happened to it, and how can I get it back? Where should it be located if I need to delete it to force VS 2013 to make a new one?

He may not be able to switch to a pistol if he doesn't have one. Grenadiers I'm pretty sure can't switch to melee if they don't have it. You could probably just copy the AI_Grenadier.cpp code for Grans switching back and forth between melee and thermal dets. That code implies that they must possess WP_MELEE to be able to switch to it, so I would recommend using that code and then editing the st_commander NPC file to give them a blaster pistol.

This show is honestly really growing on me. At first I thought it was just an immature version of the Clone Wars show, but it's honestly pretty cool. When I first saw Ezra do some force jump dive rolling building parkour like it was nothing I was just like o_O. Plus as I look at more of the episodes the themes and character interaction is more mature than my first impression. My only genuine criticism right now, is that as usual, the stormtroopers are portrayed as mostly unskilled. They're not terrible, just not good. I wish they could just for once be characterized the way they were supposed to be like in the opening to ANH where they board the Tantive easily, and then Obi says "Only Imperial Stormtroopers are so precise...". Of course the Heros would still outmatch them, but you could just do a quick thing like... Hero character narrowly dodges a few close shots, then says "These guys have good aim, better not give them a clear shot!" or something. It's not like it would be that hard to do

For my mod in the SP main menu, I wanted to make a video of bits from many SP cutscenes to make for a more interesting video rather than the boring looping one of the shuttle going to Yavin IV. For example, cuts from scenes where Luke is addressing all the students in the academy, ones with Rosh and Alora, and from the beginnings of various missions (t1_rail, t1_danger, t2_hutt, t2_dpred, t2_rogue, hoth, t3_boba etc.). I could do it myself, but I'm not adept with in-game video making and Quake Video Maker. I remember a while back having trouble fussing with codecs that gave me good quality once they were converted to .roq and then having the colors in all my .roqs getting messed up for some reason I couldn't figure out...

thirdpersoncameradamp exists. Use it. That's how I make 2nd person cameras. You can make the camera much tighter.

^So, I looked into that. But I'm not sure how to "set" the SFL_NOT_THROWABLE flag back to not being on the saber after it is applied (setting it is easy as I can just copy Raven's code). I'm sure it can be done, but I'm not good with bitwise operators (the |=, &=, ~, and & are all used as bitwise operators by Raven) as they require me to wrap my mind around modifying binary code. What I did find was a piece of code I previously overlooked, a function in wp_saber.cpp called WP_Forcepowerusable. That actually controls the ability to saber throw. So now holding use disables saber throw by modding that. It seems the purpose of PM_SaberThrowable is just purely for kick checking. I'm still a bit confused however as to why staff saber allows kicks and single does not (maybe it has to do with the saberAnimLevel == SS_STAFF in there?), as with staff saber even when I make the saber throwable, you can still kick as the saber is returning to your hand, while it's mid-flight, or when you don't have enough FP for a saber throw. Still trying to solve the mystery I guess... EDIT: I'm thinking that based on my observations, the "if player is holding use" chunk of code in PM_SaberThrowable is having zilch effect (maybe the expression I used has no value in the context of that function), as the next two pieces of code regarding saberAnimLevel == SS_STAFF and the one pertaining to the SFL_NOT_THROWABLE flag (which is set by throwable 1/0 in the .sab) are consistent with all my/our other observations. Solution: Posting this way later. It turns out it was a redundant piece of code (somewhere in bg_pmove I think) that would bar the player code-side from even being able to press the Alt-Attack button if they had a non-staff saber that wasn't throwable.

I tried that, but I didn't get any leads as to what was making my specific code not do anything. Maybe if I could have the use key change the "throwable" value. Only problem with that is I don't know if "throwable" is checked every frame. Maybe pressing use would change the value of the "saber" to 0, and then letting go would set it back. Worth a shot I guess.

I can't figure out why this code isn't working, and I can't find anything else in the code that would seem to override it. What should happen is if the player is holding the Use button saber throw should be disabled so they can kick (this is in Single Player btw). From bg_pmove.cpp: qboolean PM_SaberThrowable( void ) { //player gets to kick if holding use if (pm->cmd.buttons & BUTTON_USE) { return qfalse; } //ugh, hard-coding this is bad... if ( pm->ps->saberAnimLevel == SS_STAFF ) { return qfalse; } if ( !(pm->ps->saber[0].saberFlags&SFL_NOT_THROWABLE) ) {//yes, this saber is always throwable return qtrue; } //saber is not normally throwable if ( (pm->ps->saber[0].saberFlags&SFL_SINGLE_BLADE_THROWABLE) ) {//it is throwable if only one blade is on if ( pm->ps->saber[0].numBlades > 1 ) {//it has more than one blade int numBladesActive = 0; for ( int i = 0; i < pm->ps->saber[0].numBlades; i++ ) { if ( pm->ps->saber[0].blade[i].active ) { numBladesActive++; } } if ( numBladesActive == 1 ) {//only 1 blade is on return qtrue; } } } //nope, can't throw it return qfalse; } qboolean PM_CheckAltKickAttack( void ) { if ( (pm->cmd.buttons&BUTTON_ALT_ATTACK) && (!(pm->ps->pm_flags&PMF_ALT_ATTACK_HELD) ||PM_SaberInReturn(pm->ps->saberMove)) && (!PM_FlippingAnim(pm->ps->legsAnim)||pm->ps->legsAnimTimer<=250) && (!PM_SaberThrowable()) && pm->ps->SaberActive() && !(pm->ps->saber[0].saberFlags&SFL_NO_KICKS)//okay to do kicks with this saber && (!pm->ps->dualSabers || !(pm->ps->saber[1].saberFlags&SFL_NO_KICKS) )//okay to do kicks with this saber ) { return qtrue; } return qfalse; } I would know it was partially working if I couldn't kick but I couldn't throw the saber either while use is held, but I know it's not working at all because I can always throw my saber... I would try debugging but the VS debugger hasn't been ehm, agreeing with me.

Big-picture wise, I think I will keep specials roughly as they are (the it-breaks or it-doesn't type deal), and then later on play testing more differences can be ironed out. Otherwise... I think you're on to something with the multiple hit thing though. This would make sense for katas and moves like the staff and duals saber twirls. Perhaps blocking these attacks would act kind of like pseudo-blocking strong style in the normal saber system as in, the defender's guard would not be crushed and they would be able to technically parry/block, but the attacker would not actually be interrupted at all, so the defender only can completely defend glancing blows, but a solid hit still powers through. Other thoughts: Do special attacks need an extra advantage, or is the "offense level + 1" combined with a few small unique properties enough? (I think it is because you don't want normal swings to be too much weaker). Should different special attacks act largely the same as each other like they do in base? Or should different attacks have different properties such as damage, guard-breaking ability, etc.?

So, I need some suggestions. I'm not quite sure how to handle saber staff in the new saber system or how to do special attacks. In base SP staff is pretty overpowered because it hits as hard as strong style. And special attacks are a little tricky in the new system. Also, on the whole, I'm trying to follow the motto of keeping things relatively simple and not too drastic as far as changes go from the default system. What I have so far: Staff - Attack strength is properly tied to staff style now, as opposed to the saber hilt having the twoHanded property. - Staff style is power level 4 (medium is 3, red/desann is 5, medium is your offense level + 0, red is +2 for example), I figure the wide two-handed palms-down motions of staff would add a little more gusto to the attacks - Staff does damage during transitions like strong/desann Special Attacks - have power level 5 strength - rather than adding to a break counter like standard attacks they act a little different - if the attack is strong enough, it breaks their defense out right - otherwise the attack is blocked Maybe... special attacks cause a longer stagger than other moves. And they react to being blocked differently than a standard attack. Ideally I don't want them to be too cheap (I want regular slashes to be important), but I want them to still be useful. Any ideas?

Yeah, knockdown or stagger is probably better.

What Roxoon suggested is practical I think, you just need coding. It could be hard coded that at all/most times the player's bones will fluctuate by a unit or two for breathing, or at least I imagine that would be possible. As for the running speeds, in JA they're hardcoded to match up with the run speed of the character or something. Changing the animation.cfg won't do anything by itself. Trying playing with the g_nofootslide and g_footslidescale cvars or whatever they're called. (or is it cg_? I can't remember off hand) EDIT: As for other updates, the saber system is nearing completion. Not bug-free though. I'm also making a little progress with some of the AI stuff. Figuring out why certain things don't work though is proving tricky.

No one has really given me any feedback . Next mods I will work on I think: - Independent release for Reborn Apprentice skin - Lightning visual effects - Menu mods

Let me just say, for me any sort of saber throw possession battle or saber catching mechanism is well out of my ability to code. It would have to be eezstreet or Razor or some other experienced coder if you want an idea how feasible it is. I already had help from @@redsaurus coding some more tricky things, like having to aim blaster deflections with the crosshair, save game screenshots, and saber force lightning block effects. About the saber inventory thing, there's two commands in SP related to picking up sabers. One is g_saber. This is/are the saber(s) that are saved as belonging to the player. You can use "playermodel x" to change your saber, or the saber command, but I'm not sure if they actually change the value of g_saber (i.e. I know playermodel doesn't change the value of g_model so if you don't change that too when you load the game later you'll have an untextured model). Then there's g_pickupabledroppedsabers. I think the Yavin IV mod just turned that on then did some clever menu stuff to keep track of sabers so you could gather up an inventory of them. Either way pretty clever and cool. For breathing animations I don't know what that would look like... maybe they could be ripped from the cutscene... as for the feet sliding and rollerblading in JA, I noticed in JK2 the run animations were more accurate, and in JA no matter what I did to the animation.cfg the animation speeds wouldn't change. What I found was a cvar in JA called cg_noFootSlide or something like that. If you turn it off the run (and walk?) animations are sped up. There's other cvars relating to this too but I'm not sure how they all work.

^Interesting idea, but out of my own abilities to code. Sabers are sort of possessed by whoever it belongs to and act as the active weapon even mid-flight. That's why you can't really switch to melee in MP when your saber throw is disarmed. Unless the saber's possession could be "deactivated" code-wise and then the "pick up" code that g_saberpickupabledroppedsabers uses could be used to "grab it". Saber throws are interesting though for duels but could use a little work. I feel like NPCs just need to not sit there dumbfounded when you knock their saber throws down or rush them after they throw it. Also, ideally the player shouldn't be able to be too cheap with it either. Saber throws in JA/JK2 in general are more of the spammy sort. In BFII the throw was more realistic IMO where it was powerful but it had more a boomerang likeness and high-speed momentum but required more skill to aim. While I like it roughly how it is in the JK games, I feel like it should have a smidge more power and speed, but be less like "lulz eat saber" and act like a rebounding pinball, and therefore a little less quick and cheap. Just an idea. Not sure what it would really look like though. What you guys think? On a side note, for return damage to be an allowable skill, I think NPCs would need to be able to cheat and be able to block it from behind except in maybe some special situations. Or perhaps return damage would be allowable if the saber throw was given more of a boomerang dynamic but wasn't so easy to aim nor has such a "rapid-fire" mechanic. Idea: Maybe disarmed sabers could be "picked up" mid-fight. Like if you knock an enemy's saber out of their hand (from a saber throw, strong attack, parry etc.), you could grab it and use it for the remainder of the level? But then some enemies would become defenseless...

Some more NPC AI things I've been working on that I've yet to test, or that I plan to do and think I can do: NPCs shouldn't default to "Heavy Melee" now (the punches that do 25-30+ damage), but only Chewie, Class_Gran, and Class_Trandoshan get it now, and non-heavy melee users should punch faster nowGrenadiers that have melee should try to punch you if you get really close to them now even if your saber is outImperial commanders and class_rodian + e11 using alt-fireAllied NPCs don't get higher game difficulty bonuses to HP like enemies do now, only on lower difficultiesNPCs that are "smarter" with surrendering and less awkward about itAllied NPCs that don't attack surrendering enemiesSaber-wielders that semi-evade if they're saber is mid-flight or run for it if you've disarmed their saberblaster/melee npcs with class_reborn not doing cartwheels unless they have at least force jump 1melee force user NPCs using force push on throwables and auto-dodging sniper shots just like saber wielders

So, anyone have any feedback for the couple of mods so far?

You know, in game, I can't find a difference between difficulty levels for blaster defense in normal gameplay... That's really weird though, because I could've sworn your defense was noticeably worse on higher difficulties... Does anyone know, if anything in AI_Jedi.cpp can affect the player's attributes? Or does everything in there only pertain to NPCs?

Silly me. Never assume because it makes an *** out of you and me. In JA imp commanders don't use alt-fire by default, precisely because that part of the code is commented out for JA. Still doesn't explain why alt-fire in .npc files doesn't work... but that's for another day.