simple machines forum

There's just not a lot of people testing it. Please try to figure out what's going wrong for you so it can be fixed.

There's two versions of SOM. There's the one From Software published in 2000 and this one that's updated. The former was developed for Windows 95. (And has hundreds of bugs and generally isn't worth using for anything today.)

If you have no clue what's happening you can turn on do_log and db_log_bardb_log_debug_bar=7 in the Ex.ini file and look at the log to get an idea of how far it gets. If your computer isn't like 15 years old whatever is wrong is probably minor like this problem you had.

EDITED: Can you see the model previews in the SOM_PRM tool? You seem to have everything working, so if not that can suggest you have an issue with Direct3D 9. (You said you can see models in SOM_MAP. Or did I mishear?)

Patch

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

This corrects a recent mistake I made for item based event activation (I don't know how I got this wrong, I thought I had Ghidra when I did it but maybe I was just beginning to unravel the subroutines and was a little too cocky.)

Another interesting thing in this patch that obvious now is when the hit PC hit effect (do_hit) occurs the gauges are drained out just like when climbing. I probably need to base the gauge drain on the hit strength. I tried a complicated set up based on HP loss but it wasn't as nice as just enabling draining in the hit effect...

I thought the impact was determining the loss, but now I'm not sure. I have to spend more time with it I guess. I'm not sure why it took me this long to realize getting hit should drain the gauges. I guess at the time there wasn't anything draining the gauges, but now many things do.

Edited: I've reuploaded this patch a couple times, once to try to treat poison damage differently, and again after finding out I shot myself in the foot with a last minute change. The amount of drain is consistent with the effect's impact. I still can't quite make out what's happening. I can't find any code that suggests the impact holds down the ducking animation, but it seems like that must be part of it. It's weird talking about my own source code like it's unexplored binary code. Because the hit effect looks like dashing it makes sense that it should drain out the gauges. It should work well with a shield system (that's always just around the corner )

Patch

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

This patch fixes a problem with the recent work to extend monsters beyond 128 per map, that arises when opening a new map from such a map. (I've even seen this before I thought I just had some monsters on my other maps from early attempts to convert the data on the PlayStation disc to SOM data.)

It also has a "really simple" shock absorber system that's very subtle but seems to help. It seems to fix or mask the jarring takeoff that happens sometime when jumping. I wanted to do something fancier for a while but the thought just occurred to me today that something simpler would be very quick to whip up.

In the past 2 days I've been obsessing over the spear trap and one of the trap doors that have bad cracks sometimes that give them away. It's been making me very unhappy. I also noticed the itch.io demo doesn't apply the scaling extensions to the second arm with the Bastard Sword item. I missed a debug check for holding off on experimental tests.

It looks like I haven't mentioned that the baby monsters are set up now, and I've boosted the color a little. I feel like I've written about that somewhere but I don't see it here. I think it helps with filtering but a little bit of color goes a long way. KFII is particularly drab/gray among the trilogy even on the PlayStation.

I've been noticing turning is a little jerky lately sometimes. (Edited: I've uploaded a patch for this.)

Back to those cracks, I really don't want to have to make a special animation for secrets. KFII actually swaps out the animated models with map pieces. SOM can't do that. There's a fundamental problem because the depth buffer lets pixels overwrite each other, so in theory the last polygon wins the so-called depth fight.

At first I thought this was the problem, but now I'm leaning toward it's more to do with precision of the MDL files not having the same exact coordinates. I rewrote two pretty intense subroutines to see if sloppy code was responsible for the imprecision without success. I'm feeling defeated. I tried reversing the part order for hard body animations. That probably helps because the MDL files put the "children" body parts earlier in the list and that seems to be the order they're displayed, but it's a problem for secrets and traps because that would display the motionless part last making it to win the depth fight, which is probably not good.

It's pretty complicated. I don't see a way to change the overwrite issue because typically the map geometry is displayed first and then any secrets or traps clearly have to overwrite it to conceal themselves. (Basically the motionless parts are equivalent to map geometry in this regard.)

