skew

9 hours ago, Lazarus said:

This looks pretty neat. Is it 1 vs npc or is it 1 vs 1 as in multiplayer?

It's a multiplayer mod for Jedi Academy MP. It's intended as 1v1 for a 2/3 round structure of matches. It picks a pair of people to play for each match. It supports clients and bots with a new fighting game AI.
 

Unfortunately you won't find any servers yet since it's still in development. 
 

You can find more info here:

https://www.moddb.com/mods/jedi-fighter/downloads

Hey guys,

It's been a few years since my last update but I will be trying to work towards a release soon.

Quick update:

- Trying the built in saber knockbackScale as a hitstun with my own damage system. Video below. It seems to work well enough, but it breaks the knockdowns from kicks and, in certain cases, results in ridiculously far knock backs, so I'll be adding a knock down when the knock back exceeds a threshold.

What a great idea. Thanks for doing this, Circa.  I watched a portion but will check the rest out over this week. 

Thanks to the staff and the community for keeping this site vibrant. It's much appreciated, even by sporadic lurkers like me!

Well I think part of what factors into the decision is what your featureset is going to include. Are you going to have combos or chain moves? Are you going to define weak zones?

If I go with hitboxes, then I'll definitely be doing weak zones. Also looking at my special move system right now to see how I can do chains/combos.

I wrote a scripting system for special moves which I'll include commands to create or delete zones of a certain type at a given time during move execution, which is how I'll do the hitboxes without resorting to per frame info.

For chains/combos, I've got a permissive check in the special move script.  When an input combo is matched, it'll check permissives before executing the remainder of the move. In the permissives I'd add the moves one must be in to perform the chained move, but this might not be the final approach. Just working on some concepts.

Fighting game fans are pretty opinionated about how hit detection is done and it can be a major factor in their enjoyment of any given fighting game.  Traditional fighting games use one of two methods, 1) hit boxes, or 2) sprite/model based collision detection.  

I'd like to hear the community feedback on which hit detection approach you prefer and why.  I'm considering whether to improve the standard JA collision detection or switch to hitboxes in Jedi Fighter.

Hit boxes

Hit boxes are basically collision zones (usually a set of boxes) that define the regions of the character which can cause damage (e.g. a leg during a sweep kick) or take damage (i.e. the head while executing a kick). Some variations on this approach are to handcraft or automatically generate the hitboxes per frame of animation, or to use hit spheres/circles rather than boxes. For the purposes of this poll, hit boxes are any metadata defining collision zones that don't match the model/sprite.

Many 2D fighting games like Street Fighter II use hit boxes.

Some reasons cited for using hitboxes:

- to provide consistency of the hit detection zones during idle animations

- to keep a hit box fixed while taking damage during a knockback animation so the opponent can execute chained attacks

- to define weakness locations during an attack

- they provide a method to fine tune and balance the hit detection

Examples shown below:

Street Fighter II/Turbo/Championship hitboxes

Hitboxes from Garou: Mark of the Wolves

Examples of hitboxes in 2.5D and 3D fighting games are shown below.

Super Street Fighter IV

Collision detection

The traditional approach for JA is per poly collision detection using the Ghoul2 animation system. This means that the actual polygons of the model are used to determine the collisions against weapons, once the weapon/projectile has penetrated a certain box around the player.  You get whatever the animation gives you.

Some reasons cited for per poly collision detection are:

- less development effort since collision zones are determined by the model directly

- collision detection matches how the player looks, so it appears more "accurate" and "realistic"

- it is technically more realistic

I don't have any art to provide for this type of collision detection but I think this one is pretty straight forward.

I'd love to hear which method you all prefer to play with and why!

What is Jedi fighter?

New, shorter, teaser trailer just went up

Hey skew. It's great to see you're trying out rend2 I don't think you'll get the results you want with a plain Gaussian blur. You will end up blurring across edges which ruins the effect. What you want is a depth-aware Gaussian blur which only takes samples across areas of continuity (i.e. not across edges). If have to say though, it's really difficult to notice the SSAO - I feel like something is wrong with it.

I'm trying out a depth based blur now, and you're right that it was really difficult to notice.  I made a few changes and will post some shots soon.  Looks much more natural now.

