Jump to content



  • Posts

  • Joined

  • Last visited

Contact Information

  • Homepage
  • ICQ
  • AIM
  • Yahoo

Marker0077's Achievements


Newbie (1/14)



  1. 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.
  2. 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. 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.
  3. 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. 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. That's what purity is for; Not primarily but that can be accomplished with purity.
  4. 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. 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. 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). 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.
  5. 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.
  6. 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. 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. #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. 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.
  7. The 2x the saber damage was an exageration. I was thinking the host would boost the damage in smaller amounts such as 10% or 15% which would be undetectable. I'm talking about a a CVar that when enabled, it protects against modified .sab files via hardcode - the server can't change that if the CVar is enabled; Unless the host is a coder, in which case you aren't really going to be able to stop them. At that point, all you can do is reason with them & inform the community on what type of mod they put out there. How do you know? Tell me you haven't gone onto a server & seen people take other people out on rather simple hits. Now I'm sure most of the time it's just head hit or whatever but the point is there is no way to tell. With this CVar enabled, clients are protected. You can't say this is a non-existant problem because unless they have extremely increased the damage, there is no way to tell. The animations need to be hardcoded, this is something else that should go in the hardcode. I wasn't aware that anyone was even doubtful. Granted, the process is taking longer than expected, & I apologize for that but I have to deal with this stuff at home before I can venture onto this. It's not optional for me, what about everyone else? Look, if you don't like the idea then a simple "I don't like the idea, don't see the point" or whatever would suffice. Getting pist off about something isn't going to change anything. If you don't like it then don't use it but don't get pist off at me because I'm trying to make the game more secure or because I couldn't think of the best way of going about handling it on the first try. Calm down before you post please. The mods need to work in base also, that's why. For now I think simply making certain .sab file options disabled & the higher the number, the more options enabled is the best way to go about handling this. As for this whole checksum bit, we'll see but first things first. Also, I'm pretty sure all the stuff from OJP Basic will go in the AnimPack code (possibly the JAR features as well, nothing for sure on that yet). Is the value of g_saberdamagescale stored in a sets like CVar (so what it's set to can be viewed from the net)? Why would they, unless people are setting the damage extremely high, they would have no clue - hell, the .sab stuff is set up VERY similar to how MoH is. Alot of times in MoH, the server will set a certain gun to do 0 damage instead of just removing it, you'll be using a gun for awhile not even knowing it's not doing any damage until you go to shoot someone in the head or something. Now granted, this would be pretty easy to spot out in Duel servers but what about FFA where there's no one watching each player? Also, this wasn't very common place at first in MoH, as time went on it did however. Modifying .sab files isn't like writing code, ,pre & more people WILL eventually figure this stuff out as time goes on. I think we should offer some sort of protection against that type of gameplay. The bottom line is just because someone isn't complaining about cheating, that doesn't mean there isn't people out there cheating. For all you know, you could have been playing with cheaters & not even known it. This provides alot more re-assurance that you are playing a fair game.
  8. You easily seem to forget that most people out there are n00bs. They don't even know all of what they can do with the .sab files, when they do, the filesize check alone will be a big hurdle for even some of us to climb. We don't have any proggies that do exact matches down to the byte so that leaves them with hacking the code. How many of them do you think are going to be able to do that? Sorry, I don't agree. This is neccessary because all someone has to do is add a .sab file that makes his reborn hilt do twice as much damage as all the other hilts & voila, you have an easy cheat or at least a decent example of how it can work. I feel it's our responsibility as the leading developers of this community to prevent this type of gamplay. Well we may have no choice if this checksum thing doesn't work out. I'll do some investigating on how easy it is to do filesize matching later today. Right but you have to realize that there are multiple levels of standards. The primary standard has all the hilts being the exact same. Now that I think about it, we may have to make option 2 be what I had planned for option 1 & make option 1 be CM packs only because with CM packs the blades are in the exact same spot. That may or may not be the case with other hilt packs. And how is that any different from how it is now? What I am proposing is hardcode protection, your suggesting we bring it back into universal text files; Or am I misunderstanding? Ya I think you may be right. I was planning on having this with or without the filesize checking protection. I think what's going to really make or break that is the testing I do later on. If anyone can just fire up WinARJ & match up the filesize, it totally defeats the purpose. Not really, this is a CM based mod & we would only be doing this for a few CM files. Not really, CM hilt packs have gone through standards, other hilt packs have not. That's the point. Also, whether or not a CM pack would be usable or not would also depend on the settings of the CVar. If the CVar is set to "1", then the CM non-standard hilt packs would not be permitted to be used. I have another question. Can the code search .pk3 files to see whether or not a .sab file is in it? I think you can see where I am going with this. This is a HUGE factor in this feature. I can't have sound mods, for example, be blocked because of .sab protection. I really don't want to make this complicated & without me being an actual coder, it's harder for me to come to the most sensable solution so I am just throwing out some ideas here. I think for now we should just go with certain levels of standards. This would probably be the easiest way of going about handling this for now considering this is something I think we all wanted to do with or without the filesize chekcing. Once that is put together, we can possibly add on from there. After I do some testing on the filesize matching, I'll go over all the .sab options & what levels I think those should be put at, post them, then we'll all go from there.
  9. You lost me, I don't see why you think purity would be useless. We're not preventing other mods from being used, we're just making it so that the CM pack (which has been checksum verified) is the only pack that has permission to make certain types of changes via .sab files, like the different specials setup - that's all. The higher the CVar is set to, the more leanient the standards. Again, the beauty of this is clients will be able to tell what kind of server this is before they even join & they can rest assured that no tampering has been made to the server. Also, WinZip doesn't support filesize matching. Now I think WinARJ does but I don't think it's that exact. Either way though, it's more security. Unless anyone has another idea, this is what we've got to work with.
  10. Normally you can do 6 different specials with a single saber. The both attack buttons special is 3 since there is a different one for each stance, the lunge, the rdfa, & the ydfa. With the way I am saying you can do it, you only have 2 specials; The lunge & the rdfa but I may change that to ydfa. It's a little different but I wouldn't say it's unbalanced. Lunge is the probably the most used counter-attack move there is & the new stance cycle speed is alot slower than that of JK2 - so that's a plus; But not having the both attack specials is taking away alot also. That's not what I had in mind. This stuff needs to work in the base game as well, so this wouldn't fly with me even if we could get it working. I was thinking of having the code check the filesize. If anyone made any modifications to the pack, that would change; Especially if it the compression rate is changed specifically for throwing off the standard compression filesize.
  11. I like the pulling the flag concept, this way it can still be secure & people may use hilts that aren't included in CM, however, this still doesn't answer my question in regards to the CM hilt packs. I don't change the damage or radius or anything like that but with certain hilts, as I said before, have specials set differently (no both attack buttons specials but lunge & rdfa in all stances) & I want the CM packs to be the ONLY packs allowed to make those kinds of changes. Another thing is with the CM packs, I probably wouldn't decrease the damage amount for multi-bladed weapons. I would more than likely cripple those types of hilts differently via the CM packs. As for non-CM packs, then yes I suppose this would be the best fix for that. In all reality though, when this CVar is set to 1, those types of weapons should not even be available. It kind of defeats the purpose. Is authenticity verification for the CM packs possible via the code?
  12. Well while I agree that we need some results here, there's more to this than just that. I apologize if some of my methods are not so pleasing to some of you, but walk a mile in my duelers shoes & you'll understand exactly where I am coming from. Trust me, I don't like it any more than anyone else (especially considering this is more workload on my end - not yours (not really)) but the worst case scenario is just not worth it to me. Anyways, gameplan is important. This is a pretty big project & I think it's also important that we are all on the same page with all of this so there are no misconceptions or misinterpretations about anything. New CM Standards Concept (Requires Hardcoding) I wanted to run this idea past you guys & get some feedback. I'm personally a stickler for making sure that when a user joins a server, there's no cheating or abilities that are very similar to cheating available. I'm not sure how aware all of you are with the stuff you can do with .sab files but you can do alot. You can increase the damage amount, the speed, the radius of the blade, all kinds of stuff & this is all server-side & it does not give any notification that any changes have been made (like there is when cheat mode is enabled). This is a big concern for me.... I want a CVar specifically for disabling all .pk3 files that contain modifications of .sab files (or possibly all .pk3 files if need be) aside from CM hilt packs. When enabled it does let CM packs (which have gone through standards) be used, depending upon which level of standards the CVar is set to. This checks the filesize for authenticity verification. When set to... 0 = Disabled, any .pk3 may be used. 1 = Any level 1 Standard Hilt pack may be used. Level 1 hilts are basically the standard hilts, all hilts are *exactly* the same, they just look different. 2 = Any level 2 Standard Hilt pack may be used. Level 2 hilts are slightly modified but balanced hilts none-the-less, like some hilts (which are configured all via .sab files) may be permitted to allow the blue lunge & red forward slash in all stances, however, it does not allow the third specials to be used (both attack buttons at same time), etc; etc. 3 = Any level 3 Standard Hilt pack may be used, which in all reality are non-standard hilts but I may change the name to level 3 standards. These standards permit the blade to be positioned differently which is a necessity for some hilts such as the Chainsaw hilt (which positions the blade more to the right than the standard) & the Schwartz hilt (which positions the blade closer to the hand itself since it is a ring & not a normal hilted blade), etc; etc. The beauty of this is the client has the availability to see what type of server whomever is hosting before they join where now, they have no clue. I intend on informing the public how they may filter out specific types of servers so that they view only the types of servers they would like to play on via the Cool Mods Manual. I'm not exactly sure what is & what is not possible coding-wise for eliminating the use of possible cheating-like abilities via .sab files so I was hoping you guys could shed some light on this subject, give me your opinion &/or other commentary in regards to that.
  13. Last night when I posted, I was tired & drinking so I wasn't thinking too clearly so please forgive me for not clarifying right away. 1 of the things that are an ABSOLUTE MUST with me is copyright in part or in whole; For example, with all the models I put out I include a CM mesh that identifies the work as coming from CM staff. I do this in case someone ever tries to steal my work again, they have to remove the CM mesh in order to use it so they may as well be using the original authors work (which is what I want them to do in the first place). The point is, if I can't claim partial copyright by putting this out there in .XSI format, then I probably won't do it. Like if I put the .max file out there for the models, people could just remove the CM mesh & voila, I have no legal right to claim anything. The same concept applies to these animation files, they can remove the animations that I made & voila, same boat. The gameplan for me is, if someone makes up some animations & wants them added, I (or another CM staff member/supporter) will add them to the pack, then it becomes available in the next AnimPack version. The source code is a given, I have to submit that but I don't really see why I *have* to submit the existing animations. The whole point of AnimPack is a pack of all new animations, if there's new animations out there, it belongs in AnimPack & that's what coders should be using. It's good to know there are other people out there that are serious about doing new animations & tbh, I could really use someone to run the AnimPack portion for the most part. The only thing I am claiming dibs on is the installers, manuals, & a few animations but I still have sooooooooooooooooo much stuff to do & I'm dropping all of it to do this AnimPack project. If any of you are interested in becoming staff or supporters, just let me know.
  14. I wasn't aware that there was even any other animators willing to realistically play ball. This is great. I think we should work together or at least allow me to add whatever animations you guys create to the CM AnimPack. Ummm, I think you are misinterpreting what AnimPack is. We create new animations, compile the .GLA, then we put a source together that already has the coding needed done plus whatever other improvements we think should be in there like bug fixes for example, then that's what gets submitted to OJP. When we put together new animations & add it, we submit a new version of AnimPack to OJP. Get it? The source code will be submitted as well but it may be a seperate submission. I haven't worked out all the detail but that's the gameplan I have so far. I just want this to be a resource for coders, that's the main concept of AnimPack but I will make it a stand-alone mod as well. Any .XSI files or maybe even actual code will all be released in the CM developers pack... maybe, like I said, there's still some things to work out.
  15. I have a novice grasp on what you can do gameplan-wise with ideas I post (that needs coding) & I normally post them. Most of them are pretty self explanitory though. Anyways, the point is we have tons of stuff on the table here. There's so much stuff that still needs work, yet alone the stuff that we haven't even got to yet. You're talking about a concept that would take a pretty long time to produce. Granted, it would be hella cool but I guess you just have to decide for yourself what's better. A bunch of features that don't take up as much time, or 1 feature that takes up tons. The 1 feature might be sweet & all but so is all the little ones too. It's really six in 1 hand & half dozen in the other & since RA, Phunk, & the other coders are the ones that have to actually do the work, it's rightfully their place to say what does or doesn't get coded next. This was one of my problems with Lee when we were partners but unlike Lee, RA & them are saying that if you can find someone to code this stuff & add it, they'd be willing to use it. That's not the case with my old partnership, so take it from me, be grateful for what you have & try not to get too upset about the things you don't. It could be worse.
  • Create New...