To practice what I suggested earlier, I'm starting these types of threads to have a specific area where developers can discuss what we think is the best doable system for certain areas of the game.

Anyone is allowed to contribute to the discussion but please be sure to be reasonable with the ideas, read the whole thread before posting, and stay on topic.

This particular thread deals with how we should handle the saber hilts/blades/sounds/etc.

Personally, I think the best solution would be to add the following features:

- selectable RGB blade colors

- selectable blade types - The saber hilt file would have an override if it doesn't have a blade at all (for solid weapons). There's also be a saber glow disable option in the saber files for the same purpose. You'd probably have a file to name the blades.

Since hilts need to be downloaded to be seen, if you don't want to see the melee weapons, just don't download them.

- selectable saber sounds - Saber files would have an override option for this as well (for melee weapons). The sounds would be controlled by a new file type.

- selectable blade length - There's obviously have to be some sort of balancing mechanism here. I suggest that the length of the blade would determine the number of skill points that you need to put into Saber Attack/Saber Defense. This could also be used to balance out the double/dual sabers.

There's also have to be a max blade limit. Probably something like 150% of normal although the minimum would be much lower (probably one or something).

Apparently you have to add a line in the player.npc file: saber sith_sword
to get the sith sword to work in the game without it crashing.

Original post (http://www.lucasforums.com/showthread.php?s=&postid=1368680#post1368680)

Thought it would be useful to let you guys know this...

Here's how I am thinking it should go. There would not really be any CVars for console aside from the ones that puts everything back to the defaults.

What you would do is have a variable for each saber characteristic in the saber (.sab) config file. This would allow sabers like old bens hilt to have the same blade, sounds, etc; etc. that his hilt did in the movie. The variables for the .sab files would be...

saberType: SABER_REVERSE
The saberType variable is already coded, the SABER_REVERSE portion is what's new.

The Adi Gallia character uses a reversed single saber as her weapon. Lee & I did a bit of work with this in Duelers & the Tavion & Desann stances seemed to work pretty well with this concept. It would take a bit of tweaking & I would have to create hilts specifically for this but all in all it should be a nice addition to the project & shouldn't take that much effort to make happen.

soundBounce, soundHitwater, soundRainfizz, soundCatch, soundSaberblock, soundSaberbounce, soundSaberhit, soundSaberhitwall, soundSaberup, soundSaberspin, & soundSaberspinoff
These are all the various sounds that the saber config files do not cover but should, especially the saberup (saber swing) sounds.

Alot of these are multiple sounds like saberup1, saberup2, etc; etc. so what you would enter into the variable would be something like "sound/weapons/saber_jk1/saberup%n.wav" if this was the old ben hilt (the JK1 sounds are the same sounds used in the original SW trilogy). The "%n" variable would be filled in by the code because these various saber sounds get played randomly. Also, if there is no .wav file, the code automatically replaces it with any .mp3 file with the same filename. Again, there should be a CVar (in console) that disables all of this & plays the default sounds only; In which case, the user obviously has an option to use any third party sound mods.

Obviously if you did not enter anything in any of these variables it would use the default.

Example:
soundSaberup "sound/weapons/saber_jk1/saberup%n.wav"

Or you could set it up so the only thing you need to change is the path...

soundSaberup "sound/weapons/saber_jk1"

This way, it would save a little effort as far as the filenames go.

saberBlade
This would be the path to the saber blade textures, NOT THE HILT, the actual blade.

Example:
saberBlade "models/weapons2/saber_oldben"

Again, this would not point it to any specific files, this would only point to the path that would replace the blue_glow2.jpg, blue_line.jpg, blurcore.jpg, blurglow.jpg, green_glow2.jpg, green_line.jpg, orange_glow2.jpg, orange_line.jpg, purple_glow2.jpg, purple_line.jpg, red_glow2.jpg, red_line.jpg, swordtrail.jpg, yellow_glow2.jpg, yellow_line.jpg, yellow_glow.tga, & any other files that are used by the RGB scale as well.

Disabling the hilt specific saberblades is not the same thing is disabling the RGB scale. That would be a seperate CVar (FYI).

noBlade
This would add a new sabercolor which is actually just a transparent blade. This should ONLY be enabled for hilts that are sword hilts, or something similar.

Setting this to 0 would disable the option & setting it to 1 would enable it.

defaultColor
This is pretty self-explanitory. When you choose a hilt, it goes to this color. It should cover standard colors, RGB colors, & the noBlade.

There should also be a CVar for console that disables this feature. Some people might be pissed if they set their colors the way they like them & then this thing goes & changes it. The CVar for console should default this feature to off.Originally posted by razorace
Since hilts need to be downloaded to be seen, if you don't want to see the melee weapons, just don't download them.I like the idea of removing sword-type hilts. I did get a complaint about them before (of course, the guy was losing at the time). I think I might put all of the sword hilts in its own pack, however, not with the non-standard hilts.Originally posted by razorace
- selectable blade length - There's obviously have to be some sort of balancing mechanism here. I suggest that the length of the blade would determine the number of skill points that you need to put into Saber Attack/Saber Defense. This could also be used to balance out the double/dual sabers.I think this should just be tied to a specific kind of hilt like the Bustersword 2k hilt (which I have to redo because Chrono is a groupie).

Any of these types of hilts will be in the non-standard hilt pack. When you join a server you want to be assured that there is fair gameplay, you don't want someone using the ninja hilt (no glowing blade) then scaling the saber length up = ghey.

Making a CVar that allows the hilt to be very long defeats the purpose of the Standard Hilts pack IMO. You shouldn't be forced to play in that manner regardless of the server settings IMO.

Anyways, how you would balance it out is the longer the saber blade is, the less damage it can do. We might also need to make it so that the thing can be parried easier too. I saw someone else had made a Sai hilt, which I do like the concept of but it belongs in the non-standard hilt pack. The Sai's would do more damage since they are smaller.

IMPORTANT NOTE: Another big problem I see with handling the hilts in packs like this is if someone does not want to duel with non-standard hilts, they will not use the non-standard hilt pack but the server & opponent both do have the hilt pack, this may cause complications & piss some people off, especially with longer bladed sabers.

Perhaps we should include some sort of coding or variables that prevent non-standard hilt usage if an opponent chooses not to use them.Originally posted by Samuel Dravis
Apparently you have to add a line in the player.npc file: saber sith_sword
to get the sith sword to work in the game without it crashingyou don't need to edit the player.npc file, I've got it to work in-game with no problems aside from the glowing blade showing up.

I agree with the additional sound varibles and the issue of saber length/disable glow/blade, but I think the sounds and blade should be modifable from the menu by default. We want people to have as many options as possible.

As for saber length balancing, what's wrong with different skill point requirements? It's more realistic than damage scaling and is less confusing.

As for noblade, since we're going to have to do code work anyway, it would make more sense to actually disable the blade rendering instead of just making it invisible.

Finally, about cheating/abuses, simply putting the commands in the .sab files isn't going to cut the mustard since even a monkey can alter the .sab files and the server isn't guarnteed to have the hilt. My suggestion would be to....

a) Make sure that the saber blades render the same size as the hit detection length.

