simple machines forum

Patch

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

Continuing to update via patches, this patch fixes a twitch when bending over in front of walls I introduced in a recent patch and fixes a bug that had let projectiles pass between level geometry polygons when aimed at the seams, and upgrades the wall clipping math.

The last detail is significant, but first I must add there are some files changed that require using SVN Update. These are upper arm sections for two arm equipment items and a new MHM clip model for the tile that is like half of a column embedded into a wall, and changes to their PRT files.

After I made the change to this MHM model (the old one modeled the column with just a slab) they revealed the clipping issue I sought to address in the past days. After I finished that yesterday I looked into the projectile bug which I've been aware of for a least a couple years, and I discovered the MHM hit detection code there was particularly bad (SOM's code is not the work of geniuses, in case anyone is wondering) so I just rewrote it all and managed to fix the bug along the way.

As for the new wall clipping logic, it uses a significantly different approach that is much more accurate with the goal of being able to pass through any opening that will accommodate the clipping radius (developers should be able to assume if there is a 1 meter opening players will be able to pass through it.)

I'm pretty confident I implemented this correctly, but it's new. Because it's more accurate a problem arises because if you consider a corner, if you approach it, you might hit both walls, in which case whichever side happens to be first in the model data will predominate. If the code is very accurate it will make it impossible to touch the other wall. I might change this by adding some reflection logic, but the end of result of this change is the model is more "sticky" so to remedy this the best I could think of was to reverse the order that the polygons are considered every other time. That way the other wall in the corner can exert an influence in the case of a draw. In this way the stickiness mostly goes away, but it's a short order fix to a brand new system. I just have to get it off my work stack right now.

The old system was sticky too, so I guess very possibly this new system is better, but the top priority is removing those instances where the old model resulted in invisible barriers. I guess I never noticed since as long as they don't create a passage narrower than the clip radius usually you wouldn't notice them.

The technical differences is I used the section of the clipping circle (on the ground) and the wall's plane (upright) as the clipping radius for testing 2D penetration of the polygon outline. Usually this is much smaller than the fixed radius that was being used. But in one case at least, it can be a problem, so I resorted to a hybrid system that maxes out at a half radius, which was the old system's way. That problem case is if you find yourself right on the wall's plane, which can happen if you approach it from beneath an archway.

Another step lessens how far the clip shape is ejected from the wall so that if it's on the wall's lip instead of being ejected all the way out, it just ejects to where the clip shape (column) would be stopped by its own geometry. Like if you pushed a cylinder against the edge of a wall forming an exterior corner then depending on how far the cylinder is from the corner, more of the cylinder can pass behind the plane of that wall before actually coming into contact with it.

I think the old system dealt with this by using half the radius for the 2D geometry penetration test and using the full radius for the plane test. I think that's an interesting hack but leads to the problems this change addresses. In other words it had pretended like the walls were inset by half the radius. But only for some of its math. Part of me wonders if this is actually smart, but I think it's not something that can work with the new system since its radius isn't a fixed value.

Also for this second step (ejection) the code could be a lot better. Instead for time sake I've just treated every polygon like it's an upright rectangle. It can be improved (later when I have time) by clipping the top and bottom to the base and height of the clip shape and finding the point on the diagonal where the clip shape touches the polygon if it's not a rectangle polygon. Most clip geometry is rectangular, so this is good enough in the meantime.

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

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.

Before I forget, I added a lot today, but I'm a little too tired to speak to it. Before I switched over to fixing the recent security breach problem I think I got the jump direction straightened out to a large degree just by adding some code that cancels out antagonistic inputs, that I thought already existed. (The jump system is a chief source of these because it acts like a capacitor of inputs, which it remembers even if they're antagonistic.)

Because I was working on SFX things today I was all over the place in the code in the new Ghidra decompiler and project manager software so I ended up doing a lot of miscellaneous things.

I added an arm_ms_windup [Player] extension that compensates for the fact that I've made SOM to not issue attacks until buttons are released. It can shave a few animation frames off the front of the attack animations. I set it to jump 150ms into the attack by default, but KF2 I set to 300ms (which is the limit) at least until I decide to remove the front of the its animations to try to make it usable to other projects. This can be used by players who want more or less responsive attack timing.

