Jump to content

Home

MBII saber blades


Recommended Posts

  • Replies 94
  • Created
  • Last Reply

...That's odd. The cores are colored ingame?

 

I don't think that's supposed to happen...

 

But besides there, what's the issue? They seem to be colored properly.

 

BTW, what I effectively did by fixing bnum was make this part of case SABER_RGB work properly:

 

if(bnum == 0)
VectorCopy(ci->rgb1, rgb);
else
       VectorCopy(ci->rgb2, rgb);

 

Which, if I understand what I'm reading, means that the various values of the first RGB saber are used if bnum is 0, but otherwise the values for the second RGB blade are used instead. Could you tell me what's missing?

Link to comment
Share on other sites

I don't see that in code in SaberCode.txt no matter how many times I refresh it. It is in the old version of CG_DoSaber that this MBII code replaces. But no matter because what you're missing is that while you put bnum in the function definition "void CG_DoSaber( vec3_t blade_muz, ...-snip-... int bnum )," you also need to call DoSaber with bnum added in down in CG_AddSaberBlade.

 

Where it said:

CG_DoSaber( fx.mVerts[0].origin, fx.mVerts[1].origin, fx.mVerts[2].origin, fx.mVerts[3].origin, (client->saber[saberNum].blade[bladeNum].lengthMax), (client->saber[saberNum].blade[bladeNum].radius), scolor, renderfx, (qboolean)(client->saber[saberNum].numBlades < 3 && !(client->saber[saberNum].saberFlags2&SFL2_NO_DLIGHT)), (qboolean)(cg_saberTrail.integer > 0) );

 

you need to tack on an int that identifies which saber "bnum" is like this:

CG_DoSaber( fx.mVerts[0].origin, fx.mVerts[1].origin, fx.mVerts[2].origin, fx.mVerts[3].origin, (client->saber[saberNum].blade[bladeNum].lengthMax), (client->saber[saberNum].blade[bladeNum].radius), scolor, renderfx, (qboolean)(client->saber[saberNum].numBlades < 3 && !(client->saber[saberNum].saberFlags2&SFL2_NO_DLIGHT)), (qboolean)(cg_saberTrail.integer > 0), saberNum );

 

Actually bnum is a misnomer since really what they want is "snum" but oh well. Both bnum and snum are used in the code. Bnum should be for like the second blade of a staff instead for a second whole lightsaber.

 

I think the lack of good core in the RGB sabers is either because of neglect my poor RGB saber graphics files have suffered while I was making regular sabers look like I wanted; or else because the RGB stuff conflicts with and/or fails to use some graphics the MBII sabers use called SFX_Sabers/saber_blade.jpg, SFX_Sabers/saber_end.jpg and/or SFX_Sabers.shader.

Link to comment
Share on other sites

*Blinks, rechecks*

 

Huh. I was looking at the wrong function, namely CG_RGBForSaberColor. Regardless, it needs bnum filled out anyway, and gets it filled out by CG_DoSaber via bnum. So I wind up being right anyway.

 

As for bnum in CG_AddSaberBlade, it IS edited. Note:

 

CG_DoSaber( fx.mVerts[0].origin, fx.mVerts[1].origin, fx.mVerts[2].origin, fx.mVerts[3].origin, (client->saber[saberNum].blade[bladeNum].lengthMax), (client->saber[saberNum].blade[bladeNum].radius), scolor, renderfx, (qboolean)(client->saber[saberNum].numBlades < 3 && !(client->saber[saberNum].saberFlags2&SFL2_NO_DLIGHT)), (qboolean)(cg_saberTrail.integer > 0), cent->currentState.clientNum, saberNum );

Link to comment
Share on other sites

I didn't see that before. I must be too tired. Anyway then it's all set as long as int cnum is declared and == cg.clientNum in CG_AddSaberBlade. I had to do that but it might be already in what you've got and just be another thing I missed.

 

Then it works except my cores are still dim even though I tried to fix the graphics. I'm too tired to see what I have to do to fix them tonight. The trails work like MBII and I think the glow too though I forget what it looked like before. The black saber with MBII trails is totally bizarre.

Link to comment
Share on other sites

...As for that declaration to cnum you mentioned... that's actually a bug in OJP Basic itself. Surprise.

 

For some reason the code declares cnum in the middle of the scolor switch's RGB Sabers cases, but forgets to do it in case SABER_RGB, which comes first, and therefore you get that error since it hadn't been declared then. I have no idea why this was done this way, so I added a note to declare cnum at the start of CG_AddSaberBlade.

 

Now then.

 

I believe I fixed every issue in this latest revision, which now comes in a zip since I had to add a .shader file. Do compile as soon as you can. Tell me of any compile errors, I'll eliminate them.

 

...God, this saber code is beyond bloated, I swear. The SFX Saber Code draws multiple sabers on top of each other, and to make it work with RGB I had to nearly double the number of sabers it draws. If anyone can find a way to optimize it that'd be great.

 

http://www.seraphicradiance.net/BB/avaimages/rgbsfxsabers.zip

Link to comment
Share on other sites

It works fine. Nice job, especially without being able to test it as you go.

 

Here're screenshots:

 

