Topic: EXIT: Unleashing monsters (Read 31019 times)

Holey Moley · « **Reply #15 on:** August 04, 2020, 07:00:02 AM »

For the record I fixed a bug yesterday that made the bicep equipment piece not show for full body armor like the Forest Armor (although technically it doesn't have anything covering the bicep) and Full Plate armor (which does.) I think Verdite may have tried to explain this to me once.

I also fixed a SomEx.dll bug that didn't update the arm equipment for full body armor. This started only since back when I worked on making the inventory sortable/reordable and recalling the menu state.

I haven't published a patch for this since I've identified a new problem with clipping that requires (I think) a change to the clip test. I changed the MHM model for columns with a beveled base, and forming a 1m passage from two of these reveals the problem since it's impassible. It happens I think because the clip planes of the walls extend beyond their edges, so two diagonal clip planes cut into each other forming an invisible wall.

I may look into why projectiles sometimes go through walls at joints, which may be related to this problem. I'm also considering making platforms take friction into account so that when you walk past these columns you don't climb up onto the base like someone who doesn't know how walking works. (They're the same height as stairs but they're not meant to be stood on.)

Holey Moley · « **Reply #16 on:** August 06, 2020, 10:48:21 AM »

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.

Holey Moley · « **Reply #17 on:** August 09, 2020, 12:53:45 AM »

Patch

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

Ostensibly this patch is to remove some spurious code I missed that shifts that arm model over in wide screen mode.

It also fixes a recently added glitch that could occur when climbing a platform immediately after falling in front of it. It gave me an idea to try to implement wave interference for the bounce when falling to see if that's more pleasant than the current system. I wonder if I meant to do that originally or if it never occurred to me.

(I was also wondering today why my high school athletic team was called the Hurricanes when our state/city are land-locked and hurricanes don't happen here .. or really why this never came up in all my time in high school.)

Lately I've been converting KF2's arm model to use SOM's system. Today I tweaked the arm display system a lot. I was actually able to make it look like KF2's arm. But I decided it wouldn't do, especially in wide screen modes. I think probably (I'm not positive) KF2 uses some tricks on its arm. As opposed to displaying it as-is like SOM does...

One thing I did was to rotate the arm up some, to create the illusion of having a top-down perspective on it. But ultimately I had to make it rotate down in the middle of the swing since I'm trying to make the arm aim for the center of the screen, and rotating it up can make it go higher.

Another thing I did is to have the arm move forward and back again. The reason for this is to fade it in and out of view, but after I set it up I have a feeling maybe KF2 does this, because it feels like lunging your body forward to attack, which the ARM.MDL file doesn't actually do by itself. It wasn't my goal, but it feels more like an attack and I think that KF2's model doesn't quite feel right, but after adding this it feels much better, even without sound.

Lastly, the Moratheia demo's arm animations had an issue rotated up and with the arm raised up higher and made prominent. The problem is the longer swords weren't animated to get out of view, since previously they were much lower, out of frame. So what I did is set up a system to fade in and out the weapon (like spawning) that only happens in the very beginning and end, so that it's probably not possible to see in the beginning using the new arm_ms_windup extension, and in the end it's only possible to see the weapon fade out if it's very long and sticks out in the end of its animation, or if you're jumping around with the do_arm extension and manage to catch it in a pause or menu screen. It's a very subtle effect, but it's applied to all weapons, even though it's mainly for super big weapons that are hard to get off the screen.

Also, the new arm_bicep extension I might have mentioned before wasn't set up to accept a value. Also although I've fixed the field-of-view for the arm, after the changes I made today it looked fine at 62 so I made it to use 62 if that's the FOV setting. 62 is what KF2 uses, and although I don't like how it makes things look like a fun house mirror, I've actually gotten used to it, and one of the nice things about it is when you look down you feel like there's room for a body beneath you. With lower settings it's like looking through a scope on a gun at the ground, so you feel like you're just down on the ground I guess, which is weird. In the lower settings I made a quick fix to pull the perspective back when looking up and down, but I'd like to do that even for the 50 setting, but I only did it below 50 right now, since I piggybacked the change onto an existing effect that's capped at 50.

I've actually taken to switching between 62 and 30 like a zoom scope system. It's very convenient since that's when you roll over from the highest to the lowest setting. I have like a zoom lens when I want it. One of the bad things about 62 is you can't ever get close to things.

Holey Moley · « **Reply #18 on:** September 01, 2020, 05:34:19 AM »

Important patch

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

This patch fixes a problem where movement cancels out from the same code that crashed in the last blog post. Two of the buttons that were meant to be opposed used the wrong assignments.

But there's a bigger fix in jumping since while looking at this I was reminded about a bad effect when jumping while turning that had been flickery I think, it's hard to describe but it would look like a the line on the corner of a wall bounced back and forth when looking at it and turn jumping.

I'm not sure why it looked like that (maybe an optical illusion) but I thought I traced the problem to using the gait system to simulate jumping. When turning the system that simulates input rotates it as you turn and the gait code system converts the rotated values into 4 bit codes. I thought this resolution was inadequate, so I set up an alternative path.

Except I ran into problems there, that lead to a good discovery that jumping (at least when not running) movement was being stalled while the variable that is used to lock the position while crouching bled out. Then I made some changes to try improve the input smoothing system while jumping/falling and after this it was good enough even with the gait code values.

Either way, this is some major improvements for jumping feel. Jumping is complicated because the control system is on auto pilot. I went ahead and left in the new code I worked on to use the raw values instead of the gait codes, but I will revisit it sometime to see if it's really necessary or if it really feels better. The gait code system sounds primitive but it has a lot of benefits and can feel more organic than raw data. It's a quantization system.

Holey Moley · « **Reply #19 on:** September 03, 2020, 02:08:11 PM »

Addendum patch

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

I've deleted 2 or 3 "EDITED" posts referring to the previous patch. This little bit of code it refers to has bitten me so many times I just have to chuckle at it. I think it's stabilized

I also included some info on some features I happened to be working on in the past days. I will just say I've given them a lot more time than planned in order to refine them, and they are basically a feature where doors stay open until you move away from them, and a new "nosedive" feature that I had to moderate in this most recent patch because it was too much walking down 0.25m stairs...

It works by looking down some when you begin falling. I know KF2 does something like this. I don't know if it rolls sideways or in the direction of the fall. I generally don't implement head rolling because it's not realistic. (We have a vestibular system for that.) It also accentuates falls. I didn't design it to do that but in order to blend it with the "bounce" effect what seemed to work was to postpone it for the duration of the bounce, so that the recovery (looking back up) comes after the bounce, and the further the fall the more steep the "nosedive" so the longer the recovery. There's also a little bit a duck, that kind of feels like standing back up but is mostly not noticeable... maybe it should push the head forward, but I usually add a little dip when forcing a nod because it looks more natural. (Owing to us having necks and all.)

It's definitely pushing me to find a solution for the descending stairs problem, and falling into "cracks", that is between platforms using the system that makes it so you don't hover out over thin air. The solution is probably related or can be packaged together. It has to probe the space underneath the character's feet.

Holey Moley · « **Reply #20 on:** September 10, 2020, 03:49:09 PM »

Layers patch (important)

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

The new SOM_MAP layer system was still "off by one" it seems, from the last time I thought I fixed this. This means it was pulling tile data from the wrong row, but very often rows have the same values.

This patch also maps the sound/music volume levels to a logarithmic scale. The full range of values is audible.

Holey Moley · « **Reply #21 on:** September 14, 2020, 05:23:07 PM »

Final patch? (important)

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

Crap, uh, this patch fixes the "system-wide" event system when regular local events come after system-wide events in the event table.

I'm not sure what happened here, but I tended to put global events at the end of my tables, so I didn't notice, however the mistake in the code is very suspicious, it looks like my old mouse may have triggered the text drag-and-drop system in my code editor. I never use drag-and-drop, but it's not currently disabled, I should try to disable it.

On a technical note, this patch introduces a "breaking change" to do_sounds. I made the sound playing event use 3D sound for non-system events. Originally you had to arbitrarily attach an event to a dummy object or something, but now you can make system (unattached) events to get the old no-3D sound behavior. On the upside you can make an object, etc. play a sound now, via an event.

The old behavior was to play the "always on" and "use item anywhere" sounds non-3D. So like the fountain in KF2 makes a water sound, that sound is "always on" so it makes sense for it to be 3D sound coming from the source.

I considered given the last two patches to go ahead an establish a new release, finally, but I felt I didn't want this release to be left with this system event bug forever. I think I'm going to make a new release shortly, just to mark the time.

Holey Moley · « **Reply #22 on:** September 16, 2020, 05:34:52 PM »

Full disclosure: I've reuploaded the previous patch after learning it broke the sound play event for "system" class events because back when I added system/system-wide events I mistakenly thought the "use item anywhere" event needed to be nominally attached to a subject (object/NPC) to work.

So I faked that by attaching them to the NPC type. So I needed to undo that, and so yesterday morning I mapped out all of the event handling code (honestly Ghidra is making mapping/reprogramming som_db.exe relatively straightforward these days; the tools are tougher cookies because they do a lot of indirect function calls) only to learn that it would've worked fine without that hack all along! I can almost remember that time, I think I would have tested it before making that change but there was probably another reason such a test failed. Anyway I tested it this time.

I also learned the play sound event/instruction is unique in referring back to the event's subject. I was surprised to see it has code for 3D sound effects, for that reason. The NPC conversation animations are another case but they're a bit more ambiguous in terms of if they're part of the event instruction.

The reupload also has some new code that I developed to camouflage secrets like King's Field hidden passages and compartments. I had to refine something I already written about elsewhere last night while working on the little compartments hidden in the walls (I'll probably write about this in my dev-log later) and I discovered that the map geometry that has baked in 8-bit lighting is for some reason darker than the regular geometry. I was able to (functionally) perfectly match it for my KF2 project down to replicating the dither patterns (which is actually a very precise way to do color matching) on all of KF2's walls with its fairly complex lighting. It's still possible it varies with the ambient light level, but the code in this upload is dimming the regular geometry 96.5% and quantizing the values to 8-bit intervals in the shader path.