b) For disabled blade weapons, just force render the blade if the client doesn't have the hilt model. If someone is cheating by altering the the blade length of an invisible blade weapon, the clients could just force render the blade.

Originally posted by razorace

Personally, I think the best solution would be to add the following features:

- selectable RGB blade colors

- selectable blade types

- selectable saber sounds

- selectable blade length

I have plans along those same lines...I think it's the way to go. But remember that RGB colors won't be compatible with most of the blade skins that are made, unless they have a code-based convention to follow.

Well, if you're planning on doing that system, I could not work on it and do the saber system instead (like my original plan).

You have a good point there. Since we get to set the standard, we can do whatever need to be done. :)

Originally posted by razorace
Well, if you're planning on doing that system, I could not work on it and do the saber system instead (like my original plan).

You have a good point there. Since we get to set the standard, we can do whatever need to be done. :)
Tchouky has a nice format that i modified slightly - he may well have the first RGB mod out if/when the sdk is released.

It's not a matter of being first; It's a matter of doing it right.

Just because it was done first doesn't mean it wasn't done right.

It's a matter of redundancy: Tchouky did it right the first time and was generous with his code; he'll likely do so again, do it first, and may be willing to contribute to your project.

Ya, it's nice to have developers in the community that are not selfish pricks & donate their work for everyone in the community. Now I'm not mentioning any names *cough*Lee Oattes*cough* because that would only be something someone who is bitter would do; But they are out there. :-)

