Sword of Moonlight > Devs

Exit: Passing between worlds

<< < (2/4) > >>

Holey Moley:
Minor usability patch (SOM_MAP)

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

Sometime back in 2017 I noticed when SOM_MAP's palette area moves on its own (after clicking a tile) that it wipes out the information displayed in text boxes under the work area.

But what I somehow didn't notice until yesterday is this also wipes out the stored information used to place copies of the selected tile (instead it reverts to as if you clicked the palette area... forgetting things like elevation and rotation) which is obviously important for work.

So I'm going ahead and putting this out there in case it helps anyone in the meantime. An example of when this would become a problem is if you were using the tile sets packaged with SOM and mix-and-matching tiles from different sections of its KF sample project. It could also happen if the palette just happens to be on the border of the tiles you're working with. I guess it goes to show how little time I spend building game maps with SOM that I didn't notice this for more than a decade of working with it!

Holey Moley:
Patch #2 (today)

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

I think I may have found the reason for random crashing at start in this release in this patch. I also tested the new background loading system today on my KF2 project and found I neglected to test it on an elevation change scenario. It turned out a "shock absorber" effect caused a big glitch. (The crashing I think was caused by the [Number] based extensions in the Ex.ini file, since it is used on the background loading "thread" when it wasn't designed for sharing between threads. There may be other sources of this kind of problem, I now know what to keep an open mind about. Of course SOM isn't a multi-thread system, even though many of its tools are loaded down with "critical sections" because it's written with MFC code that seems to have produced ridiculously bloated applications. When designing the system I had to be careful about what kind of bad interactions could happen. Luckily loading code is pretty isolated.)

Edited: Oh yeah... as for background loading KF2. There's still a hiccup. I don't know if I'll be able to work it out of the demo I'm working on or not. It could very likely have nothing to do with disk access... maybe just memory cache hits. On beefier CPUs it might not hiccup. Hopefully I can profile it some more at some point, or think of some strategies to avoid extra work.

Holey Moley:
x2mdl (dll) patch

http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip (maybe unnecessary, can't remember)

I'm still patching this leaky raft... namely I didn't test the texture downsizing path (to fit MDL's 256x256 limit) and some other nontrivial stuff I won't go into details about. One serious problem led SOM_MAP to convert non level geometry models into level geometry. (A new time optimization is it no longer generates MDL textures when there aren't animations, since it won't be outputting a MDL file. Eventually I want to omit textures from MDL files altogether since they're not shown in the game. But for now--transitioning time--the files still have textures so they can be opened up and looked at.)

Holey Moley:
Optional x2mdl (dll) patch (#2)

http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip (maybe slightly improved)

I got lucky with an accident that helped me to identify a pretty wild bug in x2mdl when converting the MM3D files (that format specifically) into SOM's files. It will likely crash if the MM3D file doesn't assign all of the model parts to groups (i.e. materials/smoothing groups) (which is how I found it, by accidentally not doing so with a portion of model) but the real kicker is a "loop" I wrote was using the wrong "variable" to track its progress, which could potentially be slow things down.

(I've never made a bug like this before, but basically in one standard kind of loop you have a number that is incremented until it gets to another higher number. What I did is mistype the "variables" holding the numbers so that the higher number is incremented and the other retains the value of the first item that is looped over. In that case the CPU just keeps hitting that item until the higher number "wraps around" in memory so that it becomes lower, and that can take billions of instructions (probably around 1B in this case) which is in theory a gigahertz if an instruction is one cycle. In practice though there's probably several instructions involved, although this loop was very simple.)

I'm just glad I found it. I'm sure it would turn up eventually, but I actually neglected last night to investigate it since I forgot to make a note, but luckily I remembered and went back and reproduced the crash (in SOM_MAP) to figure out what happened.

Holey Moley:
Routine patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip
http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip (minor)

The x2mdl.dll patch just adds some hints to error popups and an option to subdivide MSM input. The latter is is needed to make object models that blend into the level geometry, a/k/a secret doors.

The past few days I've been trying to crack down on a bunch of recent bugs I've been neglecting debugging. That's what this patch is. I'm not going to lie, here lately it's been crashing for me a lot, usually at the start, in ways that seem random. I'm hoping all the problems are covered by this patch. I haven't had any this morning. A lot of them were really weird, and I've only recently hit upon a few reproducible cases for a few of them.

I'm pretty sure there are still unsolved problems. It's always demoralizing when a problem keeps raising its head. Most of these crashes are around new features. There was a constellation of bugs that all kind of seemed related but were not. I've fixed a least 3 like this, so at least they're being teased apart. Divide and conquer. At least this patch addresses several of them, which is better than nothing. It also fixes a number of places where recent patches broke new features. I have to be bug free before I can release a demo later in April. I'm going to have to work like a demon if that demo is going to not have a bunch of loose ends, but I intend to publish it in April, however far I get.

Navigation

[0] Message Index

[#] Next page

[*] Previous page