http://www.taddia.com/vruki/saberbladepics/rgb_fixedduals_2.jpg

http://www.taddia.com/vruki/saberbladepics/rgb_fixedduals_3.jpg

http://www.taddia.com/vruki/saberbladepics/rgb_fixedduals_4.jpg

 

 

update:

 

Here is what should be a plain OJP basic cgamex86.dll with the RGB MBII sabers:

 

http://www.taddia.com/vruki/cgamex86.dll

 

I haven't tested it yet though. If you do before I do let me know how it works. It should be fine - no more animation problems.

 

(ps. I fixed the links to the pics above) (pps and took out the old bad pic)

Link to comment
Share on other sites

The first fixed duals pic are the old duals with bad cores...

 

Anyhow, I discovered a mistake in the code. I forgot to remove an old shader for the Black Saber, which is causing its trail to render badly, a trail within a trail. Further, the trail is transparent due to... being transparent, which worked on the old weapon but not here. The zip has been updated with the new instructions, but the only differences are the removal of this code in CG_AddSaberBlade:

 

//[RGBSabers]
if(scolor == SABER_BLACK)
fx.mShader = cgs.media.blackSaberTrail;
//[/RGBSabers]

 

If you can't find it, just search for blacksabertrail since I probably just mistyped the rest. You'll see what to remove.

 

And the second difference is in the scolor switch in CG_AddSaberBlade, the SABER_BLACK entry turns into:

 

case SABER_BLACK:
    VectorSet( rgb1, 255.0f, 255.0f, 255.0f );
    break;

 

Let me know if you get a chance to recompile. Thanks for the help.

Link to comment
Share on other sites

Would either of you guys mind making a pk3 of this for enhanced? No matter what do, I cant get anything to compile on Enhanced with VC Express. I have no idea how to set the include stuff to the platform or what ever sushi said to do. Unless you guys can give me step by step instructions, I would really appreciate a workable version on MB2 sabers for Enhanced to be able to be used by non-computer/code savy forum goers.

Link to comment
Share on other sites

Let me see if I can get an update of the enhanced code. I was having CVS troubles with it before.

 

---------

 

OK it updated but I can't do it til later. Check now and again and I'll try to do it tonight.

 

Oops, I forgot I'm a moderator now. I edited your post rather than replaying LOL. I'll say it again here: Thanks.

Link to comment
Share on other sites

OK here you go for enhanced:

 

http://www.taddia.com/vruki/zzz-MB2_style_trails_for_OJP_Enhanced_f.pk3

 

It works.

 

screen:

 

http://www.taddia.com/vruki/saberbladepics/ojpE_MBII_blades.jpg

 

Whatever you want to name this pk3 file, it has to come alphabetically after your OJPE dlls pks loads because it replaces the default cgame dll. Also this pk3 contains no colors so it won't override whatever saber color mods you have, if any.

Link to comment
Share on other sites

You're welcome but it's really the work of those guys who coded it first.

 

One issue with Enhanced and these yo should be aware of is that those special long trails of the "fakes" are gone so it's harder to tell if there's one going on. I have my own interest in adjusting the length of these trails so I'll look into the issue but I haven't any success doing it so far.

Link to comment
Share on other sites

You're welcome but it's really the work of those guys who coded it first.

 

One issue with Enhanced and these yo should be aware of is that those special long trails of the "fakes" are gone so it's harder to tell if there's one going on. I have my own interest in adjusting the length of these trails so I'll look into the issue but I haven't any success doing it so far.

 

Cool, let us know if you have any success. Thanks for doing this, you've done us Enhanced players a good service.

Link to comment
Share on other sites

Huh? If the special trails vanish after SFX is applied, it seems to me that Razor edited CG_AddSaberBlade's CheckTrail portion for Enhanced.

 

EDIT: And he did. Forget about this Razor?

 

	//[saberSys]
if(cent->currentState.userInt3 & (1 << FLAG_ATTACKFAKE))
{//attack faking, have a longer saber trail
	saberTrail->duration *= 2;
}

if( cent->currentState.userInt3 & (1 << FLAG_FATIGUED) )
{//fatigued players have slightly shorter saber trails since they're moving slower.
	saberTrail->duration *= .5;
}
//[/saberSys]

 

The thing is, SFX totally IGNORES saberTrail->duration. It just sets it to 0 and leaves it.

 

To fix it, you'll have to edit this part of SFX:

 

fx.mShader = cgs.media.SaberTrailShader;
fx.mKillTime = 0;

 

The thing is, SFX's default trails are EXPLICITLY set short. You can't go lower than zero to display fatigue, so your only choice is to mod SFX a bit and make its default fx.mKillTime 1.

 

fx.mShader = cgs.media.SaberTrailShader;
fx.mKillTime = 1;
//[saberSys]
if(cent->currentState.userInt3 & (1 << FLAG_ATTACKFAKE))
{//attack faking, have a longer saber trail
fx.mKillTime *= 2;
}

if( cent->currentState.userInt3 & (1 << FLAG_FATIGUED) )
{//fatigued players have slightly shorter saber trails since they're moving slower.
fx.mKillTime *= .5;
}
//[/saberSys]

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...