[JAEnhanced] Enhanced Development Platform (EDP)

[Archangel35757]

@@eezstreet, I would recommend holding off on this new format until I can recreate and confirm any jitter... if my results (using both Carcass 2.2 and Noesis) show no jitter then there's no need to waste your time that could be spent elsewhere.

[eezstreet]

@@eezstreet, I would recommend holding off on this new format until I can recreate and confirm any jitter... if my results (using both Carcass 2.2 and Noesis) show no jitter then there's no need to waste your time that could be spent elsewhere.

This is a wishlist. Not a commitment of an actual new format.

[Circa]

You can use cg_sabertrail to get a somewhat comparable effect

 

Doesn't that just turn the blur off completely though?

[Archangel35757]

Hmm... @@eezstreet - from the pics & video the effect seems to be incorrect... drawing a straightline linear blur like this (wrong):

rather than an arc, like these (correct):

 

 

...also, the interpolation looks jagged-- as though it needs more steps to smooth it out. And the glow seems a bit excessive... is there a setting to change the amount of "glow"?

 

Edit: I suppose pure translations by the wielder's hand would generate a linear blur. But rotations should be blurred on an arc.

[darthpepo1]

i would like to remove this comment

[Lord Grievous]

This sounds really nice, any updates on the project?

[Lord Grievous]

Skeletal animations?

[Lord Grievous]

Actually, it would be great if this new Ghoul3 format could be based on Ritual's Tiki format from Star Trek Elite Force 2.

 

• TIKI Model System
• Built-in scripting on a frame-by-frame basis
• Client-side and server-side scripting reduces net-transmission of effects
• 4-part character state system for independent control over eyes, head, torso, and leg orientations
• Low memory footprint Skeletal Animation System
• Bone support for attaching other models or effects
• Variable playback rates for animation
• Movement deltas determined from animation eliminates skating of actors
• Support for movement driven animation (player speed controls rate of animation)
• Improved lighting model correctly lights models from light sources around him rather than at his feet
• Real time interpreted player state system.
• Single skin weighted mesh (deformable meshes)

That would add enough modern features to make JO/JA last another decade

[ensiform]

Almost none of that is related to the animation or model system itself. And none of the code is public even for study afaik.

 

Ghoul2 is already quite advanced as it is. The rest would be likely pertaining to some form of scripting in the game code logic.

[Lord Grievous]

This site seems to have quite a bit of info on the tiki format: http://ritualistic.chrissstrahl.de/games/ef2/gdkdocs/content/fakk2_tiki.html

 

I didn't mean to implement all those features, but when comparing it to the proposed ghoul3 format it does have quite a bit of overlap

 

Personally I would love to have this new model format support skeletal animation, as I understand it, this would allow for more complex motion without distorting the mesh.

Also, I assume that the wrinkle maps for the ghoul3 model are there to avoid clipping issues with clothing?

 

Looking forward to this new format!

[Xycaleth]

Ghoul 2 already uses skeletal animations o.O

[Lord Grievous]

Really? I always though it uses vertex deformation

 

Well ahem, good work then

[Archangel35757]

Really? I always though it uses vertex deformation

 

Well ahem, good work then

...that would be MD3 format.

[Dusty]

As for the animations, if you did this @@eezstreet, you would have my undying love and devotion. Is that why animations have always been hardcoded? It is related to limitations of ghoul2?

 

If you ever wanted help with this, how does one learn about creating new file formats? I've always been fascinated by that kind of thing.

[eezstreet]

Animations being hardcoded really has nothing to do with the Ghoul2 format, and more to do with how the animation system is coded. You see, the skeleton format is just a series of frames with no rhyme or reason behind them, and the animation.cfg is what binds the frames to specific animations.

 

What makes animations so hardcoded is very simple; the game just wasn't built for adding more animations. It's just a table of animations with strings mapping to integer values which is easier to work with.

 

As far as file formats are concerned, you have to consider the following:

 

- Is this something which I want people to edit quickly, but not necessarily load quickly and space isn't an issue? Go with a plaintext format, like JSON or the formats that JKA has for .sab, .npc, etc.

 

- Is this something which I want to load quickly, or contains so much data that space becomes an issue? Go with binary data, like JPG or something.

 

Loading binary data is way easier unless you use a library. In which case, loading plaintext data can be a cinch: https://github.com/JKGDevs/JediKnightGalaxies/blob/develop/codemp/game/bg_jetpacks.cpp

 

Model data is normally binary but COLLADA (.dae) files are notably plaintext. I think FBX may be, too.

 

