Sword of Moonlight > Devs
EXIT: Unleashing monsters
Holey Moley:
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:
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:
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:
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:
CRITICAL PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
:doh: 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version