Likewise I relaxed the magic gauge requirement so that it's more like if the gauge is full when you are looking at it that you can still use magic, of course by the time you look at it and your brain hits the button and releases it that was a long time ago in computer time, so maybe by then it's drained away a little, but anyway that's the thinking behind it.

Part of the reason I did this is because I made the gauges more forgiving/responsive when crouching and holding onto walls so that there is bit of "cover" game you can play if you lean out from behind walls and fire off your magic and pull back.

I also made my project's fireball's clip radius even more slim than I already did partly so it doesn't blow up in your face when you fire it from behind a corner. (When crouching there's a tendency for it to shoot straight into the floor.)

And partly because I ran across the code that sets up the particle emitter for magic, so I could adjust it to factor in the crouching height and full range of looking up and down with the direction pad.

BTW, something I've been meaning to work on for a while is the problem in the demo (and with SOM right now) of falling between cracks. It's most obvious on the rope bridge. I've actually been meaning to address this for years... but I actually came up with a plan only a while ago. It's definitely something I hope to fit into the demo I'm working on, if I don't get so behind that I just rush it out without a lot of things I'd like it to have.

The reason this happens is because of an extension that's designed to not let you hover out over ledges like Wile E. Coyote, however the problem is, how it works, to be 360 degrees, like all features, is it shrinks down the width (radius) of the clip shape, so that works great if there isn't a crack on a ledge, but if there's a crack it means you fall between it as your shape gets smaller. (A "crack" is like a ledge sandwich, for example.)

For a while I thought I might need some kind of complex analysis to solve this, but I realized there is a real simple way that is probably for the best, that is just to do an additional clip test (a lot are done already) with the full width shape displaced by the ledges around it (at the elevation it will be after falling) and if the displaced shape still hits a ledge, then that means it can't fit into the hole it's trying to fall through. It's really so simple I don't know why I didn't set that up already. Maybe I'm missing something but I don't think so. A downside of this approach is it's extremely conservative and won't let you fall through any small holes, but I reckon that's probably actually a good thing.

EDITED: I also realized the Shift and Control buttons on the right side of the keyboard hadn't been considered for years, forever really. I guess I thought I'd merged them a long time ago. They're swapped like the left side now.

So, it turns out when I migrated the site to a new host a while ago I didn’t know that the authz_svn_module module had to be configured to get vanilla protection of the Subversion files containing the Sword of Moonlight downloads, so it turns out somebody or something was making revisions to the files, so I’m scrambling to try to restore it.

If you had the misfortune of downloading these files, the first ones are listed on the full page of this post (go through the “Continued” link) so you can see if you have these among your personal files. If you do I recommend deleting your installation and go back through the download and install process.

I’ve ripped out all of the changes since I migrated. I’m going to put them back in as soon as possible, but in the meantime they’re missing. They’re listed below if you want to try to recover them, except for source code changes. I think this shouldn’t have happened if the Apache and Subversion teams were more humanistic in their software design practices. Something you often run into with open-source projects is a callous disregard for basic use cases.

Right now I can’t seem to synchronize my personal files with the hosted files because I had to rip the offending files out of the database, and unfortunately Subversion doesn’t provide a tool for this. I don’t know if it will work from a fresh download or not. My files think they’re out ahead of the real files which is a scenario TortoiseSVN doesn’t want to account for. If I had a back up handy I’d just restore it to the state before migration and start over, which is what I’m trying to do ASAP. That revision number is 361 and as soon as I get things back in order there will probably be a revision 362 with the files I had to remove yesterday.

(On the bright side, I guess our “intruders” can be credited with helping to highlight the hole in our defenses. A lot of the files were Windows style DLL files, so be careful in case any of them are malware.)

The list below is legit changes that are temporarily missing.