The dimming is a mystery. I'm interested in finding the exact lighting code inside the MPX compiler but haven't come across it so far. It does make the games significantly darker (9 shades darker on a 0~255 scale) and I consider this a temporary fix. I tried brightening the map geometry without success, but I will try again. I did find that quantizing is important, so requantizing is generally not ideal. I can also add something to boost the brightness to make up the difference.

Update: I determined the lighting difference depends on the ambient light level setting, so I've disabled the light level balancing for future patches until I can refine it. In the meantime I've left it on with do_kf2 but that's an abuse on my part, in order to use it with my KF2 project until I get to it on my note pad's to-do list.

Holey Moley · « **Reply #23 on:** September 19, 2020, 09:23:18 AM »

Patch

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

I think I've been doing dither wrong all this time! But this patch is to fix lingering problems with the F12 (or Alt+F12) muting function, since I changed it to have 255 values instead of 16 (like the other volume levels.)

About dithering, this patch changes the "high color" mode with dither to match the same brightness as the "true color" mode, which is helpful for artists who want to match colors. I thought since it was darker I would just try to brighten it, but in the process I figured out for one reason or another the darkness was a mistake. I had centered the dither pattern on the color, but instead I think it's supposed to be added to the color, which is counterintuitive, and maybe differs from the source I was working from (I don't know.)