I'm also working on getting post processing effects to properly show up in mirrors. Here is a test compositing them to the scene image rather than directly to the framebuffer if it's a mirror.  When I tried putting it directly to the framebuffer after rendering the portal surface, it never seems to persist in the framebuffer for some reason. Need to figure out why the colors seem off on the blur when compositing to tr.sceneImage though... format issue?

EDIT: Also temporarily fixed the issue with the improper scissoring of mirrored surfaces (see previous screenshots) by temporarily disabling the scissoring, but this needs a proper fix.  From a cursory check, it looks like the mirrored surface is being split into multiple surfaces. It also looked like, since none of the vertices of the nearer surface are in the frustum, then it culls them entirely rather than checking if the surface exists in the frustum and clipping it to the view.  It was then calculating the scissoring coordinates from the remaining verts in clip space, which is only the further half of the mirror surface. I'm going to do more debugging on that to see what is exactly happening, but just another thing to eventually get right.

Not gonna lie....this is the best mod in a very long time. Well done!

Thanks, I really appreciate it. Positive feedback like this always helps to keep up the motivation

Just noticed that I forgot to update the credits (forgot to put you down for the Luke model, and left out quite a few others) in the Youtube trailer so putting up a new version today.

EDIT: The new trailer is up with higher bitrate encoding too, so no more oddly skipped frames!

Any thoughts on what you'll be doing? I'm using OpenJK for a mod that relies heavily on gamepad support...

Hey Everybody,
 
I've been working on a 2D fighting game mod called Jedi Fighter.  I just released a beta 3 yesterday, which was mainly focused on making new adaptive fighting game AI.  Previous releases relied on JA AI for everything. No more!  

Check out the mod's profile on moddb:

The new AI is loosely Bayesian based and learns on the fly which move to execute next, based on the relative position, health, and absolute health of self and the opponent. It works pretty well, as you can see in the following terrible trailer video:

In the next few weeks, I'll post a lot more detail about how the AI and various other features work. Soon I'll be releasing the full source on github too.

I'd really appreciate if you guys would try it out, or at least give some comments from the video. Many of the models came from you guys and other talented modders, without which my mod wouldn't have the presentation, so I'm really appreciative that you let me use your assets in Jedi Fighter!  Thanks!

------------ BEGIN MARKETING -------------

Features in beta 3

• Fight as 10 characters from the Star Wars movies and expanded universe, each armed with unique force powers and devastating special moves
• Fight in 5 arenas, from a Tie hangar bay, to turbolifts in the Deathstar, to the aftermath on Hoth
• New fighting game artificial intelligence, enabling fighters to learn and adapt from opponents on the fly! (new in beta 3)
• Gamepad support! (improved in beta 3)
• Full widescreen support for 16:9 (1080p and 720p), 16:10, 4K and 21:9 resolutions! Or any custom resolution!
• A dynamic camera that gives a cinematic view of the action
• Awesome title music
• and much, much more!

Feedback
Your honest feedback is incredibly important and very much appreciated! Please post comments to theforums. I'll be checking them regularly so your comments will help shape the direction of the mod!

If you would like to contribute by making maps, please reach out to me via email or messages, or post to the forums. I'd appreciate the help!

Requirements:
You'll need to install Jedi Academy, the OpenJK engine, and Jedi Fighter beta 3 to play.

Installation:
Check out these installation instructions to get started.

1. Unzip both Jedi Fighter beta 3 and the OpenJK engine to your Jedi Academy\gamedata directory.
2. Right click on SETUP.BAT in the Jedi Academy\gamedata\jedifighter directory and choose "Run as Administrator".

Run JF_CLIENT_OJK.BAT in your Jedi Academy\gamedata\jedifighter directory to get started. Configure your controls, max out your video settings and resolution, and have fun!

If you have any issues, check out the detailed instructions in jedifighter\_README_.txt. If you still have problems, feel free to post in the forums.

Future plans:
JEDI FIGHTER will continue to be improved until the v1.0 release in 2016, with a beta 4 in the next few months.

Beta 4 will focus on a few key areas:

• balancing and adding fighters (including from Star Wars: The Force Awakens)
• improved user experience with the server browser and match making

----------- END MARKETING -------------

Tried a Gaussian blur on the ssao result and it doesn't look too bad. Going to try a bilateral filter next because it's supposed to preserve edges better.

Without SSAO:

With SSAO + 2d Gaussian blur:

@@skew Great, another one who's interested in helping with the renderer. To the SSAO. The random function isn't the problem imo. If there would be blur applied to the rendered image it would look ok, i guess (thats what the "big" engines do, if i remember correctly). You could look in the ioquake3 repository for some enhancements. They reworked their ssao some months ago. https://github.com/ioquake/ioq3/commit/93e1feaaad19fcc97459b8fd15492b1ff3551bc3

 

Have you looked at the c code or only the glsl code? I could use some help with other effects if you are interested. I implemented some refraction prototype that could use some work to get the vanilla parity of this effect. E.g. the wobble effect is not implemented.

I do want to learn more about modern OpenGL so I'm interested in helping out with what little time I have .  I started looking through the renderer source code to see how it was binding textures, providing data to the shaders, etc and generally walked through bits of it to get an understanding of the flow.

The mod I'm working on could really use a modern renderer, and is using the refraction with force push/pull, but also reflections, weather, and at least the SSAO.  Let me get past my next beta release in about a week and then I'll try to jump back into rend2.

EDIT: Thanks for the info re: ioq3. I was about to try that out to see if they evolved it any beyond the old rend2 used as a basis for the OpenJK version. Looks like the blur on the SSAO output is how most people make it look better.

(Excuse the giant images!)

SSAO seems to have an odd screen door effect, almost as if the direction vectors around each normal were following a strong pattern rather than being pseudo-random.

Below is a screenshot of the latest rend2 branch from yesterday.

When I visualized the random function from the ssao fragment shader( using the fragment coordinates in screen space as the seed just as rend2 at runtime), there is a clear non-randomness to it, similar to the vertical striations from the screenshot.

I tried increasing the random vectors per fragment from 3 to 9 to see if it could smoothen out the pattern but it didn't help as much as I wanted.

Ultimately I went back to the source referenced by the shader to see if it was an implementation issue. Looks like the random function was done per the source originally but then changed to what is now.  

// Input: It uses texture coords as the random number seed.
// Output: Random number: [0,1), that is between 0.0 and 0.999999... inclusive.
// Author: Michael Pohoreski
// Copyright: Copyleft 2012 :-)
// Source: http://stackoverflow.com/questions/5149544/can-i-generate-a-random-number-inside-a-pixel-shader

float random( const vec2 p )
{
  // We need irrationals for pseudo randomness.
  // Most (all?) known transcendental numbers will (generally) work.
  const vec2 r = vec2(
    23.1406926327792690,  // e^pi (Gelfond's constant)
     2.6651441426902251); // 2^sqrt(2) (Gelfond-Schneider constant)
  //return fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) );
  return mod( 123456789., 1e-7 + 256. * dot(p,r) );   // adnan - this gives a strange screendoor effect because the random numbers have vertical banding
}

Here is what it looks like if I change it back to the original method ( fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) ) ) and with 9 vectors per fragment.  Looks much better.

This method is obviously more compute intensive only because I've got it doing the 9 vectors per fragment, but seems to work decently on my machine.

I'm going to look at doing what Nvidia mention in some of their papers, which was to interleave the selection of vectors from a larger predefined Poisson distribution to get something closer to random, by using the same random number generator to pick vector indices from the set of 9 predefined ones and see if that improves the screendoor effect even further.  Others also did a blur to the resulting values to get it to look smoother, so may explore that too.

If it ends up working out, I'll update it in my fork of rend2 and will probably post a pull request!

Wow, cool. Was this something people could download and play together on a server in JK2? If it's playable, there's enough players still to try this out in JK2. I'd be interested, never tried space combat stuff in any JK game.

Yeah, it was on my old site (skew.telefragged.com) which is now down, so I need to get it from my archives. I'll post it by next week.