Note though, because I feel like this needs repeated. This is just an ideas thread; I don't really have any motivation to work on a new format.

[Tempust85]

I'd rather see someone enable the use of other file formats for player models and animations. Wouldn't mind giving IQM a whirl for player models.

[Dusty]

A while back, I remember @@katanamaru making a suggestion for creating .style files, to define saber styles, and a similar thought being extended to weapons, force powers, and items.

 

I feel like this would be a great way to separate coding from modding a bit more, and is something I would be willing (and able, I think) to look into personally. You could customize and get more versatility out of existing hard-coded behaviors and functionalities, without ever having to touch a piece of code. And that would IMO make it more motivating to write new code behavior, because it would be more reusable.

 

My ideas for definitions so far:

 

.style (saber style definition):

• name: for use with addsaberstyle command
• stance animation: animation.cfg ref
• walk animation: animation.cfg ref
• run animation: animation.cfg ref
• attack/transition/defense animation set: some list of constants (FAST, MEDIUM, DUAL, STAFF, would need to code in any others); perhaps attack, defense, and transition anims need not match?

Level stats --- (can define "levels" for styles, level 1, level 2, level 3, and change the following))

any .sab file fields... plus more?

• attackAnimSpeed: float
• kataStandard: standard kata if any
• kataSpecial: a kata performed with +forcefocus, if any
• specialAbility: list hardcoded constants here, for behavior that is difficult to define outside of code (for example, uninterruptible)

 

For the next two, the point is that you can have weapons based off existing weapons with different properties, such as model, icon, damage, etc. without needing to code it explicitly.

 

.weap (weapon definition):

write new entries into weapons.dat file:

• name: WP_MYWEAP (used for reference in console commands)
• baseWeap: WP_BLASTER (which weapon's coding and physics to use)
• effectRef: folder name prefix to find .efx files, will use effects in the same manner as the baseWeap, but inside it's own folder)
• all weapons.dat fields

.force (force power definition):

create a forcepowers.dat file:

• consoleName: myforcepower (to be used in setforcexxx)
• constantName: FP_MY_FORCE_POWER (for any reference in UI files that might be necessary)
• basePower: FP_PUSH
• level: which level of the power this controls
• alignment: LIGHT/DARK/NEUTRAL (affects whether powers can be used together)
• similar fields to weapons.dat (icons, sounds)
• effectRef: folder name prefix to find .efx files, will use effects in the same manner as the basePower, but inside it's own folder)
• fields that may be unique based on basePower: fpInitDrain, fpContinuousDrain (Absorb, Protect), cooldownTime (Speed, Rage), hpDrainRate (Rage), hpIncreaseRate (Heal), etc.
• annoying part here is the levels, may need separate entry for each level of a power, which is more of a pain than saber styles since there are 15 force powers

 

Any thoughts on the matter? Part of me feels like maybe it wouldn't be worth the work though, in that it wouldn't see much usage relegating the state of the matter back to being "well might as well just hardcode it" due to my perceived lack of popularity of SP modding. Whatch yall think?

[Futuza]

You should look at how JKG does most of our stuff, we haven't gotten to force powers yet, but we try to make things as "softwcoded" as possible so everything can be changed in json files on the server host's whim.

[Dusty]

I know eezstreet had mentioned that in the past. I guess I'm wondering, what the benefits are of using JSON files over the existing game file structure, or maybe JK Galaxies written that way simply because there wasn't already any file system for MP?

[eezstreet]

Our JSON files load faster than COM_Parse reads files because of how the format works. It's also readable by Javascript and Apache, making documentation (through a generated wiki, for example), an extremely easy task. Plus it's not buggy like COM_Parse is.

[katanamaru]

I'm glad I started playing JA this winter break. I came back to see if any progress was being made for adding saber styles.

 

I haven't animated in 10 years, but it's something I'd like to do again.

[TheWhitePhoenix]

I'm glad I started playing JA this winter break. I came back to see if any progress was being made for adding saber styles.

 

I haven't animated in 10 years, but it's something I'd like to do again.

It would be nice for you to make something again. I don't think I need to remind you of your amazing work making the DF2 stances.

[katanamaru]

I still use those gun animations!

[TheWhitePhoenix]

I still use those gun animations!

I still use your DF2 saber animations!

[Dusty]

The JSON sounds pretty cool then, but is a bit out of my ready-made knowledge to code. Is there any progress currently made on implementing JSON for JK Enhanced? Or maybe I could look into implementing that?