So now it matches exactly the other mode. When I added the missing brightness I realized the math was simpler to just add the dither pattern, but I was concerned this would be a problem for black/dark colors, but I think not, it's just that when the colors are quantized (reduced to 16-bit color) the brightness added by the pattern collapses neatly into the gradations, so that 0 remains 0 and 1 lights up 1 dot in the dither pattern, so it seems ideal. I wish I'd given it more critical thought. The screenshots I've been sharing lately are four shades darker than they should be, which really doesn't seem like much, but it definitely is noticeable.

P.S. When I went to write this earlier I couldn't access this website. It turned out it was being bombarded by requests to an xmlrpc.php file that's part of WordPress installations, effectively producing a denial-of-service scenario, but it was probably just a mindless "hacker" bot that hits any sites with this file. So I disabled that and the site came back to life. Hopefully no harm was done. I let my host know what occurred. They might have a way to see if anything happened.

Holey Moley · « **Reply #24 on:** September 24, 2020, 04:51:38 AM »

CRITICAL PATCH

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

Sometime back I broke the most important [Option] section so that I discovered the do_red extension wasn't working, and it's a wonder more weren't. (I need to change the Ex.ini system to not require that I keep it alphabetized, since I can't even do that right.)

Also the do_hit extension has been misinterpreting monsters as traps ever since I extended the monster limit many months ago.

