Like I said. the game balance changing flags in the .sabs shouldn't even be there.
In fact they weren't until the patch.
Pull out the scaling and splash flags and that should solve any problem you have. This should be done for the base game if you ask me. Its just as bad as abusive admin commands.
Take those out and add in creative ways of further customizing hilts and players should be satisfied. And cheating should be averted.
*edit*
Also length and radius of the blade should be limited. Make it go up in steps of five and it should be obvious if someone changes it. Unlike now where it can be altered by one or two with no noticable effect.
Wudan is correct. Please move this non-animation discussion to another thread or forum. I see that Kenshire has already bumped up the approprate thread (here (
http://www.lucasforums.com/showthread.php?s=&threadid=117038)) for you to use.
Originally posted by keshire
Like I said. the game balance changing flags in the .sabs shouldn't even be there.Well I see where Raven was going with this & think it's a cool idea, I just don't think it should be set up as it is. Hardcode would have been a better way of handling this. With the way it is now, it just leaves too much room for cheating.Originally posted by keshire
In fact they weren't until the patch.Actually that's not true. Alot of these features were available before the patch it's just that there was alot more available after the patch; Or at least that's what the saber documentation states.Originally posted by keshire
Pull out the scaling and splash flags and that should solve any problem you have. This should be done for the base game if you ask me. Its just as bad as abusive admin commands.#1) I agree with you that the base game should be set up this way (because all other mods would be set up in the same manner), however, the base game is Raven's territory & we're obviously not going to be modifying that. Now I don't think you were suggesting we should, I just wanted to clarify.
#2) I'm not looking to take away features. If someone wants to host this type of game I think that's fine, however, the client has the right to know if that's the type of game being hosted before they even join. That's what this will accomplish.Originally posted by keshire
Take those out and add in creative ways of further customizing hilts and players should be satisfied. And cheating should be averted.
*edit*
Also length and radius of the blade should be limited. Make it go up in steps of five and it should be obvious if someone changes it. Unlike now where it can be altered by one or two with no noticable effect.The radius & length are already capped. Here's what I have in mind for the settings...
Level 1 Protection Allows
I'm not including the variables that will have no protection against them such as saberType (i.e. staff/single), saberModel (path to the model), saberColor, various sound variables, etc; etc. These are the types of variables that all levels of protection allow (level 0 is no protection, 1 or 2 will be the default). I'm only including the grey area type variables in the level 1 protection list section.
twoHanded: Whether or not it requires 2 hands (makes it restrict force powers but makes it stronger in locks or parries).
When this is enabled, "numBlades" is automatically set to 2.
noIdleEffect: When set to 0, this allows the saber to do idle damage like it did in JK2, now I don't know about the rest of you but I don't know why this was ever defaulted to enabled. I can see why with sword-type hilts, but not lightsaber blades.
Level 2 Protection Allows
This is mainly intended for permitting sword-type hilts to be used.
twoHanded: This is setup exactly the same as when the .sab protection CVar is set to 1.
bounceOnWalls: Allows blades to bounce off of walls instead of going through them.
noWallMarks/noWallMarks2: Self-explanitory.
noDlight/noDlight2: No dynamic lighting (reflection of light blade on the floor, walls, etc; etc.)
noBlade/noBlade2: No light blade.
noClashFlare/noClashFlare2: The saber will not do the big, white clash flare with other sabers.
noManualDeactivate: Sabers can not manually be enabled/disabled.
onInWater: Weapon stays active even in water.
I like this feature but for sword-like hilts, I think the animspeed should be reduced when in water.
Level 3 Protection Allows
This is for permitting small variances on some of the hilts, such as it can use blue lunge & yellow dfa in any stance, however, all other specials are not permitted or it can use blue lunge & red dfa in any stance, however, all other specials are not permitted, as well as blue stance etc; etc. All of these types of hilts will be signified by the name of the hilt like 1-Luke or something similar.
saberStyle: What one style it's limited to, if any.
saberStyleLearned: What styles they should get when they are given this saber.
saberStyleForbidden: What styles *cannot* be used with this saber.
forceRestrict: What force powers it restricts.
singleBladeStyle: Makes it so that you use a different style if you only have the first blade active.
singleBladeThrowable: Makes it so that you can throw this saber if only the first blade is on.
noRollStab: Self-Explanitory.
noPullAttack: Self-Explanitory.
noBackAttack: Self-Explanitory.
noStabDown: Self-Explanitory.
noWallRuns: Self-Explanitory.
noWallFlips: Self-Explanitory.
noWallGrab: Self-Explanitory.
noRolls: Self-Explanitory.
noFlips: Self-Explanitory.
noCartwheels: Self-Explanitory.
noKicks: Self-Explanitory.
noMirrorAttacks: Self-Explanitory.
kataMove: Choose which move for both attack buttons.
lungeAtkMove: Choose which move for crouch+fwd+attack.
jumpAtkUpMove: Choose which move for jump+attack.
jumpAtkFwdMove: Choose which move for jump+fwd+attack.
jumpAtkBackMove: Choose which move for jump+back+attack.
jumpAtkRightMove: Choose which move for jump+right+attack.
jumpAtkLeftMove: Choose which move for jump+left+attack.
Level 4 Protection Allows
Just because I've been at this post for a really long time, we're just going to forget about level 4 for now, perhaps add onto it in the future.
Originally posted by razorace
Wudan is correct. Please move this non-animation discussion to another thread or forum. I see that Kenshire has already bumped up the approprate thread (here (
http://www.lucasforums.com/showthread.php?s=&threadid=117038)) for you to use. I see what you are saying but this thread is about AnimPack (which is the "New Animations Project"), not just animations alone. If you want to keep this thread about animations only then I guess I'm done posting here until someone gets something done or I can finally be finished with this LAN (which is depressingly time consuming) & I can get something done myself.
Also, that thread is not exactly the same thing as what I am talking about here. That thread is a bunch of concepts that weren't implimented at the time (or we just didn't know about) & are now available with the patch; For the most part anyways.
How exactly does .sab file modification allow you to cheat? Do you actually say that the JA server -trusts- the client with the data?
From my experience, the only thing client-side .sab files are used for is for rendering purposes. The other parameters are set and controlled by a server, including -actual- number of blades (if you can see it, it does not mean that the server can), the damage and the length/radius. If the person has an extra .sab file that the server does not have, afaik it either does not let them choose it, or counts their saber as the default type.
However, if the server -trusts- the client with that data, then all of the above is wrong, and the FIRST and FOREMOST goal should be on getting this to be controlled fully server-side.
Originally posted by ASk
How exactly does .sab file modification allow you to cheat?You can go into the .sab for the reborn hilt (for example) & set "damageScale 1.15". That sets the damage 15% higher than the standard hilt damage. If this type of change isn't made to the other hilts, than it is obviously 15% stronger than the other hilts.
Again, in an FFA game this would totally go unnoticed. Perhaps people would catch on in a Duel game but I certainly wouldn't say anyone would for sure.Originally posted by ASk
Do you actually say that the JA server -trusts- the client with the data?I'm not sure what you mean by this. If you mean does the server trust info from the client then it's not a matter of that because this info is completely server-side - not client.Originally posted by ASk
From my experience, the only thing client-side .sab files are used for is for rendering purposes.Certain things are client side, certain things are server side. For example, the number of blades, the width, the damage, etc; etc. is all server side. What sounds to use, whether or not to permit the glow, etc; etc. is all client side.
There is a sab_read_me.txt file that comes in the JK3 SDK that explains all of this in better detail, including what is & is not server side (not all but some).Originally posted by ASk
If the person has an extra .sab file that the server does not have, afaik it either does not let them choose it, or counts their saber as the default type.Again, some of this is server side, some of it is client side. If the client had the .sab file & the server didn't (but was in the servers list of hilts (it would be unaccessable otherwise)), the only thing that would do is use whatever different sound files & whatnot - this is not my concern, hell I'm not even including the sound variables in the protection system at all. My only concern is most of the server side stuff.
So, you mean, if the server host changes his .sab files, then he can make some hilts more powerful than others, and therefore cheat?
I don't think of it as a problem, since everybody with that certain hilt would have higher damage rates. Cheating is defined as something that gives you an unfair advantage over the opponent, but in this case, the opponent can gain the same advantage.
With this in mind, perhaps set up a function that will compare .sab file variables across clients with the server and kick those who has different data (and it would not be based on pk3 checksum either, but straightforward comparison of the values)
That way, IF the server owner decides to modify the values, the clients would have to do the modifications as well.
Originally posted by ASk
I don't think of it as a problem, since everybody with that certain hilt would have higher damage rates. Cheating is defined as something that gives you an unfair advantage over the opponent, but in this case, the opponent can gain the same advantage.Technically, no it's not a "cheat", but considering only the host or whomever they tell (unless someone stumbles upon this find, & even if they do, realize that it's even there) is going to know about this advantage, it's not exactly far from a cheat now is it? That's the point.
Unless the hilt is set to kill you in 1 hit, people aren't going to notice & those whom want to have an upperhand, will. That's close enough to a cheat if you ask me.Originally posted by ASk
With this in mind, perhaps set up a function that will compare .sab file variables across clients with the server and kick those who has different data (and it would not be based on pk3 checksum either, but straightforward comparison of the values)What would be the point? To not allow clients to use alternative sounds with their sabers?
Most servers out there are unpure. Clients whom would like to have a sword-like hilt can use them, however, any clients that do not have that hilt will see kyle's saber instead. A feature like this would remove that availability.
Using different sounds or allowing the light blade to be removed is not cheating (only the users with this file will see a non-light blade, not everyone on the server) or anything even remotely like it & is not what I am looking to prevent.Originally posted by ASk
That way, IF the server owner decides to modify the values, the clients would have to do the modifications as well.That's what purity is for; Not primarily but that can be accomplished with purity.
um, quick question for people on this thread. Has anyone actually made any new animations for JA? If so maybe you should post what you've actually done and get some feedback. Otherwise why talk about it if you have nothing done anyways?
We're waiting on a suitable skeleton. It shouldn't be long, both me and Marker were working on one, but corto left a message at his forum saying he was done but for a few minor tweaks.
Originally posted by JediLiberator
um, quick question for people on this thread. Has anyone actually made any new animations for JA?New animations have been made for Jedi Outcast but that's not what we're interested in. The AnimPack will be for Jedi Academy only since there is no real way to simply convert the animations over to JK2, not to mention the coding as well.Originally posted by JediLiberator
If so maybe you should post what you've actually done and get some feedback. Otherwise why talk about it if you have nothing done anyways?This thread is about the new animations project (AnimPack) which requires coding. There are other things that are going to be coded aside from new animations in this mod such as any bug fixes & various other improvements - that's what we're discussing because this is the developers discussion thread for this project.
Eventually we will have 1 thread for each animation & 1 thread for each concept (such as the .sab protection) in the AnimPack forum but until some publicity is done for the CM site & forums & whatnot (& things are working right with everything), this is where the AnimPack discussion is going to stay.
As for the actual animations, until we have a working skeleton we can't make any. I'm tied up with converting a LAN system at home right now & until that's done, I can't make the skeleton (which will only happen if Corto & I can't come to an agreement), therefore we can't make any animations.
Again, there is more to the AnimPack than just animations. This is a mod which other mods will be based off of, so we're planning ahead.
Fair enough Marker0077. But if this thread is about ALL coding issues why call it new animations in the first place. Seems to me you'd be better off spliting things up like bug fixes, new animations, and basic code changes. Otherwise you'd be having way too many different arguments/discusion going on at once. Which is what seems to me is what is happening here anyway. Maybe it's just me but it seems this whole thread became a big jumble.
Originally posted by JediLiberator
Fair enough Marker0077...Soz if I snapped at you earlier, I had just woken up & I'm REAL bitchy when I first wake up. :-) It doesn't excuse it, I know, but I can't do anything more than apologize, so I am. Perhaps I should just stay away from the forums when I first wake up but I had a ton of stuff to do today & some of it was forum related.
Anyways, this thread is mainly about new animations. The .sab protection isn't exactly a long discussion. We discussed it, we have a good gameplan for it now & that should be that. As for the various other fixes & whatnot, most of it is in OJP Basic which is discussed elsewhere (RA wasnt too interested in adding the .sab protection into OJP Basic, or at least just didn't want to code it :-) (from what I understand)).
Once we have a working skeleton that's cool with everyone, we'll really get the ball rolling here.
At this point this thread is mainly for keeping people posted on what's up with everyone, what their gameplans are (or discussing what it should be), etc; etc.
Speaking of which, I am hoping to be done with this LAN crap by next monday (which will be March 1st). At that point I should be completely available.
I can bring this up now. Because I'm done. Any one who wants the xsi just let me know.
http://mediaservice.photoisland.com/auction/Mar/20043301185333045938791.jpg)
Rough two blaster anim that I used as a test.
Anyway you can submit the XSI to OJP?
That's a good question. How should we store new animations for OJP? In raw xsi format and then in merged form with a unified .gla animation file?
Something tells me you're not going to have a flood of new animations. I think keshire suggested XSI format, so go with that. When I actually get Dragon to a point where it's at app-level functionality, my anims will be coming in .gla format, with the prerequisite one-frame-at-the-front buffer, for easy merging.
It depends, how do you want me submitting these?
The skeleton is best suited to xsi.
The animations I can do in a couple of different ways.
xsi
individual gla's ready for merging, or just keep changing the main gla, and uploading a new one each time.
Being this is my hobby and not my job, I'm fine with upping the xsi for anyone who wants to improve on what I've done.
Sweeet. Pack a second pistol, do some sideways jumping and we got ourselves some John Woo/Hong Kong fighting action. Screenshots are gonna be coooool. :cool:
Sweet Keshire :) Looking great.
http://mediaservice.photoisland.com/auction/Mar/20043318908445004825801.jpg)
This was part of the anim package I was working on. They work. They look good. But its the little things that bother me. So this will be done by the end of the week. :)
And then on to the other stuff
sniper prone
ledge hanging (and pulling up and letting go)
Diving move (for when you press crouch right as you jump)
water improvements
part two of the diving move. (one for landing on land one for in water)
Better swimming movements.
etc etc...
I've seen your latest animations, and they're nice, although you could fix a very-very small thing: the legs. Don't leave them as they are. Move them to make the character look more like dynamic. Probably you already knew... I just wanted to let you know...
Ok, I'm starting a new thread since this thread is pretty bloated. The new thread is here (
http://www.lucasforums.com/showthread.php?s=&threadid=127055).
This may have been mention or talked about before, and is merely and idea, i do not know if this would be classified as an animation but it would be extremely useful and alot of people would benefit from it, what i had in mind is a saber holster emote where you attach you saber to your belt would just be stuck to your side) than you could attach it when needed.
with the holster system it already sort of does that.