Boothand

Well, the duck and the horse are without 'caps', so when they lose a limb there's a see-through surface underneath. Also their hands/fingers aren't rigged as well as the base models, so they will sometimes not appear to hold the hilt properly.

Haha, nice! Nice.

Kyle defeating Desann at Yavin

So far, only yellow style has been enabled. An idea is to make yellow the slightly faster, technical and close-distance style (though still well within most people's reaction time), and red style a slightly slower but more range-seeking sort of big-sweep style. If blocking animations are different based on your style, that would be only eye-candy at least. I just added upper diagonal block animations, and I'm happy with the animations, and semi-happy with how it feels like to see them triggered in game. Like I said, they are triggered automatically if you choose the correct side (left/right). I don't know if that sounds lame, it sounds like something I could be skeptical to, out of context, but blocking is already difficult. Three directions are plentyful when combined with JK2's movement (though slowed down), using movement keys for blocking as well. I'm considering a stab/thrust, starting from something like a "pflug" (http://www.encasedinsteel.co.uk/wp-content/uploads/2015/06/Cod.44.A.8_001v.jpg, the guy on the left), which would either require a fourth block direction, or would be blockable by forward/backward/nothing movement. Just to be on par with Mount&Blade M&B's advantage is that the movement is so clunky that all the focus falls on the weapons. We'll see..

Haha You could always try it locally against bots. They won't be doing any blocking, and since they mostly run away from you it's hard to simulate an actual fight with them. But it works if you just wanna stress test yourself against an unpredictable bot. Oh, I forgot to say - there is location based damage (only for sabers atm) and dismemberment corresponding to which part you hit. I'll get back to you later about testing, not at home yet.

Hey, thanks You're in luck, I've been working on this non stop-ish for the past 2 weeks - before that, a huge break. It's gone through some changes after testing. At the moment it's cut down on difficulty, trying just to get the gameplay I'm after before I know how many directions and stuff can be expected to be used. Custom animations have been made/edited, based on a slow yellow style. At the moment, there's left block, right block and top block, so only three block directions, and I gotta say it's still pretty hard to block the top one in the heat of the moment, other people think this too. It looks pretty cool though, for the side blocks, it looks at what attack the opponent is doing and if you're blocking at the correct side, it chooses the correct lower or upper animation before the impact even. I have plans for doing the same with a custom anim for diagonal blocks, though for now it will be only for the sake of eye-candy, but I think that's important. I've spent a little time on blasters as well. Blocking gun shots requires a key-press on manual block for each shot, so it takes some concentration. Guns are more powerful, but won't fire as rapidly. Bullets gets reflected as usual, but in the exact direction you're facing, so they go where the cursor is, instead of in a random-ish direction based on where the shooter was. In the same go, I'm making some changes to impact effects, making blasters seem more powerful by adding a lot of smoke and sparks where they hit. For now. If you're interested in trying, I can send you the latest clientside and we could have a go, later today or tomorrow. Have not yet tested if it runs smoothly on high pings, in case you're not from Europe (?). Otherwise, it should still work as intended. My schedule today says to make an animation rig for blender (or to try), so I can make less messed up animations.

Ok, will give it a try soon then!

When editing and creating new animations, I start with importing animations and so on. Would it be worthwhile (or possible) to learn how to create an IK rig to use and animate, and simply export after that? Would new animations get imported onto that rig set-up or would it find a conflict/import the old one? The reason I'm asking is because while I'm not uncomfortable with rotating limb by limb, it doesn't have the hierarchy necessary for that - so when I rotate the elbow, the hand doesn't follow, and fingers etc. If it did, I wouldn't need the above. But even if I somehow figured out how to fix that, would I need to do that every time I imported a new animation?

Yeah, it's only for multiplayer. With ++ I meant from 1.1 and all later versions, sorry for confusion

That never occurred to me Yeah, that fixed the offset animations! AND, it turns out they get put in the very end, so in case someone else is wondering, that's where your frames go! THANKS!!!!!!!

I'm making new animations to be used in JK2mp. Got some trouble, don't know where my frames have ended up, and after using GLAmerge, watching animations in modview displays the base animations incorrectly, like all the starting frames have been offset in animation.cfg, caused by the merge. So: Importing the _humanoid.gla and editing an animation is no trouble. I put the base pose in the first frame, as instructed by the GLAmerge manual. I create the marker and name it Boot_Testanim1, set the end frame in Blender to 9, the length of the animation. Exporting the boot_animation.cfg is fine, shows up with length 9. I export the .gla, putting "models/players/_humanoid/_humanoid.gla as the gla reference, rest is blank. I take the exported .gla to GLAmerge and merge it with the original .gla. It outputs a file slightly larger than the original, so it makes sense so far. I replace the old with the new _humanoid.gla, but since I don't know where the frames have gone, I don't know what to set as starting frame in animation.cfg. But in any case, as mentioned, all animations seem offset now, so something must be done differently in Blender or GLAmerge. Does anyone have a clue what goes wrong? @@mrwonko @@DT85 @@eezstreet @@katanamaru (?) @anyonewhohasdoneanimationstuff

With Jk2mv 1.1 and ++ you can load JKA models in JK2, so no need for conversions actually.

The JO multiplayer community has a place at at JK2.info, but not sure if you're interested in single- or multiplayer. We have hosted mods that we've received permission to host (as has JKHub, just more so), so you might need to go back and forth. Buuut, you could always take a look at mrwonko's archive, which contains.. a lot. http://mrwonko.de/jk3files/Jedi%20Outcast/

Ultimate Weapons mod really is a treat, with some modifications. Weapons feel much better, and looks more like the weapon effects from the original trilogy (shots smoke and burn with impact etc). Although you may not want to modify anything, I prefer the base lightsabers, with these saber sounds.

Had some great fun ^^

I'm playing it now, the beta. It's pretty fun. And the graphics actually makes it more enjoyable.

I was replying to another thread when I realized I should make a topic for this, because I love to talk about it. How do you think a realistic lightsaber fight would play out in practice? First, some assumptions: Single blades (without handguards) are used and share the weight and air resistance of lightsabers seen in the old trilogy (most likely requiring two hands to use properly?).Blades can slide somewhat along each other.Both opponents are at least reasonably trained in lightsaber combat.No force knowledge plays any part.I think it would be incredibly dangerous, in a way that would change the whole approach. These are weapons without handguards, and any touch would probably incapacitate the swordhand of whoever's using it. If one compares to a duel with longswords, they were mostly likely (but not always) to consist of only a few exchanges at most before someone would be beaten/dead. The techniques used relied heavily on a handguard, and a lightsaber has (or had) none of such. So I think the lack of a handguard could turn a lightsaber fight into a hand-sniping contest, happening primarily through quick binding/winding and change-throughs, leaving hands at least as the main target. Once two sabers connect, there would be a very short way for either of them to burn through the hilt or fingers, and counters/precautions would have to be made. Once their own hands would be in grave danger, quick levering strikes could be made at the head or feet, pulling the hands away for the moment. But actual strikes only seem useful as a counter to the hand-game, not as the main play. Wasn't sure if I should reveal the nerdiest side of me, but there you have it! Any other theories?

I don't want to derail this, and I get the point of your post But. No, this is not realistic I say this because I care about sword fighting (and if it gives any more credibility, regularly practice it in a HEMA club), and while this has some other approaches than the new trilogy stuff, it does not really shed light on how incredibly dangerous any kind of advanced lightsaber combat would be (I can make another thread for that). You notice all the time with the flashy attacks, twirls and funny ways to hold the saber that this is showmanship (and in my opinion very cringey to watch for the reasons above). Okay, with that well out of the way, as I've said before, great mod! I'll give it another try soon and see how it has improved since my last run.

Sounds like a clan culture would be difficult without a server browser.

The riff that makes everything alright.

Once again, no issues in game It's only in the editor preview. Unless someone else has these problems in-game of course.

In-game it all looks correct. It's just the display in GtkRadiant that doesn't merge these points.

Hello Boothand. I found the issue for you. It seems to be merely a visual mistake in GtkRadiant 1.5. Compiling the map makes it correct, regardless of how it looks. Also GtkRadiant 1.6 doesn't have this issue.

Hi. You know when using patch meshes to create curves, as you adjust the vertices and tangents, subdivisions are generated. Some positions of those vertices trick GtkRadiant into thinking no more geometry is needed, however this makes it not match up with the neighbouring patches. There is really only one correct position for the tangents here, and wondering if any of you know a way to counter this problem? This is GtkRadiant 1.5. @@Langerd, @@Szico VII Pictures to illustrate the issue: The second picture here shows the consequences of the misalignment.