Here are the type of vehicle attributes that were slurped in from a text file. It was stolen from a mod I was making for RTCW, which was a top down vehicles game based on code I started for Combat Quake III Arena (itself a remake of Atari's COMBAT! for Q3)... I loved having so many Q3 engine based games at the time, since you could make your code completely portable between games.

vehicles 5 {
  
  vehicle deathstar {
    type tank
    stats {
      health 100
      armor 200
    }		
    weapons 1 {
      weapon panzerfaust 20
    }
    display {
      turretmodel models/deathstar/deathstar.md3
      basemodel models/deathstar/deathstar.md3
      turretshader models/tanks/photon/bluespin
	baseshader models/tanks/photon/blue
	turretskin none
	baseskin none
    }
    sound {
      movesound1 tanks/panzertank/sounds/movesound1.wav
      movesound2 tanks/panzertank/sounds/movesound2.wav
    }
    physics {
      type treads
      width 30
      height 15
      maxspeed 240
    }  
  }
  
  vehicle tiefighter {
    type tank		
    stats {
      health 100
      armor 100
    }
    weapons 1 {
      weapon mp40 200
    }
    display {
      turretmodel models/map_objects/imp_detention/tie_fighter.md3
      basemodel models/tanks/photon/lower.md3
      turretshader models/tanks/photon/redspin
	baseshader models/tanks/photon/red
	turretskin none
	baseskin none
    }
    sound {
      movesound1 tanks/panzertank/sounds/movesound1.wav
      movesound2 tanks/panzertank/sounds/movesound2.wav
    }
    physics {
      type treads
      width 30
      height 15
      maxspeed 320
    }  
  }
  
  vehicle stardestroyer {
    type tank		
    stats {
      health 100
      armor 200
    }
    weapons 1 {
      weapon venom 2000
    }
    display {
      turretmodel models/ships/test.md3
      basemodel models/tanks/photon/lower.md3
      turretshader models/tanks/photon/greenspin
	baseshader models/tanks/photon/green
	turretskin none
	baseskin none
    }
    sound {
      movesound1 tanks/panzertank/sounds/movesound1.wav
      movesound2 tanks/panzertank/sounds/movesound2.wav
    }
    physics {
      type treads
      width 30
      height 15
      maxspeed 240
    }  
  }

  vehicle jesustank {
    type tank
    stats {
      health 100
      armor 200
    }		
    weapons 3 {
      weapon panzerfaust 20
      weapon venom 2000
      weapon mp40 200
    }
    display {
      turretmodel models/tanks/panzer/head.md3
      basemodel models/tanks/panzer/lower.md3
      turretshader models/tanks/panzer/default.tga
	baseshader models/tanks/panzer/default.tga
    }
    sound {
      movesound1 tanks/panzertank/sounds/movesound1.wav
      movesound2 tanks/panzertank/sounds/movesound2.wav
    }
    physics {
      type treads
      width 30
      height 15
      maxspeed 240
    }  
  }

  vehicle ewing {
    type tank		
    stats {
      health 100
      armor 200
    }
    weapons 1 {
      weapon venom 2000
    }
    display {
      turretmodel models/ships/ewing/ewing.md3
      basemodel models/tanks/photon/lower.md3
      turretshader none
	baseshader none
	turretskin models/ships/ewing/ewing.skin
	baseskin none
    }
    sound {
      movesound1 tanks/panzertank/sounds/movesound1.wav
      movesound2 tanks/panzertank/sounds/movesound2.wav
    }
    physics {
      type treads
      width 30
      height 15
      maxspeed 240
    }  
  }

}

Anyway, I would support a combat flight sim if someone were to make one. I might be able to contribute in a few months too.

• The physics are all Newtonian physics with a thrust setting, so you need to properly manage vehicle thrust to go in the right direction.
• Entity orientations are internally managed as quaternions (and packed into the playerstate) to avoid gimbal locking. Also wrote some terrible quaternion client-side prediction which needs to be revisited.
• The player dimensions were scaled down significantly, while velocity was slightly scaled down, giving the illusion of high speed in large spaces. It took 8 minutes to fly linearly across one dimension of a map from end to end. All the example models were pretty much to the right relative scale: fighters to star destroyers to death star...
• The .md3 radius field (supposedly used for culling .md3s based on  distance of the origin from the edge of the frustum - but we didn't have the engine source at the time so who really knew!) was increased through a model processing tool I wrote, so you could make massive models that would always be visible (i.e. death star)
• Created a targeting system that allows you to cycle through entities in distance order, and paints a reticle on them in screenspace.
• Created some viewmodels of cockpits (totally untextured yet)

 

This one. How to change it?&&0

That box is this object in the setup.menu file:

itemDef 
{
	name				setup_background
	group				none
	style				WINDOW_STYLE_FILLED
	rect				260 185 340 225	
	backcolor			0 0 .6 .5
	forecolor			1 1 1 1
	border				1
	bordercolor			0 0 .6 1
	visible				0
	decoration
}

That object is made visible whenever you click on any of the main option buttons. See this example where you see the "show setup_background" command:

		itemDef 
		{
			name				gameoptionmenubutton
			group				setup_submenu
			text				@MENUS_OPTIONS
			text				"Jedi Fighter Options"
			type				ITEM_TYPE_BUTTON
			style				WINDOW_STYLE_EMPTY
			rect				80 257 170 24
			font				3
			textscale			0.9
			textalignx			160
			textaligny			2
			textalign			ITEM_ALIGN_RIGHT
			textstyle			0
			forecolor			1 .682 0 1
			visible			1
			descText			@MENUS_CONFIGURE_GAME_OPTIONS

			mouseEnter 
			{ 
				show			gameoptionsbutton_glow
			}
			mouseExit 
			{ 
				hide			gameoptionsbutton_glow
			}	  	  
			action 
			{ 
				play			"sound/interface/button1.wav"

				defer			VideoSetup	videowarningMenu
				show			setup_background
				hide 			video
				hide			applyChanges
				hide			video2
				hide			vidrestart
				hide			sound
				show			options
				hide			langapply
				hide			mods
				hide			defaults

				setitemcolor	setup_submenu		forecolor	1 .682 0 1 ;
				setitemcolor	gameoptionmenubutton	forecolor	1 1 1 1 ;
			}
		}

That object has the style WINDOW_STYLE_FILLED which will get drawn like this in the code:

if (w->style == WINDOW_STYLE_FILLED) 
	{
		// box, but possible a shader that needs filled
		if (w->background) 
		{
			Fade(&w->flags, &w->backColor[3], fadeClamp, &w->nextTime, fadeCycle, qtrue, fadeAmount);
			DC->setColor(w->backColor);
			DC->drawHandlePic(fillRect.x, fillRect.y, fillRect.w, fillRect.h, w->background);
			DC->setColor(NULL);
		} 
		else 
		{
			DC->fillRect(fillRect.x, fillRect.y, fillRect.w, fillRect.h, w->backColor);
		}
	} 

This means that if you set the "background" key to a shader for that menu item, it would draw the background shader using the "backcolor" color vector.

If you don't have the background key set (just like it is in the setup.menu file by default), it will draw a rectangle using backcolor directly without any shaders.

Hope this helps!

EDIT: Long story short, set a "background" key with whatever shader you want to use in the setup_background item!

@@GPChannel The idea and overall look of the lightsaber blades + saber glow, I was trying to get across to you before (Not very well), is this:

 

 

The blue lightsaber in the game, should resemble the same colour & glow of Obi-Wan's lightsaber, in the above picture (left). This is the same colour as Anakin/Luke/Finn/Rey's lightsaber in TFA. If you can replicate this, this would be fantastic!

 

Hope this helps!

 

**Note**

The above image was taken from the Jedi Academy "Jedi Fighter" mod, found here:

http://www.moddb.com/mods/jedi-fighter/images/jedi-fighter-beta-2-character-list#imagebox

For what it's worth, I didn't do anything to the standard Jedi Academy saber blade shaders when I made that saber for Obi-Wan. And the color is just the normal blue. It might look brighter around the glow because it's blending with the blue background, which itself is transparent.

jf_obiwan1
{
	name		"Kenobi 1"
	saberType	SABER_SINGLE
	saberModel	"models/weapons2/saber_obiwanep1/saber_w.glm"
	customSkin	"models/weapons2/saber_obiwan/jf_obiwan.skin"
	soundOn		"sound/weapons/saber/saberon.wav"
	soundLoop	"sound/weapons/saber/saberhum4.wav"
	soundOff	"sound/weapons/saber/saberoff.wav"
	saberLength	40
	saberColor	blue
}

EDIT VVVVVVV: Don't want to hijack this thread. Another beta will be out by April and final release by June. Beta 2 was a proper release though. You should try it. Post feedback on the moddb forum!

I updated JAFont to create fonts with different width and height in order to make properly scaled HD fonts for Jedi Fighter for various aspect ratios.  

The executable, full source, and everything is available here.

Please use it for your mods! If you run into any issues, please let me know.

Thanks to Wudan and the OJP team for making the first version.

Enjoy!

------------------- BEGIN README.TXT ------------------------

I'm going to echo everyone else's sentiments and say that this looks fantastic. The settings look like believable encounters in mystical lands, and the characters, their weapons, and the different effects looks as if they're all pretty cohesive.

Someone else mentioned that you ought to try to sell this and I totally agree. Get the gameplay figured out and then try to get it greenlit on Steam.

EDIT: Actually, you probably couldn't because it looks like you've still got some of the JA assets, like at least some portions of the humanoid animations. Maybe you could ask for permission from Raven...

I tried to make a list of the different sites that linked to it over the last few days. It's awesome to see that people are still interested in mods like this.

http://www.kotaku.com.au/2016/01/theres-a-mod-that-sort-of-turns-jedi-academy-into-street-fighter/

http://www.kotaku.com.au/2016/01/mod-turns-star-wars-shooter-into-2d-fighter/

http://kotaku.com/mod-turns-star-wars-shooter-into-2d-fighter-1754846197

http://www.gameblog.fr/news/56334-un-mod-transforme-star-wars-jedi-knight-en-jeu-de-combat

http://www.playground.ru/blogs/star_wars_jedi_knight_jedi_academy/shuter_po_motivam_star_wars_prevratili_v_fajting-178928/

http://www.melty.fr/un-star-wars-a-la-street-fighter-a494062.html

http://www.tweaktown.com/news/49942/cool-mod-turns-classic-jedi-academy-fighting-game/index.html

http://www.meristation.com/pc/noticias/jedi-knight-se-convierte-en-un-juego-de-lucha-con-un-mod/58/2106009?id_externo_promo=meri-ob&prm=meri-ob&ncid=meri-ob

http://www.hobbyconsolas.com/noticias/star-wars-jedi-knight-convertido-juego-lucha-gracias-mod-135806

http://www.pcgamer.com/mod-turns-jedi-academy-into-a-fighting-game/

https://www.reddit.com/r/Fighters/comments/42mbuq/jedi_fighter_jedi_academy_2d_fighting_game_mod/

http://www.gamestar.hu/star-wars-jedi-knight-jedi-academy-jedi-fighter-2d-verekedos-jatek-mod.html

http://blogjob.com/oneangrygamer/2016/01/jedi-academy-mod-jedi-fighter-turns-battles-into-a-street-fighter-like-game/

http://www.slashgear.com/mod-turns-jedi-academy-into-a-1v1-star-wars-fighting-game-25424231/

http://gamerant.com/star-wars-jedi-knight-fighting-game-mod/

http://news.douxie.com/zx/40808.html

@@skew If I were you I'd be pist about the that quote.

I tried to contact them to correct it (and posted comments to that effect) but didn't get a response.

I'm not pissed but thankful because this made Jedi Fighter jump to #4 on moddb momentarily. People playing it is all I wanted .

There are a lot of follow-on articles on other sites where they get the facts right so I'm not too concerned.

News about this mod has been picked up by Kotaku:

http://kotaku.com/mod-turns-star-wars-shooter-into-2d-fighter-1754846197

Awesome, thanks for sharing. They did get the quote wrong though... this doesn't have the revamped AI yet, and no botroutes are going to make this look like a total joke when not playing against people. Oh well!

Wow. Nice work. That's genius. if I understand correctly, that wouldn't work in vanilla JKA then, otherwise the camera would move, correct?

Right. The in-game solutions works well when the camera is separated from the viewangles of the actual player because all it does is move the viewangles that translate into client model deformation. If you turn off the jedifighter camera, you'd see the player bobbing his head up and down proportional to his health.

You could do it in-game if you used the method I did in the UI, though. I wanted to keep the fighters actually facing each other, so I applied the viewangles grossly as the base of the neck and then applied the inverse of those angles when you go up the spine to the cranium. This way they're technically keeping their faces parallel. That would stop weirdness from happening with the normal third person view.

I'd rather have a blocking system! That would be awesome. 

It has a pseudo functional blocking system... While you have the block button held down, then it'll clash sabers, do knock-aways and parries depending on saber skill level.  It kinda of works but is pretty terrible.

I'll make that a higher priority for the next release.

Got any thoughts on what you'd want to see in a blocking system? A blocking stance that gets held where you can adjust blocking direction or something? I really want to incorporate parries to do counter attacks (like in the Last Blade games) in the next version so it would need to be conducive to that.

I really like this, congratulations on bringing something fresh to the modding scene.

Thanks, appreciate it!