As Forum moderator, I'm going to have to ask you to please not slam other people. I know you've had personal issues with Lee in the past but please keep it out the OJP forums. I believe we all know about it already. :)

Thank you.

Well regarding the saber blade length, I good realistic way of dealing with it is making the longer blade harder and slower to control. I know lightsaberblades have no mass and all but it would be for the best to assume they do.

I'd make them move like the red stance... like slow and cumbersome. Just like a two handed 6 foot sword, in medieval times they were used on mounted horses and on ground to BASH and keep enemies at bay. On close encouters that sword was really more of a disadvantage than an advantage.

I don't think that's a good idea. Slowing down the saber speed isn't realistic and would saber dynamic issues especially with the JKA system. You'd be trying to attack and the other guy would be constantly hitting you or forcing you into blocks.

Believe it or not guys almost all of this stuff is already programmed into the game... all we need to do is figure out how to manipulate the files for the sabers.

Uh dude, while some of it is as part of the *.sab files, it's not remotely set up for an ingame selectable system.

Hopefully it will be easy to do. :)

I see your point Razor... well then i guess it will have to be balanced out some other way. Damage or defense I reckon. Higher range vs Damage and/or Defense maybe?

Originally posted by BloodRiot
Damage or defense I reckon. Higher range vs Damage and/or Defense maybe?
Longer == less damage?, that sounds simple and effective Riot.

I still think the balancing factor should be with skill points. Damage levels aren't very visially obvious and will probably feel wrong.

Well another way of putting it would be making all saber blade deal the same ammount of damage... then apply the hit location modifier. Make the yellow swing speed the base speed for all stances. Then make the stances nothing more that a style of fighting. one of the stances enables longer blade and the apropriate swings for a longer blade... logic tells me they would be pretty straight forward swing since the blade is too long to allow pretty swirls and such.

On another issue... why not getting rid of the stances altogether and create a move list... then the more points you assign to force offense and defense, the more moves you can pick from the list. So a guy with force offense and defense at max could pick from... let's say 5 or 6(example) from all the available moves for all sabers, and that could work well with them all as well(counting cartwheels, stabing rolls, katas, lunges, dfa's, kicks, punches, grapples, everything), thus granting a player it's own individual style. I can go as far as creating more moves as well.

So, you can select the moves as you would with force powers... now what... well let's say a longer blade DOES grant you advantage... then make the longer blade cost something like 2 or 3 times more than a move you could select.

I may be pushing the envelope here.. i wouldn't know... just throwing stuff into this thread so u can consider if you want to.

Cheers.

I guess I'll speak up. I made the sai saber as a multiblade test.

If it helps these are the things I found out.

multibladed sabers can use any stance. ie:all 7. But only two at a time.

This includes if you can't even see the saber. I made a couple of multibladed sabers classified as single sabers but hid the blades. ie made them really small and overlapping the first.

This gave me the option of giving it the tavion stance and desann stance if I wanted. That is why the sai use the dual stance even if using only one.

Also here is a site catalogging all the hilts. Please email the guy if he hasn't given credit to something you made.

