Sword of Moonlight > Devs

EXIT: Unleashing monsters

<< < (3/6) > >>

Holey Moley:
For the record, earlier today I uploaded a fix for the F4 flying thing that by changing it to work with the controller, I broke it working with the Alt key, and also, to repeat some edited into yesterday's announcement, I had to reupload because I put a debug mode build up the first time.

Edited: Crap, actually I didn't upload the F4 fix because rain had knocked out my Internet access, so I thought I did, and I couldn't upload until the next morning. I have to go out and trim some tree limbs around the satellite dish. I'm pretty sure it wouldn't have been as bad without those tree limbs in the way in way. I feel dumb making these updates since unlikely anyone downloaded it. The patch to my KFII demo yesterday should include the fix.

Holey Moley:
Neato Patch (some under the radar fixes)

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

This patch holds a bevvy of quality upgrades for the movement system.

I got sucked into working more on trying to minimize false positives in the jumping system yesterday and began to notice the jumps were sometimes a bit halted in their movement, so I really dug into what the problem could be, investigating everything. The old jump system was designed to cancel out some assumptions based on how SOM's pseudo (flying squirrel) gravity works that seem to no longer hold.

I guess at some point one of the (many) changes to the clipping system changed this behavior. So the extra oomph it was programmed to give on the first frame of the jump was adding to it instead of canceling out and throwing off the descent as well. So I just removed that and some other stuff and tried to figure out why the jump was underpowered, which related to some new changes in this patch that smooths out the frame rate (I was keeping the fractional part of the smoothed frame rate for some stuff and not others and the difference in rounding was enough to reduce the jump height/impact.)

So, this fix is the biggest non-feature part of this patch. The jump arc is smoother than ever and very fluid.

This fix also solved some ceiling interaction issues I was having with my KF2 demo.

I've done so many upgrades to the movement system this week I probably can't recount them all. One of the biggest is there is now a tentative system for making the bounce effect depend on the field-of-view so I was really able to push it to the limit instead of trying to find a one-size-fits-all compromise.

Climbing now has a bounce like effect, but just the head tilt and not the knee bend part. Landing a jump without stopping feels a lot better now. There are two ways to land a jump, one (stopping) is a deep knee bend, while the other is just kind of hits the ground running. This one is far more dramatic now but somehow less noticeable.

There's a friction system that ties into grabbing the wall. It slows you down when you rub harder and harder against the wall. I added it just so it feels less slippery (don't slide off things when pushing against them) and it's very subtle by design, so you might not even notice it.

It's now possible to look all the way down while crouching and even while leaning out. You can even look the furthest down I think by crouching and leaning out. I guess that feels about right if you wanted to look down the side of a cliff. This may tie into a system for climbing down off ledges at some point. All the way down now means like 110 degrees or more.

Like I said, there's a new system for eliminating false positives so you jump by accident less. But I ran into some problems with my controller momentarily crossing over to the opposite side of the sticks when releasing it, instead of stopping in the center. This is what got me looking at it again yesterday. I made a lot of other changes and by the end the problem wasn't occurring for me, but it could just be my stick was having a good day. But I just left it alone for now. (One fix could be just one frame of smoothing the input data would probably prevent it from going that far, but I know I'm using a much smaller dead-zone than PS4 games do, so the obvious fix would be to increase the dead-zone, but I'm hesitant to do that. But too I worry other peoples controllers aren't going to work if I don't increase the default anyway.)

In short, I want to push this patch out since it presents a more competent movement system.

Holey Moley:
Patch Patch

EDITED: http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

Unfortunately, I've had to compromise the new filter that prevents some jumps because the logic it uses is to cancel jumps that crossover the middle of the direction pad, taking that to mean it's not a jump input... but it turns out that even though you can't see it in the DualShock4 controller, it crosses over up to like 33% of its effective output, so it's really not possible to tell if the stick is let go or pushed. I mean, it'd be really hard to push it to the center without going over, and I wish that was how they worked, because then the jump could know you let the stick go and didn't just move it.