372
/data/menu/NWSE.bmp
/data/menu/NWSE.txr
/data/menu/NWSE1.mdo
/data/my/prof/Ex.ini
371
/data/my/prof/Ex.ini
370
/tool/SomEx.csv
369
/data/map/mhm/yk4220.mhm
/data/map/parts/0096.prt
/data/map/parts/0224.prt
/data/map/parts/0352.prt
/data/map/parts/0480.prt
/data/map/parts/0608.prt
368
/data/obj/prof/0012.prf
/data/obj/prof/0013.prf
/data/obj/prof/0014.prf
/data/obj/prof/0015.prf
/data/obj/prof/0174.prf
/data/obj/prof/0175.prf
/data/obj/prof/0222.prf
/data/obj/prof/0287.prf
/tool/SomEx.csv

This list is a subset of the offending files that you can use to determine if you have a compromised set of files. Really I suppose I could just list one of these, but it’s just a copy/paste job of the first revision with bad files. Some of these look like someone might have made a mistake, not knowing how to use SVN or something, however one (assuming they’re from the same party) modified SomEx.dll and some other executables and some of the language pack files, including adding some of the translation files to the versioned files that aren’t supposed to be. So you could be running these files unfortunately.

/HEAD
/config
/description
/hooks
/hooks/applypatch-msg.sample
/hooks/commit-msg.sample
/hooks/fsmonitor-watchman.sample
/hooks/post-update.sample
/hooks/pre-applypatch.sample
/hooks/pre-commit.sample
/hooks/pre-merge-commit.sample
/hooks/pre-push.sample
/hooks/pre-rebase.sample
/hooks/pre-receive.sample
/hooks/prepare-commit-msg.sample
/hooks/update.sample
/info
/info/exclude
/objects
/objects/info
/objects/pack
/refs
/refs/heads
/refs/tags
/svn
/svn/.metadata
/svn/refs
/svn/refs/remotes
/svn/refs/remotes/origin
/svn/refs/remotes/origin/git-svn
/svn/refs/remotes/origin/trunk
/svn/refs/remotes/origin/trunk/.rev_map.908064de-85fe-4402-a909-d45d0ebbf1e1

As of this time I haven't been able to overwrite the files with the ones from before I migrated the site. I will update when I do so. Just in case you want copies of the new files that I've taken down I've attached them to this post, although you'll have to sort them into their respective directories.

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.

I thought I could find a topic/thread for this post, but alas no... for the record yesterday I FINALLY worked on a strategy to eliminate false positives from the jumping system!

It seems like an improvement. This is actually important but something I kept thinking to myself I would get around to one day or another and never would.

The jumping system has been one of those incomplete things that I would immediately fix if I got wind of someone about to publish a game with SOM. But since nobody has it's not been a huge priority. False positives (accidental jumps) is one of those things that players would be right to not put up with.

How the changes work is to try to tell when the thumb stick is being let go of as opposed to when it's just being moved through the center manually. To do this there is a delay after the jump is inputted to wait and see if the stick lands in the center or crosses over it. This means the jump doesn't happen immediately.

It's programmed to wait 33ms more right now. Anything longer than this is probably going to feel weird (unresponsive, jerky, etc.) so I wasn't sure at first if this strategy would work or not.

I can move the stick around wildly while pressing the dashing button down and releasing it without ever jumping, but I think there is still a chance for unwanted jumps, just a very small one. My attitude toward accidents in games has always been that we have accidents IRL too and so we should embrace them in games and look at them as an opportunity to send us down a different path or just make things interesting from time to time. Hopefully you don't jump to your death, in which case I wish SOM had better features for recovering from that scenario, meaning that in time I will program in more and more safety net features. But right now you just have to suck it up.

EDITED: Big things I still need to do for jumping is to take a look at trigger (analog) buttons since I only added good support for them this year and they're not currently as satisfying for jump inputs as a regular (digital) button, and I think that the direction of the jump should be considering the raw input from the controller somehow instead of using the gait system, which has very low resolution by comparison (between 3 or 4 bits technically speaking.) It will be much better by the end of the year.

Random update