http://jk3hilts.evilzz.net/)

Originally posted by BloodRiot
Stuff

Yeah, that's a bit off topic. It belongs in a thread just about the actual Saber System. I'll go start a thread about it now.

Kenshire: How does the game determine which two stances you can use in multibladed weapons? The .sab file?

Yep, the .sab file.

Here's the break down.

name //spawn name.

{
name //can be pointed at menu or put in quotes

saberType //saber_single,saber_staff,sith_sword *only used in single player*

saberModel //obvious

soundOn //obvious

soundLoop //the idle sound

soundOff //obvious

saberColor //Only used in single when spawned with npcs

numBlades //up to 7

saberLength // length
saberRadius // radius *apparently this can be -1 giving only glow*

saberStyle //any seven stances, only multibladed weapons can use tavion or desann.

throwable //0 or 1, turning this off doesn't allow kicks. Which I think it should.

singleBladeStyle //Any seven stances, used when multibladed goes to single.

singleBladeThrowable //For multibladed weapons.

brokenSaber1 //points to spawn name of first half
brokenSaber2 //points to spawn name of second half

twoHanded //0 or 1, classifies it in the staff category and puts force restrictions on it in single player.
}


am I missing anything?

hmmm interesting. Half these commands were never listed in the main saber.sab

{
name "Battle Axe"
saberType SABER_SINGLE
saberModel "models/weapons2/axe1/axe1.glm"
soundOn "sound/weapons/sword/draw1.wav"
soundLoop "sound/effects/null.wav"
soundOff "sound/weapons/sword/swing4.wav"
numBlades 3
saberLength 22
saberRadius 4
saberLength2 18
saberRadius2 3
saberLength3 12
saberRadius3 2
saberstylelearned strong
saberstyleforbidden fast
saberstyleforbidden medium
saberstyleforbidden tavion
saberstyleforbidden dual
saberstyleforbidden staff
twohanded 1
throwable 0
noWallMarks 1
noDlight 1
noBlade 1
noClashFlare 1
trailStyle 1
g2MarksShader "gfx/damage/bloodcutmark"
g2WeaponMarkShader "gfx/effects/bloodsplat"
spinSound "sound/weapons/saber/saberspinoff.wav"
swingSound1 "sound/weapons/sword/swing_low1.wav"
swingSound2 "sound/weapons/sword/swing_low2.wav"
swingSound3 "sound/weapons/sword/swing_low3.wav"
hitSound1 "sound/weapons/sword/stab_hard1.wav"
hitSound2 "sound/weapons/sword/stab_hard2.wav"
hitSound3 "sound/weapons/sword/stab_hard3.wav"
blockSound1 "sound/weapons/sword/block_low1.wav"
blockSound2 "sound/weapons/sword/block_low2.wav"
blockSound3 "sound/weapons/sword/block_low3.wav"
blockEffect "sparks/spark.efx"
hitPersonEffect "sword/hitperson.efx"
hitOtherEffect "sparks/spark.efx"
noIdleEffect 1
knockbackScale 1
damageScale 2
breakParryBonus 1
parryBonus 1
lockable 0
lockBonus -1
blocking 0
disarmBonus 1
onInWater 1
bounceOnWalls 1
moveSpeedScale 0.8
animSpeedScale 0.8
noStabDown 1
noManualDeactivate 1
}

So this was hidden somewhere in the patch.

//===The following fields were added after retail version:========================================== =================================
//these values are global to the saber, like all of the ones above

//done in cgame (client-side code)
spinSound none - if set, plays this sound as it spins when thrown
swingSound1 - swingSound3 none - if set, plays one of these 3 sounds when swung during an attack - NOTE: must provide all 3!!!
fallSound1 - fallSound3 none - if set, plays one of these 3 sounds when weapon falls to the ground - NOTE: must provide all 3!!!
onInWater 0 - if set, weapon stays active even in water