It's also counterintuitive that the sensors are saying the stick is at 30% (for a split second) even though the stick itself isn't. It took me a while to convince myself this was happening. Even the Control Panel calibration too doesn't seem to show the stick bouncing over.

How I've dealt with this is to make the detector less sensitive during the jump window so that when it goes up to 33% it doesn't appear to get out of the dead zone, but this also diminishes the filter's ability to detect crossover...

So, after the jump is initiated it starts returning sensitivity, with the thinking that the springs will snap into place faster than a player's finger, and so to get the desired effect you have to overcome this insensitivity and you only have one or two input frames to do so, depending on the frame rate (2 at more than 30fps.)

Because of the short window the system works best for fast movements, like sudden stops. If you're moving your thumb slowly it's going to register as a jump most likely. That's why you shouldn't make a habit of releasing the action button while moving/releasing the dpad.

Holey Moley:
Feature/crash fix patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
http://svn.swordofmoonlight.net/data/my/model/ARM.MDL

I was about to possibly put out a new release but in the last minute I somehow crashed the program in a way that hadn't happened before, so as a result I want to patch this crash that was introduced in the previous patch, and as it just so happens the patch includes what would be in a new release, so I'm possibly just going to keep rolling things into this release via patches.

I may make a blog post with or without a release. I will have to see what I feel like doing.

The crash happens in the jump system because I had it to read past the end of a buffer. It's a wonder it didn't show up until weeks later, but that stuff just happens.

This patch includes the new 60fps code I've been working on for a long time, and it changes how the arm is displayed when attacking, so I've included a new-and-improved ARM.MDL file (link above) that you want to make sure is in your DATA/MY folder.

This ARM.MDL is a lot better but the animations are identical to the old one. I think that its animations should probably be changed too, eventually, but what to change them to is a major decision I can't deal with right now. I do think the chop should be centered and not twist around. The thrust seems pretty lame too.

A lot of work has gone into this upgrade to 60fps animations and effects. The attack animations now have four times as many frames, but to do that they are blurred together to form a sweep of afterimages. And the transparency effect used is not great, but it's the same as the one for fading things in.

I definitely want to program a better system for the transparent elements before long. By that I mean a full BSP triangle sorting/partitioning system.

Holey Moley:
Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

Yesterday I forgot about how the arm/hand equipment pieces have extra models that displace the ARM.MDL sections.

This patch addresses that omission and makes that system a little more flexible since before all 3 MDO files were required, but now if one is absent it will use the ARM.MDL geometry.

Most of these items have dummy models for the shoulder/bicep part of the arm so I took the drastic option of deleting those files. The problem with this approach is you need this version/patch of SomEx.dll to make it work without those models. I didn't want to upgrade the models with the new bicep/shoulder work I did.

Two items have alternative models for this section. I have to take a look at them. One seems to have a pauldron or something that is closed off, so technically it's okay I guess. The other has a hole in its shoulder like the old ARM.MDL that I have to fix when I can get around to it.

All of these models require work to switch over to soft shading to match the new ARM.MDL file and I think that this system should be more flexible, and ideally the ARM.MDL should not be displaced as long as the pieces aren't in conflict with it, so that they don't have to copy its geometry since that's error prone and inflexible. But changing how this works on a more fundamental  level will require more elaborate extensions and even more work.

Luckily unless you pause the game these arm models fly by so fast you can't see them well. But the hole in the shoulder is definitely possible to pick out. I have to fix that. Really it seems to me that the body equipment should cover the shoulder. Of course both can as long as they don't come into conflict. I actually thought maybe that's how it worked, but it turns out not to be the case. (I'm not as familiar with SOM as you might guess, yes I know more than anyone surely, but there's a lot I haven't looked at that people who've made games all have to deal with at some point. That's caused communication problems is the past. Making my own game with SOM is a big help here, although unfortunately my memory tends to slip away faster than normal.)

Navigation

[0] Message Index

[#] Next page

[*] Previous page