Then from there which polygon goes last depends on (I assume) which part it belongs to, and which texture it uses, and then what order the polygons are in. You want the concealer parts to be last in the list, unless it goes in reverse order and I don't know it. (Either texture or polygons.)

So when I started I added some tools to my modeling software to be able to control polygon order before I realized the problem was more complicated. But it can be helpful for transparency to reverse polygons (if you don't have depth sorting/splitting.) I had to do that with Blender to make many of the transparent items to look right when spinning. And there's still sometimes an optical illusion where you convince your eyes they're going backward. (I have to work on full sorting/splitting.)

But I'm almost out of ideas for the cracks. I think either the object positions calculated by SOM_MAP and MapComp are a little off, or the 1/1024 MDL scale factor is somehow a source of problems. In theory the data needs to be perfectly matched. Even then floating-point hardware can be finicky.

The geometric problem arises from things like KFII's secret compartments because they form a perfect polygon mating. I honestly can't tell if depth buffer technology somehow can deal with that, if so my chip sometimes fails to. But surprising it generally looks good. I think it may be based on rules about shifting pixels over depending on if edges are going up or down or left or right.

It looks markedly worse with the do_aa extension, that's my baby. I feel nauseous that it's not working for me. But it sometimes glitches without it too. And I can't find any geometric explanations. Sometimes even vanilla walls (built from objects) glitch.

I think I should do a test with a MDO model to see if it has issues. It may be time to work on using MDO in place of MDL for display purposes. If so that would mean the culprit is likely either its fixed precision (not all coordinates fall on a millimeter but I think the cuts x2msm makes do) or scale matrix.

Important bug fix

(http://www.swordofmoonlight.net/holy/x2mdl.zip)

Details: I've fixed an x2mm3d conversion bug for sparse keyframes (i.e. the animation freezes for at least one frame.) I'm glad I found this sooner than later.

This (http://www.swordofmoonlight.net/holy/x2mdl.zip) is kind of a rush, but I went ahead and uploaded it because I shared a bad/broken one the other day (different topic/thread.) I wanted to put out a working replacement.

I'm going to put this in the TOOL folder I guess, shortly, I want to give it more thought and add some command-line options and probably I need to finish the mixed animation feature I'm working on right now before putting in the versioned file tree.

The mm3d facility is only compatible with the newest patch uploaded to https://github.com/mick-p1982/mm3d/releases/tag/win32-demo2c just earlier today. To make MM3D files (instead of making MDL files) the way is to rename it to x2mm3d. It can only output MDL or MM3D. It can take many inputs but I only recommend MM3D or maybe X but it might be acceptable with others. (Edited: Of course it supports SOM formats.)

There are very many ways to make control points now, but I haven't tested them all. MM3D files should use real points instead of triangles and name them to (C0) or (R0) to (R31) and yes, you must include parentheses. It also detects vertex colors or color only materials or any mesh or node with those names and maybe even other points, but they need color if not named.

I may update this link. I'm not using an attachment since I don't like reattaching because it breaks the links.

EDITED: To be clear, this initial version only understands SOM's two types of animations and so can't mix them or make weighted animations. This is the first version than can do soft animations. Shortly there should be a simple system that can convert an unweighted, mixed animation into a soft animation. Then I will see if it's feasible to convert weighted to soft.

  Sorry, I've misbehaved, I'm running late on this goal. I did upload a pretty big patch to the MM3D demo from the previous Reply/post today. I swear I'm on x2mdl first thing tomorrow.

Truth is I got lost in a programmer's rabbit hole for two days. It's a hard phenomenon to describe, but it happens from time to time. You really get invested in something and it can kind of takeover your world until you realize how neglectful you've been in being so single-minded. Sometimes it can seem like your goal is just beyond your grasp, and next thing you know, it's just beyond your grasp, and next thing you know (next,next,next) it's two days later and you realize this has to end, but you keep going still, but eventually you do get that train to come to a halt. Luckily this time I got some good work in there, but I should've cut myself off sooner and did what I said I would do.

Well, right now it's midnight so I'm going to watch some videos online while it doesn't count against my data plan. Otherwise I might get started now.