I told myself I would add the pirate skeletons, mosquitoes, and sigils today, rounding out the demo's monsters and NPCs, but instead I found myself (again) obsessing over the color function to see if I could make it better, just by luck I guess, since I've never had the good sense to set up a proper UI for dialing parameters up and down. And in this case it wouldn't work anyway since the function is hardwired into the shader.

Usually this just gets me on a roll whiling away hours possibly, playing with the numbers, but I decided to consider if my old formula was wrong to scale the texture colors when mapping them into the power function, mainly because I'd reached the limits of what I could do to try to improve the color because I always ran into the problem with the bright marbled ceilings becoming to garish to go on.

To my surprise I found out I could make almost anything look acceptable by scaling and shifting the outputs a little bit. I think this is a problem I often run into where either I assume that if a bug can exist that it will appear instantly, since it's hard to imagine most would not, or in this case, if something works, then I assume that there aren't other solutions that would work too. And so don't go further.

So I decided the old solution to the color was too baroque and so started looking for a simper solution, and I eventually convinced myself the power for the formula was 1.25 instead of 1.5. Even though a little surprised I was pleased that less power meant the ceiling situation could be less going forward, and I kind of knew the power had to be less because I thought probably the color in the textures just mapped far enough to cover the unused space in the palette.

Oh, and something important I forgot is my first experiment was to situate the middle of the color on 1 for the power function, whereas the old formula set the brightest color at 1 and shifted the darkest colors up, so instead of making a hump it was just a ramp. What surprised me is that both approaches can appear so similar even though they're radically different. (And as a reminder I sat down and compared individual pixel values with the old formula, so it was accurate over a large swath of the game's surfaces to the pixel value. But there were a few cases it couldn't cover. I checked all of those cases with the new formula and everything seems to match. But I haven't sat down to test pixel values and the new working formula is just an approximation. I actually don't like the standard color so much, so I'm not super concerned with perfecting it since the lighting is pretty much hammered out.)

Maybe this is more critical than figuring out that the power is 1.25. My motivation for shifting the center was the ceiling again. I thought if I could position it in the center then the power function would affect it least.

The black fog's power is 1.25 too. Speaking of which, yesterday I worked on the little fireflies around the lighthouse. I think these are called Fire Elementals in one version of the game or both?

The first problem was finding out if SOM could do them since something like them had never been demonstrated. Although I think I remember someone finding the necessary data in the SFX.dat file. I think KFII just copies the sprites directly onto the screen. SOM doesn't do that that I know of, at least not for its little "flame" sprites. I had to use a flame for the fireflies and was able to make it face the screen in both directions, however I think it needs some work because it doesn't take into account the direction you're looking, so it isn't as convincing up close as in KFII. I assume it's possible to refine it, but I don't know with certainty.

Finally, I knew that I would have to add something to make them blend into the fog. I think ever since I added the "shader" system to SOM I purposefully made sprites to not disappear into the fog. I also found out yesterday that the sprite system always treats sprites as transparent elements, so you can't even make one that isn't part of the transparency layer.

Originally SOM didn't apply fog to any transparent elements, so technically speaking sprites were never in the fog, although they were as some point, and still may be if you bypassed the shader system.

My reason for excluding them is I thought that they just looked better if you could see the flames even when everything around them were still in fog. It makes sense since the flame should stand out from the fog. Some of the monsters with flames are more ominous since you can see the flames peeking through the darkness before you can see the source.

But the sprites appear out of nowhere since they aren't blended into the fog. I never really noticed until now. I guess it needs certain conditions to be noticeable, like for one, a short draw distance, otherwise the flames might first be so small in the distance as to go unnoticed.

Nevertheless what's called for is a smooth transition, as always. In fact I don't put a lot of stock into "graphics" for SOM but I do take seriously smooth transitions, no sharp edges in other words. So what I've done is to change the fog factors just for sprites, and add some new extensions to cover this, that are fov_sky_and_fog_powers3 and fov_sky_and_fog_powers4. The default behavior is to use 70% of the sky power and 35% of the fog power. This may not always be acceptable.

The idea is for the sprites to just appear almost like a lamp turning on. Not out of the blue but pretty quickly so they're at their full brightness almost as fast as snapping your fingers.