P.S. I should do a more in depth write up of this subject, but lately I've been working on traps, and enabling the spear traps to work for the first time, and changing some of the behavior. I discovered some weird stuff. Like for one you can (and it's not hard at all) actually climb onto traps, that are built out of CPs instead of regular shapes. That's not a feature in my book, it's a bug. Also weirdly the clip system uses different radii for the CPs for clipping and the hit test that can deal damage. The hit test was actually using half the height value in the PRF file. I wonder if this was a bug...

The clip test uses a radius value that is computed for boxes. I assume it's the distance to the corner of the box, but if so that would be a simple length, but the calculation that does it uses multiple trigonometry functions that I don't recognize what they're doing without analyzing it. I think this value used to be part of the PRF file, since it's in memory where there is an unused value in the PRF file that matches it. I think it was an activation radius. I may restore that value to use for traps since they're pretty ambiguous right now. (EDITED: I think I saw this activation radius value in the bogus screenshots on From Software's website that show the internal version of SOM instead of the commercial vesion.)

To activate the spear trap it needs to be like a normal box shape, so I stopped using the height for the hit test, bug or not, and went with the radius. But that came into conflict with the clip test, I actually believe the clip test pushes you out of the way so that the hit test can't detect a hit using the same radius. (EDITED: Maybe not, but I can't think of a good explanation. Two positions are maintained for the game's location, I think that one should be the previous location at the later stage of the loop cycle, but I don't know if they're used consistently if so.)

I couldn't figure out something that works, so for a quick fix I've made it so the do_hit (or do_hit2) extension is required to get better trap behavior by eliminating the clip test (this also solves the climbing problem) so that the do_hit response from the damage is all that there is to animate the trap knocking you out its way. I was also able to switch do_hit over to using the CP position instead of the object position for better accuracy. And I made it so only the first hit determines the knock back trajectory so that the trap can't cancel itself out.

Also the spare sound effect can be used to make the spear sound, so that the open/close sounds don't have to be combined with the trap mechanism.

Holey Moley · « **Reply #25 on:** October 21, 2020, 07:12:44 AM »

Patch

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

Great, I just found out SOM_MAIN wouldn't start since I changed something to load the Sys.dat file and it's the only tool that doesn't load a project, so it doesn't have a Sys.dat file.

Of course it crashes. Great look to have the first program that leads into SOM not start.

It's annoying to not realize something this for a while. And a reminder no one tries SOM or if they do they don't report when it doesn't work out. But I also really didn't want to patch this release again. It's going to be another deal where the last patch of the previous release is the same as the new release.

Incidentally there's a lot of cool stuff in this patch, but I can't divulge it now. I will say there's a new do_srgb extension that I've changed to always get turned on when the do_lap extension is turned on (but it can be turned off) because I think it really helps with ghost images that come from the do_lap extension. It superimposes two frames, so you always want it, but with the sRGB blending you get the proper colors for the blending and this makes it less funky and so it seems less blurry. Just some odd news. Of course the do_aa extension turns on do_lap. (I'm not crazy about the "do_lap" extension's name, but it's not one you normally turn on yourself.)

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Unleashing monsters

Author Topic: EXIT: Unleashing monsters (Read 31019 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Unleashing monsters

Author Topic: EXIT: Unleashing monsters (Read 31019 times)

Sword of Moonlight|

Devs|

EXIT: Unleashing monsters