OJP: New Animations Project

[ASk]

I doubt so

Most likely something along of the lines

 

'if you use this, make sure to add my name to list of credits'

 

To be honest, I myself am not entirely siding with OJP philosophy

[Marker0077]

Well adding to the credits was never an issue, credit being given is a given in OJP and CM. As far as "not entirely siding with OJP philosophy" goes, how so?

 

The only "philosophy" I am aware of is sharing. Not allowing people to use your work is one thing, using other peoples work & not allowing people to use your work is another - that's the only "philosophy" I'm aware of & I totally agree with. TBH, I can't understand how any honest person couldn't.

 

My only concern here is not being on friendly terms with Corto in the future; For example, we use the skeleton in the AnimPacks & then in the future there is more "miscommunication" that leads to Corto pulling a "you can't use my toys anymore" type thing - screw that. The AnimPack is a public resource & I am not going to put it in that type of a situation. If it's not released to OJP, CM, or some form of secure public use then I'm not using it.

 

You guys saw what happened with the JK2 animations development, how many people do you think you are going to find that are serious about doing new animations in JK3? If Corto is going to make the skeleton, he may as well let us use it & this is the only way we will (we being CM staff & AnimPack supporters/contributors). Of course, you guys could always start an AnimPack project of your own.

 

Now perhaps Corto isn't the type of person to do that, I have no idea because I don't know the guy personally but whether he is or isn't is irrelevent. After the whole Duelers ordeal, my philosophy is "business is business" & the thing needs to not necessarily be put in public domain, but in some form of secure public use.

 

Marker0077 LATE EDIT: Another thing I'd like to say is that I do apologize about the little bit of inconvenience this does create; Trust me, it's more of an inconvenience for me than anyone else. Like I said before, after the whole Duelers ordeal, I am covering my ass from now on. It's better to have something & not need it than to need something & not have it.

 

I'd be willing to write up a terms of agreement that states we are not permitted to allow other people use of the skeleton & the only thing that we are permitted to do with it is use it in the AnimPack project, which is of course going to be used in other mods but all the other mods use a version of AnimPack. Credit being given will of course be in the agreement but credit being given is a HUGE thing with me, so rest assured on that. I normally include links to email/URL that authors would like included etc; etc.

[keshire]

I already made that skelly. It only needs tweaking to be sure it's perfect. I would've released it yesterday, but I didn't have the _humanoid.gla file at work, lol. And when I got home, well I spent all the time I could with my girlfriend, so... Well. I think I'll dedicate more time tonight after work, since I'll be alone for about 5 hours or so. - Corto

[Marker0077]

Corto, I'm in no rush. I'll be tied up for at least another week with this LAN thing. I do however need the skeleton submitted to OJP or for you & I to come to some sort of an agreement so I can always use the skeleton for the AnimPack regardless of whether or not we ever "miscommunicate" in the future. Credits being given towards ANYONE whom helped out with this will be given along with any email & URL links that they would like. Due credit is mandatory with me.

 

I sincerely never meant any offense towards you & I hope the feeling is mutual but business is business & I've been burnt before in the past. I can think of obvious reasons why I should insist on doing this agreement or submittal to OJP, I can't think of 1 reason why I shouldn't; Aside from saving myself some extra work.

 

Let me know where you stand with that. If it's not acceptable to you then I'll just have to make my own, which I really do not want to do but I need security with the project.

 

Thanks for everyones time.

[keshire]

Corto, I'm in no rush.

 

But I am. Your not the only animator around here.

 

Duncan

Bloodriot(I know he checks in every once in awhile)

And Myself

 

have expressed a desire to tackle some new anims.

[keshire]

And as far as submitting animations to OJP.

 

I believe it should be in xsi format.

For each individual animation sequence.

 

If this is open source then the animations should be modifiable too. And I will put my money were my mouth is.

 

If Monsoontide submits his Acklay to OJP, I'll cough up my accompanying xsi files.

 

Otherwise you'll all have to settle for my future works.

[Marker0077]

Originally posted by keshire

But I am. Your not the only animator around here.

 

Duncan

Bloodriot(I know he checks in every once in awhile)

And Myself

 

have expressed a desire to tackle some new anims.

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.

Originally posted by keshire

And as far as submitting animations to OJP.

 

I believe it should be in xsi format.

For each individual animation sequence.

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.

[razorace]

Since the gla merger program only works on .gla files. I suggest that all _humanoid animations be submitted in .gla format. Since the merger program isn't set up for non-humanoid animation files, they should be submitted in a compiled .gla form and with a source .XSI so people can modify them.

[Marker0077]

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.

[razorace]

Anyway, I think we really need to have some results before continuing this discussion.

[Marker0077]

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.

[razorace]

Makes sense to me. Now you just have to find someone to do it.

[keshire]

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.

 

Start pulling out the flags.

 

Leave the customizing ones and pull the balance changing ones.

[keshire]

Like so...

 

soundOn=yes

soundLoop=yes

soundOff=yes

 

saberLength=tighter limit

saberRadius=tighter limit

 

moveSpeedScale=NO!!!!

animSpeedScale=NO!!!

knockbackScale=NO!!!

damageScale=NO!!!

And ditto for the splash flags etc.

 