//done in game (server-side code)
bounceOnWalls 0 - if non-zero, the saber will bounce back when it hits solid architecture (good for real-sword type mods)
moveSpeedScale 1.0 - you move faster/slower when using this saber
animSpeedScale 1.0 - plays normal attack animations faster/slower
boltToWrist 0 - if set, saber model is bolted to wrist, not in hand... useful for things like claws & shields, etc.

//replace certain anims
readyAnim none - anim to use when standing idle (use name of enum in anims.h or BehavEd's list)
drawAnim none - anim to use when drawing weapon (use name of enum in anims.h or BehavEd's list)
putawayAnim none - anim to use when putting weapon away (use name of enum in anims.h or BehavEd's list)
tauntAnim none - anim to use when hit "taunt" (use name of enum in anims.h or BehavEd's list)
bowAnim none - anim to use when hit "bow" (use name of enum in anims.h or BehavEd's list)
meditateAnim none - anim to use when hit "meditate" (use name of enum in anims.h or BehavEd's list)
flourishAnim none - anim to use when hit "flourish" (use name of enum in anims.h or BehavEd's list)
gloatAnim none - anim to use when hit "gloat" (use name of enum in anims.h or BehavEd's list)

//optionally disallow certain types of moves and attacks
noRollStab 0 - if set, cannot do roll-stab move at end of roll
noPullAttack 0 - if set, cannot do pull+attack move (move not available in MP anyway)
noBackAttack 0 - if set, cannot do back-stab moves
noStabDown 0 - if set, cannot do stabdown move (when enemy is on ground)
noWallRuns 0 - if set, cannot side-run or forward-run on walls
noWallFlips 0 - if set, cannot do backflip off wall or side-flips off walls
noWallGrab 0 - if set, cannot grab wall & jump off
noRolls 0 - if set, cannot roll
noFlips 0 - if set, cannot do flips
noCartwheels 0 - if set, cannot do cartwheels
noKicks 0 - if set, cannot do kicks (can't do kicks anyway if using a throwable saber/sword)
noMirrorAttacks 0 - if set, cannot do the simultaneous attack left/right moves (only available in Dual Lightsaber Combat Style)

//done in both cgame and game (BG code)
kataMove 0 - if set, player will execute this move when they press both attack buttons at the same time (see list below for valid values)
lungeAtkMove 0 - if set, player will execute this move when they crouch+fwd+attack (see list below for valid values)
jumpAtkUpMove 0 - if set, player will execute this move when they jump+attack (see list below for valid values)
jumpAtkFwdMove 0 - if set, player will execute this move when they jump+fwd+attack (see list below for valid values)
jumpAtkBackMove 0 - if set, player will execute this move when they jump+back+attack (see list below for valid values)
jumpAtkRightMove 0 - if set, player will execute this move when they jump+rightattack (see list below for valid values)
jumpAtkLeftMove 0 - if set, player will execute this move when they jump+left+attack (see list below for valid values)
//NOTE: these "move" fields refer to saber moves that are defined in code. Set to LS_NONE to have the normal move removed, set to one of the following values to override the current move
LS_NONE - Do a regular attack instead of a special move (overrides the usual special move with a normal attack)
// Attacks
LS_A_TL2BR
LS_A_L2R
LS_A_BL2TR
LS_A_BR2TL
LS_A_R2L
LS_A_TR2BL
LS_A_T2B
LS_A_BACKSTAB
LS_A_BACK
LS_A_BACK_CR
LS_ROLL_STAB
LS_A_LUNGE
LS_A_JUMP_T__B_
LS_A_FLIP_STAB
LS_A_FLIP_SLASH
LS_JUMPATTACK_DUAL
LS_JUMPATTACK_ARIAL_LEFT
LS_JUMPATTACK_ARIAL_RIGHT
LS_JUMPATTACK_CART_LEFT
LS_JUMPATTACK_CART_RIGHT
LS_JUMPATTACK_STAFF_LEFT
LS_JUMPATTACK_STAFF_RIGHT
LS_BUTTERFLY_LEFT
LS_BUTTERFLY_RIGHT
LS_A_BACKFLIP_ATK
LS_SPINATTACK_DUAL
LS_SPINATTACK
LS_LEAP_ATTACK
LS_SWOOP_ATTACK_RIGHT
LS_SWOOP_ATTACK_LEFT
LS_TAUNTAUN_ATTACK_RIGHT
LS_TAUNTAUN_ATTACK_LEFT
LS_KICK_F
LS_KICK_B
LS_KICK_R
LS_KICK_L
LS_KICK_S
LS_KICK_BF
LS_KICK_RL
LS_KICK_F_AIR
LS_KICK_B_AIR
LS_KICK_R_AIR
LS_KICK_L_AIR
LS_STABDOWN
LS_STABDOWN_STAFF
LS_STABDOWN_DUAL
LS_DUAL_SPIN_PROTECT
LS_STAFF_SOULCAL
LS_A1_SPECIAL
LS_A2_SPECIAL
LS_A3_SPECIAL
LS_UPSIDE_DOWN_ATTACK
LS_PULL_ATTACK_STAB
LS_PULL_ATTACK_SWING
LS_SPINATTACK_ALORA
LS_DUAL_FB
LS_DUAL_LR
LS_HILT_BASH

//***these values can be specified differently for different blades (see "bladeStyle2Start" below for more info)***

//done in cgame (client-side code)
noWallMarks 0 - if 1, stops the saber from drawing marks on the world (good for real-sword type mods)
noDlight 0 - if 1, stops the saber from drawing a dynamic light (good for real-sword type mods)
noBlade 0 - if 1, stops the saber from drawing a blade (good for real-sword type mods)
noClashFlare 0 - if non-zero, the saber will not do the big, white clash flare with other sabers
trailStyle 0 - default (0) is normal, 1 is a motion blur and 2 is no trail at all (good for real-sword type mods)
g2MarksShader none - if set, the game will use this shader for marks on enemies instead of the default "gfx/damage/saberglowmark"
hitSound1 - hitSound3 none - if set, plays one of these 3 sounds when saber hits a person - NOTE: must provide all 3!!!
blockSound1 - blockSound3 none - if set, plays one of these 3 sounds when saber/sword hits another saber/sword - NOTE: must provide all 3!!!
bounceSound1 - bounceSound3 none - if set, plays one of these 3 sounds when saber/sword hits a wall and bounces off (must set bounceOnWall to 1 to use these sounds) - NOTE: must provide all 3!!!
blockEffect none - if set, plays this effect when the saber/sword hits another saber/sword (instead of "saber/saber_block.efx")
hitPersonEffect none - if set, plays this effect when the saber/sword hits a person (instead of "saber/blood_sparks_mp.efx" in MP and "sparks/blood_sparks2" in SP)
hitOtherEffect none - if set, plays this effect when the saber/sword hits something else damagable (instead of "saber/saber_cut.efx")

//done in game (server-side code)
knockbackScale 0 - if non-zero, uses damage done to calculate an appropriate amount of knockback
damageScale 1 - scale up or down the damage done by the saber
noDismemberment 0 - if non-zero, the saber never does dismemberment (good for pointed/blunt melee weapons)
noIdleEffect 0 - if non-zero, the saber will not do damage or any effects when it is idle (not in an attack anim). (good for real-sword type mods)
splashRadius 0 - radius of splashDamage
splashDamage 0 - amount of splashDamage, 100% at a distance of 0, 0% at a distance = splashRadius
splashKnockback 0 - amount of splashKnockback, 100% at a distance of 0, 0% at a distance = splashRadius
alwaysBlock 0 - if set, the blades will always be blocking (good for things like shields that should always block)
noManualDeactivate 0 - if set, the blades cannot manually be toggled on and off (does not affect turning the whole saber on/off, just hitting the saber style cycle button when using dual sabers or a multi-blade saber)

//***The following can be different for the extra blades - not setting them individually defaults them to the value for the whole saber (and first blade)***
//***NOTE: you can only have a maximum of 2 "styles" of blades, so this next value, "bladeStyle2Start" is the number of the first blade to use these value on... all blades before this use the normal values above, all blades at and after this number use the secondary values below***
bladeStyle2Start 0 - if set, blades from this number and higher use the following values (otherwise, they use the normal values already set)

//done in cgame (client-side code)
noWallMarks2 0 - if 1, stops the saber from drawing marks on the world (good for real-sword type mods)
noDlight2 0 - if 1, stops the saber from drawing a dynamic light (good for real-sword type mods)
noBlade2 0 - if 1, stops the saber from drawing a blade (good for real-sword type mods)
noClashFlare2 0 - if non-zero, the saber will not do the big, white clash flare with other sabers
trailStyle2 0 - default (0) is normal, 1 is a motion blur and 2 is no trail at all (good for real-sword type mods)
g2MarksShader2 none - if set, the game will use this shader for marks on enemies instead of the default "gfx/damage/saberglowmark"
hit2Sound1 - hit2Sound3 none - if set, plays one of these 3 sounds when saber hits a person - NOTE: must provide all 3!!!
block2Sound1 - block2Sound3 none - if set, plays one of these 3 sounds when saber/sword hits another saber/sword - NOTE: must provide all 3!!!
bounce2Sound1 - bounce2Sound3 none - if set, plays one of these 3 sounds when saber/sword hits a wall and bounces off (must set bounceOnWall to 1 to use these sounds) - NOTE: must provide all 3!!!
blockEffect2 none - if set, plays this effect when the saber/sword hits another saber/sword (instead of "saber/saber_block.efx")
hitPersonEffect2 none - if set, plays this effect when the saber/sword hits a person (instead of "saber/blood_sparks_mp.efx" in MP and "sparks/blood_sparks2" in SP)
hitOtherEffect2 none - if set, plays this effect when the saber/sword hits something else damagable (instead of "saber/saber_cut.efx")

//done in game (server-side code)
knockbackScale2 0 - if non-zero, uses damage done to calculate an appropriate amount of knockback
damageScale2 1 - scale up or down the damage done by the saber
noDismemberment2 0 - if non-zero, the saber never does dismemberment (good for pointed/blunt melee weapons)
noIdleEffect2 0 - if non-zero, the saber will not do damage or any effects when it is idle (not in an attack anim). (good for real-sword type mods)
splashRadius2 0 - radius of splashDamage
splashDamage2 0 - amount of splashDamage, 100% at a distance of 0, 0% at a distance = splashRadius
splashKnockback2 0 - amount of splashKnockback, 100% at a distance of 0, 0% at a distance = splashRadius
alwaysBlock2 0 - if set, the blades will always be blocking (good for things like shields that should always block)
noManualDeactivate2 0 - if set, the blades cannot manually be toggled on and off (does not affect turning the whole saber on/off, just hitting the saber style cycle button when using dual sabers or a multi-blade saber)
//================================================== ================================================== =====================================

That's pretty interesting. I wonder how much of that stuff actually works.

Well just looking through the WP_SaberParseParm function in the source code most of it should work or has support to work. The only thing that has been removed is the BrokenSaber1/2 option.

The saber info is collected from the .sab file into a struct which is defined in the q_shared.h file (the unmodifiable file!) and both the BrokenSaber1 and BrokenSaber2 vars have been commented out. So if we need this option we'd have to find a custom way of doing it.

Uh, dispite claims, I'm pretty sure you can change the q_shared.h without problems.

I tried posting this before, but there were some internet problems and I don't think it got through.

But I was wondering, would it be possible to make a multi-colored saber staff? Ie, on one end a green blade, and on the other yellow?

I tried modifying the menu scripts to do that, but methinks more than that may be required.

-TiM

Yeah, I don't think it would be hard to do.

Yes I've added that functionality to my RGB Saber Color code. If only there was some suitable place to position the rgb sliders in the main saber menu, and we could adjust the length of the sliders themselves.

Well, you can free up a lot of menu space by toggling off the default blade colors area of the menu when doing RGB colors.

And by just making the menu a bit bigger.

Yeah, but that would be obvious! :D

Hehe, indeed...but strangely not the first idea presented. =]

Well, I prefer to not physically change the size of menus if I don't have to. It can cause issues with making it look right.

Let's bump this back up to the top now that the discussion is in full swing concerning it.

I don't know much about coding or advanced scripting but I think this idea is doable possibly easy to accomplish, options in the sab file for each blade, like which show up as saber blades and which do not.

I just had an idea occur to me. Can we create a new tag to be added to new models to that we can bolt weapons and hilts onto? Like bolt_holster? Then model makers could set where the holster is themselves.

It's possible that we could make this retroactive with older models. Going in and adding the tags our selves and re-weighting the model.


*edit*
Testing purposes, not in-game as of yet. I need to rotate the tag set for the guns though. Because they point straight out. Also ignor ethe weighting on this model I literally did it in 5 minutes. (Just ask Razor)

http://mediaservice.photoisland.com/auction/Feb/20042262943615147619737.jpg)

Bolting huh? Something needed when switching from two saber style to one. I'm put off when I see the left saber attached to the wrist when I grip cannon fodder. Kinda kills the screenshot moment.

Yep this method has a lot of plusses and functionality.

saber/gun on each side of hip, leg, etc
staff/rocket launcher draped across back.

We just need a standard right now.

So far Razor suggested

holster_saber
holster_blaster

I think we need a
holster_saber2, holster_staff and a holster_launcher to account for the bigger weapons and dual saber.

http://mediaservice.photoisland.com/auction/Feb/20042274336783273048947.jpg)

Lookin' good. People using sword packs will love this.

As for a standard, I'm right handed so for me drawing/holstering a weapon from the back would be opposite of what you have pictured. Of course I'm not the one doing the coding, so I'll let ya get back to what you're doing.

I'm thinking the holstering/'placing saber on hip' should be done through a command--emote, whatever you'd call it. You'd have some emote to place the saber on your belt, then perhaps you'd do the same command again and the saber would be back in your hand. It just seems clumsy taking your saber off and then trying to ignite it in time to parry a coming attack.

Currently we have no animation for the holstering/unholstering. BUT...You can experiment by trying different animation entries in the saber definition files under the Draw and put away entries.

As for a standard, I'm right handed so for me drawing/holstering a weapon from the back would be opposite of what you have pictured.

Razor just added the code to place the saber on the tag. The tag has to be manually added to the model. SO...it's up to the model maker where the holster tags are located. I'm ambi so it didn't matter for me. Unfortunately you can't have it both ways because you can't flip models around the tag.

You're ambidextrous? Curse you! <shakes right fist in air> ;)

At least I didn't say something really stupid like, having both staff and rifle or more bolted to the back.

"I can't see my character due to all these damn guns. First person POV it is!"

I think there was a plan to base it on the most damaging weapon not in use. But honestly I didn't think that far ahead when I came up with the idea. :D

It just occurred to me that shared tags probably won't look right because the rocket launcher's model is bigger than the others. I suggest that we maybe just have a tag for each weapon and then let the modellers decide which ones to set up for the model.

Thats a lot of tags. I guess they can choose to support certain weapons or not.

Hopefully we can get around this by offsetting them from current tags. Its a lot less inconvinient that way.

http://mediaservice.photoisland.com/auction/Feb/20042283186642812816056.jpg)

Some screenshots taken of the in-game code. Lookin good. next up will be the rest of the weapons. Added in. If I'm quick enough with some models hopefully this is in by next enhanced release. We'll see though.