MGummelt

Full Video: https://www.twitch.tv/videos/486308187

For those who missed it live!

Full Video: https://www.twitch.tv/videos/486308187

For those who missed it live!

Looks like the fix has been submitted to OpenJK.  The next build should have it working properly!  

My problem ended up being something different IIRC (this was just on mine so it may be different on the others' in this thread)

 

I already had these settings but it didn't work, what works for me when dismemberment randomly breaks is just "exec openjk_sp.cfg" in the main title screen

Hmm, not sure what that would have done for you - my OpenJK didn't come with any .cfg files.

FYI, the correct cvars to set are:

Oh, and it's fixed.

Totally reviving this thread to say I found the bug in OpenJK that is making dismemberment not work. 

That‘s why I showed you the RocketThink() function above. That will point the fighter at the target and chase it, like a homing/tracking rocket.

I only showed that function for the math/logic in it. I don’t think you could call that on an NPC as you probably want to set the velocity directly on the NPC, not the pos.trDelta (which is for networked general entities). I would copy that function and make the new one work for vehicle NPCs by storing the resultant velocity in the correct field on the NPC.

I just went through this whole thread. I don't have any programming skills, but making skins for JKO helped a lot with learning to use photoshop and getting interested into game design in general. It's pretty cool to see a game dev reaching out to us humble modders. Also very inspiring to know you started as a modder yourself.

 

I don't have any questions, just wanted to say this.

Thanks, Raschu!

@@MGummelt hello there.

sorry if i stress again. i have some little bug again to fix on my fighters. not much deals. i was wondering if you can give me some suggest related to this.

the first problem reguard that: dogfight against fighters TEAM_PLAYER agains TEAM_ENEMY npcs. this problem occurs also if you try to create a friendly rockettrooper NPC and fight NPC rockettrooper. basiclaly, they shoot theirself on the air and their fight with repeater. during fight they have the little problem they do fly manouvre that ... in the course of some minutes, they fly ever up, up, up and more up, until they reach the skybox or the "roof" of the level map. this is not much good to see for a starfightning because in a battle NPC will lost on the Sky. i found the incriminated functions coming by AI_SENTRY and AI_REMOTE .CPP is the maintainheight function.

This:

 

dif = (NPC->enemy->currentOrigin[2]+NPC->enemy->maxs[2]) - NPC->currentOrigin[2];

        // cap to prevent dramatic height shifts

        if ( fabs( dif ) > 8 )

        {

            if ( fabs( dif ) > OLON_HOVER_HEIGHT )

            {

                dif = ( dif < 0 ? -24 : 24 );

            }

 

            NPC->client->ps.velocity[2] = (NPC->client->ps.velocity[2]+dif)/2;

 

can you explain a lot how works exaclty fabs and difs here?

there is some way to fix this for preserve this kind of movement removing this problem of the fighter NPC shifting to Up during a dogfight?

and there is also some better code that i can use for fighter movement during a dogfights? here is defined all my npc fighters flight movements when they have a goal or a enemy. is nice to see on a combat into a map but is again alot far for a true dogfights of games like Xwing alliance or rogue squadron3d , there is any way to improve that for create a nice battle against NPCs?  this is the last tecnical problem of my AI.

@@Archangel35757 can you give me an hand too to manage this? should be great a better dogfight code of that. :3

fabs() is just a function to turn a negative number into a positive number (f = float, abs = "absolute value).

Dif is the difference in height between the top of the enemy and the bottom of me (remember, this was written for NPCs, not vehicles - so this is keeping the height of the flying NPC above the head of the enemy, which it assumes is on the ground - the flying NPCs were never programmed to be able to fight other flying NPCs).

The obvious issue, here, is that both of them are trying to fly just above the head of the other, so they both just keep going up and up in a feedback loop.

You could make it so that the fighters are just trying to stay at about the same level as each other (same Z-height, within some reasonable tolerance, like +/- 64 units or so).

But, really, if they're fighting in 3D space and able to pitch up/down to track their enemy, you shouldn't need this at all.  Just angle them towards their enemy and make them chase them.  No height matching is needed.

@@MGummelt 

 

Hello There! 

 

I am typing here as the one of the MB2 maps creator now. I want ask you for help but i dont know if you will know the answer. 

 

In MP there is a strange bug - Player models can go through the walls, floor that are crateded with patch meshes (not brushes) in the map. There is some serious collision error. I mostly happens when player is using the special jump attack both dual and staff sabers. 

 

Player is getting through the patches like a ghost. For mods like MB2 it can be game breaking and it can change the overall gaming experience. As far as i know - this issue is not MB2 only. It happens in the default verion of jamp.

Hmm, I'm not sure what this is, I wasn't a map designer or tech programmer.

Are they passing through the "front" side of the patch mesh or the back?

Does playerclipping the patch mesh fix it?

@@MGummelt it works!!! after two years of headaches! thanks ! thanks 1 thousand time!!!

 

i need just to put on the equation some decay value like the "apply friction" and the decay int of Sentry Ai because you're right!

VectorMa create a logaritmic acceleration... but is also necessary for make all workings. so they need really a brake inside the code because i spawned fifty fighters with consolles and they go forward, boost up, accelerate in so crazy way that also if they seek me as enemy they fly for all map and skybox like crazy comets and explodes by impact damage with skybox to a mad speed! ROTFL!!!

it's funny to see but it works! now i need just to debug, finding the just values for making a decent flight

i am sure at the end i'll do that. and after that i can think to the player client fighter code and user UI HUD.

Because NPC is almost done.

thanks again!!

Awesome, glad to hear it!  Yeah, direct control over velocity is probably best for what you're trying to do.  If you want to see an example of how we make objects head to a target using velocity, looking at any homing missile code in Jedi.  And example is rocketThink() in g_weapon.cpp.  I pasted below, removing some stuff to simplify it to the important parts:

//---------------------------------------------------------
void rocketThink( gentity_t *ent )
//---------------------------------------------------------
{
	vec3_t newdir, targetdir, 
			up={0,0,1}, right; 
	vec3_t	org;
	float dot, dot2;

	if ( ent->enemy && ent->enemy->inuse )
	{

>>Here we get the old velocity of the rocket - if it's got spawnflag 1, we use its custom specified speed, otherwise we use the standard constant rocket speed
		float vel = (ent->spawnflags&1)?ent->speed:ROCKET_VELOCITY;
>>This is how much it "homes" or tracks the target - I think we used the "angle" field as a multiplier on how tightly the rocket could turn.
		float newDirMult = ent->angle?ent->angle*2.0f:1.0f;
		float oldDirMult = ent->angle?(1.0f-ent->angle)*2.0f:1.0f;

>>Important part:
>>Get the center of the target - some things have origins at their "feet", not their center
		VectorCopy( ent->enemy->currentOrigin, org );
		org[2] += (ent->enemy->mins[2] + ent->enemy->maxs[2]) * 0.5f;
>>This gets the direction from from the current position of the rocket to the target
		VectorSubtract( org, ent->currentOrigin, targetdir );
>>Turns the full vector above to a direction (normalized to a scale of 1)
		VectorNormalize( targetdir );

>>Here we need to figure out how much we need to turn from our current direction (ent->movedir) to our desired direction (that we just calculated above)
		// Now the rocket can't do a 180 in space, so we'll limit the turn to about 45 degrees.
		dot = DotProduct( targetdir, ent->movedir );

		// a dot of 1.0 means right-on-target.
>>Dot product is a normalized measure of the difference in angle between two directions - 1.0 is they both are going in the same direction, 0.0 is they're perpendicular, -1.0 means they're opposite directions.
>>Here we're checking to see if the target is "behind us" (more then 90 degrees off to the side)
		if ( dot < 0.0f )
		{	
>>Start turning us around - to the right or left, depending on which side the enemy is on
			// Go in the direction opposite, start a 180.
			CrossProduct( ent->movedir, up, right );
			dot2 = DotProduct( targetdir, right );

			if ( dot2 > 0 )
			{	
				// Turn 45 degrees right.
				VectorMA( ent->movedir, 0.3f*newDirMult, right, newdir );
			}
			else
			{	
				// Turn 45 degrees left.
				VectorMA(ent->movedir, -0.3f*newDirMult, right, newdir);
			}

			// Yeah we've adjusted horizontally, but let's split the difference vertically, so we kinda try to move towards it.
			newdir[2] = ( (targetdir[2]*newDirMult) + (ent->movedir[2]*oldDirMult) ) * 0.5;

			// slowing down coupled with fairly tight turns can lead us to orbit an enemy..looks bad so don't do it!
			//vel *= 0.5f;
		}
>>These handle if it's more in front of us - turning harder the more in front of us it is
		else if ( dot < 0.70f )
		{	
			// Still a bit off, so we turn a bit softer
			VectorMA( ent->movedir, 0.5f*newDirMult, targetdir, newdir );
		}
		else
		{	
			// getting close, so turn a bit harder
			VectorMA( ent->movedir, 0.9f*newDirMult, targetdir, newdir );
		}

>>This adds some randomness - the higher the ent->random, the more randomness ("drunkenness") there will be in the velocity - this could be done only every certain interval if desired, instead of every think/update
		// add crazy drunkenness
		for ( int i = 0; i < 3; i++ )
		{
			newdir[i] += crandom() * ent->random * 0.25f;
		}

>>This makes the randomness go away after a while - so the rocket will start "drunken", but then straighten itself out after a while
		// decay the randomness
		ent->random *= 0.9f;

>>This makes the homing rocket less likely to miss and pass the target - using an old Quake multiplayer trick - don't shoot the rocket at the player's center, shoot at their feet so that even if you miss them, you'll hit the floor and blow up close enough to damage them
		if ( ent->enemy->client
			&& ent->enemy->client->ps.groundEntityNum != ENTITYNUM_NONE )
		{//tracking a client who's on the ground, aim at the floor...?
			// Try to crash into the ground if we get close enough to do splash damage
			float dis = Distance( ent->currentOrigin, org );

			if ( dis < 128 )
			{
				// the closer we get, the more we push the rocket down, heh heh.
				newdir[2] -= (1.0f - (dis / 128.0f)) * 0.6f;
			}
		}

>>Back to the important stuff - now that we've got our new direction (calculated from our old direction and target direction and how much we can actually turn this think/update), normalize it to a scale of 1 so it's a direction, not a velocity
		VectorNormalize( newdir );

>>Take the new direction, scale it up to half our full speed and use that as our new velocity (I think we used half speed because otherwise it could miss targets too easily)
		VectorScale( newdir, vel * 0.5f, ent->s.pos.trDelta );
		VectorCopy( newdir, ent->movedir );
		SnapVector( ent->s.pos.trDelta );			// save net bandwidth
		VectorCopy( ent->currentOrigin, ent->s.pos.trBase );
		ent->s.pos.trTime = level.time;
	}

>>Set the time of the next update
	ent->nextthink = level.time + ROCKET_ALT_THINK_TIME;	// Nothing at all spectacular happened, continue.
	return;
}

The reason the fighters move fine when they attack is that the Hunt function is setting their velocity directly.

If that's all you want to do in idle or patrol, just set the velocity directly and ignore all the forwardmove and usercmd stuff. Like below:

    //Get your current forward dir
    AngleVectors( NPC->client->renderInfo.eyeAngles, forward, NULL, NULL );
   //or just this - not sure why you're trying to get the NPC's eye angles on a vehicle above?  That would be more for a player controlling a vehicle
    AngleVectors( self->currentAngles, forward, right, NULL );

   //Set speed to walkspeed or runspeed or whatever you want
    speed = FIGHTER_FORWARD_BASE_SPEED + FIGHTER_FORWARD_MULTIPLIER * g_spskill->integer;

   //set velocity directly - note that this *adds* the new velocity to the old one, meaning it will keep accelerating - only do this if the speed hasn't reached max or you're changing direction
    VectorMA( NPC->client->ps.velocity, speed, forward, NPC->client->ps.velocity );
   //You can just do this, but this will go to the new velocity immediately - you'd have to smooth out acceleration yourself
    VectorMultiply( forward, speed, NPC->client->ps.velocity );

Dear MGummelt, thanks for time you spend to answer to me and to alls coder of JKHUB. here in italy is pretty hot summer and is not easy stay on computer to do coding with hot weather. but i'll do as soon as i can. i really want to see the result and i think your suggests are pretty valid and interessing. thanks again and have nice holiday. i'will let you know my progress

No problem, and good luck!

That's explain a very lot of things. infact after build nothing is changed to my fighter (but they are NOT vehicle, myster they are really NPC... basically they are like droids... but i want they move and fight like a vehicle. something like that. i do that with NPC code instead of vehicle because NPC is more simply to use, not need a driver and have more weapons and weapons can be easy switchable (i want my fighters using seekers if enemy is far and blaster if near, and bomb and chaff and flare and other original weapons too, is for a science fiction mod not only star wars ) basically i want to recreate this movement:

https://www.youtube.com/watch?v=CDntDe7eazAleaving out 

leaving force forward move, and using a vector movement imbued into NPC AI client code that force NPC to move a walkspeed into his idle \ patrol state and runspeed at his attack \ flee \ hunt \ strafe  behavour state, there is some other way to do that with a simple vector move along Y axis? i am not familiar with vector so i need an example of a little function that force an entity to move forward along a vector direction. there is into the code the command about SET_MOVEMENT X \ Y \ Z of something like that and it work on every entity, npc included, but i tryed and it move with absolutely direction, not with a vector related to X Y Z left \ right

forward \ backward  and up \ down of NPC. i need just to push a fighter along Y axis with + values, but NOT with absolutely map Y vector, but with Y axis vector relative to entity.

 

mmm strange, video link not work try to dive into google with search about "rogue squadron 3d escape on fest gold medal" and you see what i want to recreate.

I think the function I mentioned (that uses force_forwardmove) might show you how to turn a vector into ucmd directions.  But, if not, it's pretty simple.  The basic procedure is like this:

You have to turn the world velocity/vector into a local one.  The easiest way to do this is vector multiplying.

First, normalize the velocity with VectorNormalize() (this will also return the scale of the vector - your desired speed - you won't need this).  Something like this:

desiredSpeed = VectorNormalize( desiredVelocity );

Now desiredVelocity is a vector with a magnitude of 1 (a direction, not a velocity anymore) and your desiredSpeed is the speed you want to go in that direction (again, this won't be used unless you want to use this to set the vehicle's current speed or something)

Next, use the angles of your entity to get your forward, right and up vectors.  There should be a command something like "VectorAngles" or "AnglesToVector" - something like that.  You pass in your angles and it should pass you back 3 normalized vectors - forward, right and up.

Then multiply each of these normalized vectors times the desired velocity/vector.  That will give you the normalized (-1 to 1) *magnitude* (or speed) that you need to travel along in that local direction.

For example:

float forwardAmt = forward * desiredVelocity;

(I don't recall, offhand, if you can multiply vectors directly like that in Jedi code, you may need to use VectorMultiply() or something like that? - EDIT: in Jedi, we used dot_product() for this...)

Do that for all 3 local vectors (forward, right, up).  Now you should have 3 vectors from -1 to 1.  All you need to do now is multiply them by 128 and turn them into ints with int().

Ultimately, these will be used to turn this back into a normalized vector which gets multiplied by your current speed.

EDIT:

Was able to look up the function that does this:

void G_UcmdMoveForDir( gentity_t *self, usercmd_t *cmd, vec3_t dir )

Hi Mike!

 

My internet is down at the moment and I'm using the data roaming on my mobile, so I cannot get into this right now. From what I can tell you is in g_client at the bottom in clientspawn, where the model is loaded on map starting, I've created it for each level a different model is used. I was looking in g_savegame and realised.. OpenJK changed the save code so that it would be compatable cross-platformed so, I may have to discuss this with them.

 

I think your right in what your saying about 'gets set and is reading something different elsewhere..' You see the code uses npc type for the player in the scripted levels(I can save/load no problem on the 'Pit' map), I think what is happening is that its calling for the npc model and its conflicting with the different model I had saved with... Maybe, maybe not but thats the best I've got so far pal.

Yeah, I can't offer advice on modded codebases like OpenJK, I've not looked at them.

@@MGummelt

Hello pal! Good to hear/read of you once again ☺

 

I really hope you can help me out a little, or if any at all would be nice.

 

In g.client at the bottom in clientspawn, I've edited the on loading of a map different models for Kyle, but the problem occurs when I save a game and on loading of that save, the ghoul2 model's animations are locked is the best way I can describe it; he fires always in the same direction and float across the screen with the navigation all wrong. I've had it working with changing loadtransition ==qtrue, but I start back at the map beginning and looking up.

 

How can I leave loadtransition==qfalse but unlock my models animation?

In g.main right at the very bottom, there is a bit of code tbat calls playerlocked.. Does that have anything to do with it?

 

Kind Regards

Can you show me what the edit you made was?  My guess is you changed one place that gets/sets the player model but another place is setting/getting a different value.

I do two edit one in BS_Fighter_Default

void NPC_BSFighter_Default( void )
{
    NPC->client->forced_forwardmove = 127;

and the other on bg_pmove.cpp on void pmove, near to end of file.

i added the last condition

}

    if ( pm->ps->pm_flags & PMF_SLOW_MO_FALL )
    {//half grav
        pm->ps->gravity *= 2;
    }

    // FIX FOR NPC MOVE FORWARD
    if ( pm->gent && pm->gent->NPC && pm->gent->NPC->force_forwardmove != 0)
    {// Boost up forward! EVER!
        pm->cmd.forwardmove = pm->gent->NPC->force_forwardmove;
    }
}

when i build i get a build error because forceforwardmove is not a member of gNPC_t (on b_public.h)

Okay i am adding on gNPC_t . but is forced_forwardmove not forceforward. now i understand the code errors.

stilling building Dll.

You're setting it on the NPC's client struct and checking it on the NPC's NPC struct.  That won't work, obviously.  Either set and check it on the client struct or set and check it on the NPC struct.  If you want to use the NPC struct, you need to add that variable to the gNPC_t struct in b_public.h.

example on NPC_spawn.CPP i tried

else if ( ent->client->NPC_class == CLASS_FIGHTER )
            {        
                ent->client->ps.gravity = 0;
                ent->svFlags |= SVF_CUSTOM_GRAVITY;
                ent->client->moveType = MT_FLYSWIM;
                ent->s.loopSound = G_SoundIndex( "sound/vehicles/tie-bomber/loop.wav" );
                ent->client->force_forwardmove = 127;
                // For start to fly?
                ent->client->ps.forcePowersKnown |= ( 1 << FP_LEVITATION );
                ent->client->ps.forcePowerLevel[FP_LEVITATION] = FORCE_LEVEL_3;
                ent->client->ps.forcePower = 100;
                ent->NPC->scriptFlags |= (SCF_NAV_CAN_FLY|SCF_FLY_WITH_JET|SCF_NAV_CAN_JUMP);//no groups, no combat points!
                //start in the air, use spotlight
                //ent->NPC->scriptFlags |= SCF_NO_GROUPS;
                ent->NPC->scriptFlags &= ~SCF_FLY_WITH_JET;
                RT_FlyStart( ent );
                NPC_SetMoveGoal( ent, ent->currentOrigin, 16, qfalse, -1, NULL );
                VectorCopy( ent->currentOrigin, ent->pos1 );
                // Spawn Floating until see an enemy!
                NPC_SetAnim( ent, SETANIM_LEGS, BOTH_SWIM_IDLE1, SETANIM_FLAG_NORMAL );
                NPC_SetAnim( ent, SETANIM_TORSO, BOTH_SWIM_IDLE1, SETANIM_FLAG_OVERRIDE|SETANIM_FLAG_HOLD );
                ent->client->ps.torsoAnimTimer = level.time + cg.time;
            }

(i tryed to worked around a merged copy of  Seeker, Sentry and rockettrooper\Bobafett AI,

Seeker \ sentry ai for flight movement and strafing and death with explosion and corpse disappering; boba fett for switching weapons and tactics.

niceful for fight, but not force forwarding. so my fighter act like assault chopters, like tornadoes of saint row series LOL. )

i will try the pm way! thanks! :3

Here's the thing - force_forwardmove does nothing by itself.  There's a function that takes the value of force_forwardmove and turns that into the pm->cmd.forwardmove of the entity (I can't remember the name of it and I'm at work right now, but if you search for force_forwardmove, you'll find it).  But that function is only called on actual clients (like the player), not on NPC vehicles with no driver.  So you'll need to do that yourself (like the example I gave with force_forwardmove if you put it on the NPC struct).  You can put the force_forwardmove variable wherever you want as long as you can access it later in Pmove() or some setup function called before Pmove().

Keep in mind that the NPC struct doesn't already have a force_forwardmove variable on it, you'll have to add it.

Ehy Mgummelt, i have too a little question.

There is a icarus comand called set_forward move. that can affect an entity to move ever forward. +64 at walkspeed +128 at runspeed . negative value move walkback and runback.

i tryed this on game but i see it works only for player and not on NPC. there is some way for works also on NPC too about that, or the function is callind on code? (ent->client->forceforwardmove)

how it works? it need an integer for works and i think to add to the AI of my class for force an NPC using this class, when is spawn, to move ever forward, at desired speed (maybe walk when is in idle \ patrol behavour and run speed when is attacking \ fleeing).

it need something like NPC->client->setforceforward = int value (like 127, 64 etc)

or it need a command like NPC->client->setforceforward, 64 (or another value between 0 an 127)

what i want is that an NPC when spawning or calling ai functions of his behavour, can use this function for force him to move forward.

if this is not possible. i am asking if there is some way with vectors, for move costantly and entity (player and NPCs)  to forward, along Y direction axis.

 

Thanks for any answers.

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;
}

Hello there MGummelt,

 

I have a question. Is there anyway in the code (cvar or else) to change the players size? Npc files have the option to change the size but the player has not?

 

Thank you

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		16

Even 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).

Hello again,

I actually got japanese working on .str files i just add Japanese Shift-JIS encoding and same for my .cfg file if i want to give myself japanese name. For chat it only shows if I make binds atm. I am wandering now if I can mess with the direct input to allow more symbols to show up when typing in game. (sorry big image)

 

 

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.

Greetings!

 

I have a question that relates to a thread I made awhile back. I had the random thought on if it were possible to enable the player's lightsaber to damage/dismember their own body? We figured its most likely related to hitboxes, but in order for the lightsaber to detect the player's hitbox itself as a "target" then I imagine that would require some sort of coding. Is such a thing even possible? I'm curious cause, even though such an idea is completely pointless and silly, it could be interesting to pull off and have pretty funny results (with dismembering limits turned off of course)!  For example, if you use the "hilt spinning" taunt but then turn the lightsaber on then the blade clips through your neck with no damage, however that would be hilarious if such a thing could actually kill you and lop your head off. (Or if an NPC does it to themselves, lol)

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.