Also reduce damage for each blade after the second blade because as you know hilts support up to 7 blades.

[Marker0077]

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?

[keshire]

The adding of the other attacks to all stances is rediculous, unneeded and unbalanced. In my opinion.

 

But I'd leave in the option of turning off certain commands.

 

And as far as limiting what they can change. I've always wondered if you can encrypt a pk3 like a zip or rar. And decrypt it in code.

[Marker0077]

Originally posted by keshire

The adding of the other attacks to all stances is rediculous, unneeded and unbalanced. In my opinion.

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.

Originally posted by keshire

And as far as limiting what they can change. I've always wondered if you can encrypt a pk3 like a zip or rar. And decrypt it in code.

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.

[razorace]

The problem with checksum file protection is that someone can easily make the checksum for the .pk3s match by adding some fluff to the .pk3. So, that makes setting servers to "pure" totally useless.

[Marker0077]

Originally posted by razorace

The problem with checksum file protection is that someone can easily make the checksum for the .pk3s match by adding some fluff to the .pk3. So, that makes setting servers to "pure" totally useless.

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.

[keshire]

I know you like to cover your ass and all, but I really think this is all unneccessary.

 

If somebody wants to make the changes they want, they're going to find a way to do it despite any checks you put in place, especially if these changes are all stored externally.

 

As it is, I'd just CVAR the balance changing flags and leave it at that.

 

CVAR hilt_flags 0/1

 

*edit*

Oh I think i misunderstood what you were proposing. You want the flags in your hilts to work but not any hilts outside of your mod.

 

If that is the case, I really don't think you should mandate what hilts people can and can't use.

 

But an idea would be a seperate file with the hilt names that are allowed thier flags.

 

such as

coolhilts.txt

 

or one big .sab like the saber.sab that stores all the single player hilts.

 

coolhilts.sab with the all the combined hilt definitions.

[razorace]

I think the best solution would be to have levels of acceptable .sab settings that can be displayed/controlled with a cvar.

 

Doing anything for just individual files would be a pain-in-the-butt timewise and is sort of biased (it's not really fair to allow your packs to override the cvar control when everything else doesn't).

[Marker0077]

Originally posted by keshire

I know you like to cover your ass and all, but I really think this is all unneccessary.

 

If somebody wants to make the changes they want, they're going to find a way to do it despite any checks you put in place, especially if these changes are all stored externally.

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.

Originally posted by keshire

As it is, I'd just CVAR the balance changing flags and leave it at that.

 

CVAR hilt_flags 0/1

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.

Originally posted by keshire

Oh I think i misunderstood what you were proposing. You want the flags in your hilts to work but not any hilts outside of your mod.

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.

Originally posted by keshire

But an idea would be a seperate file with the hilt names that are allowed thier flags.

 

such as

coolhilts.txt

 

or one big .sab like the saber.sab that stores all the single player hilts.

 

coolhilts.sab with the all the combined hilt definitions

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?

Originally posted by razorace

I think the best solution would be to have levels of acceptable .sab settings that can be displayed/controlled with a cvar.

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.

Originally posted by razorace

Doing anything for just individual files would be a pain-in-the-butt timewise and is sort of biased...

Not really, this is a CM based mod & we would only be doing this for a few CM files.

Originally posted by razorace

...(it's not really fair to allow your packs to override the cvar control when everything else doesn't)

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.

[Wudan]

(please) Knock it off, this pk3 .sab argument is just garbage, and I don't think I'm the only one who thinks it.

 

If you're right, then pure servers and impure alike are going to be running rampant with crazy guys with saber nunchuks that deal too much damage.

 

Let's examine - where is the damage dealt? The server. What files are checked to see how much damage a .sab does? The server's files? I thought so.

 

I don't really care if I'm wrong, either, because this hacking is a non-existant problem.

 

I really don't see how we got from 'I'm going to make new animations" to this discussion. Talk about de-railed threads.

 

Please, can we talk about how many people think they will make new animations versus how many people don't think it will happen.

 

I vote that it'll happen.

[razorace]

Why not just hardcode the standards and then forget about the checksum stuff? It would be much easier to do and would result in better cheat protection.

 

Besides, this seems like a minor issue to me. I've yet to hear anyone complain about *.sabs being used for cheating.

[Marker0077]

Originally posted by Wudan

If you're right, then pure servers and impure alike are going to be running rampant with crazy guys with saber nunchuks that deal too much damage.

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.

Originally posted by Wudan

Let's examine - where is the damage dealt? The server. What files are checked to see how much damage a .sab does? The server's files? I thought so.

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.

Originally posted by Wudan

I don't really care if I'm wrong, either, because this hacking is a non-existant problem.

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.

Originally posted by Wudan

I really don't see how we got from 'I'm going to make new animations" to this discussion. Talk about de-railed threads.

The animations need to be hardcoded, this is something else that should go in the hardcode.

Originally posted by Wudan

Please, can we talk about how many people think they will make new animations versus how many people don't think it will happen.

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.

Originally posted by razorace

Why not just hardcode the standards and then forget about the checksum stuff? It would be much easier to do and would result in better cheat protection.

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)?

Originally posted by razorace

Besides, this seems like a minor issue to me. I've yet to hear anyone complain about *.sabs being used for cheating.

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.