simple machines forum

Woops!

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

The last patch wasn't good enough for running over slopes. And I'm currently back to the drawing board on climbing onto slopes as a result.

I had to trek all the way back to that section of the Moratheia 2.1 demo to see if climbing them would work or not. I'll figure something out.

I can't Escape from Sword of Moonlight

Below is a demo post I made yesterday about a new King's Field 3 style extension.

PATCH

This patch (http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.8.zip) is a quick fix for a bug that triggers jumping when you might not want to jump. I've long been unable to put my finger on it. I've been playing the Moratheia 2.1 demo lately, and every time it happens I think about it a little.

I thought maybe some code that had converted the new "half-gaits" into 0 might have changed to returning nonzero codes. Actually there is jump code to handle the half-gaits. But I looked at it, and I'm pretty sure either there's a typo in there, or I was being a ditz when I wrote it; leaving some huge gaps in its logic...

Right now, I can't think of a reason to include a half-gait in jump-detection, since they don't appear except to support a full-gait. In which case the full gait should override them. Though it's a little more complicated then this.

Strikeout: I reinstated this. The half-gaits are tracked because the controller has to go on cruise-control to complete the jump. The code looks fine. I would delete this post, but it's bound up with the quote below.


In any event; I want this fix to go out immediately. And I don't want to add anything to disable the new no-stun extension described below. So it's going into this release, warts and all (mainly it disables multi-hitting weapons--which may or may not be a thing--and is effectively compulsory for now.)

Here (http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.9.zip) is a demo of a new King's Field 3 like stun-less attack system.

I was unwinding yesterday after a trip. I've been trying to play with the Moratheia 2.1 demo since it's quite functional now. The monsters aren't balanced for the new damage formula or speeds. They are very aggressive. I thought that if the combat set up was more flexible they could be less so...

And so I realized that after the work on the sky and shadows a while ago, there wasn't anything standing in the way of doing an extension like this.

The caveat is I don't really know how to reason about multi-hit weapons, assuming they are a proper feature. That will require testing specific weapons---and I don't know which if any are multi-hit.


The system is enabled if do_red and do_hit are enabled. do_hit2 enables do_hit.


I think KF3 may not flash red if a stun animation is played. Right now the flash is always done. Personally I prefer if it always flashes. The PC always flashes, so the monsters should too. And it creates an expectation of a flash, and it is like abstract bloodshed. The only down side I can understand is if you want to see the stun animations in full color, you can't.


I've added a factor of randomness to the fighting. I think this is interesting and not really like a "miss!" when a blow clearly lands. Instead, if the blow is halfway between an always stunning hit and a no-stunning hit, it has a random chance of stunning, that is proportional to the difference.


The PC can still attack while stunned so their situation is not changed.

EDITED: I've updated the ZIP to add a fix for NPCs and the F7 overlay ... and also  the PC now gets to avoid the stun penalty same as the monsters, but is still knocked off their center. So there is no buckle or loss of the ability to dash...

I think the default setting is alright for monsters. You might think that the PC should do the stun penalty more easily. But I think if so, then the monsters should too. That can be done with the red_multiplier extension. It changes what is considered the cap in terms of HP loss. The default is 50% so it follows that the PC will not stun unless they are hit by at least 25% and up to 50% the stun is not guaranteed. So this means to experience this a monster must hit the PC very hard. And the PC will probably be dead soon regardless if a monster is so damaging. But I think it's not a bad default. Especially if people think the stun is annoying.

Decreasing the cap to 25% means more stuns all around, and redder screen effects and that only 12.5% damage or less will not stun. I just think 50% is a rounder number and a better starting point, and I like that a monster shouldn't last more than a couple good hits if they are doing the stun animation, because fights can really drag on longer than they should otherwise.


EDITED: Fixed some problems with F7's display. Mainly it wouldn't show information for 1-hit kills. I've had to make a lot of changes to it to avoid showing old data in memory and I didn't consider this. It now waits one second longer after NPCs die before returning to the prompt. (This part has changed a lot in this demo, since before it scanned memory, but now it gets information directly from the damage subroutine.)

Not-a-patch

I got up yesterday with an idea to solve a *new* problem with some of the double-doors where extension must do the activation test, and I don't understand doors well enough to do it perfectly (it doesn't work with the wider clip radius) so at close range on one side the object's center is actually behind the PC.

My idea was to use the clipper subroutine, just as if walking into the door, to get more information about it, and make sure the test is on the right side.

That worked well enough to remove the problem. And make the activation radius smaller...


But it reminded me about the small swinging doors, which have an awkward cylinder clip radius, and it's actually possible to approach them from the side and get between the rectangle and cylinder.


So I thought I was done, but later in the day I got cocky. I realized that this was a perfect opportunity to experiment with doors.


So, I tried to remove the cylinder first. And that was not so hard, but it made those doors permeable from one side... So I stubbornly redoubled my effort; hoping for low hanging fruit.

EDITED: The permeability was an extension bug. I guess the cylinder is just to give the swinging door a wide berth so not to knock the PC backward. I think the clip shape should match the geometry and that moving out of the door's way enhances the experiences. Perhaps it helps to have a 1/2 meter radius and lots of smoothing.


But I didn't come away successful, and used my entire work day on doors. But I did learn some things...


1) Doors seem to use a generic box test. I don't think the box is at the center of the object though.

2) It doesn't make sense that the door would be semi-permeable. It suggests something really funky (SOM's doors seem like a wad of hacks to me) or that the generic box test itself is flawed. The most likely reason is the test can't work with modestly thin boxes. Like no thinner than these doors if so. I'm going to try making the doors a little thicker in the program this morning.

Strikeout: turns out this was an extension that removed a funky vortex on the corner of objects and adds a slight tolerance like MHM geometry to not stick to objects. I thought I ruled this out, but it was cringe worthy obvious when I realized this was it and it should have been because it assumed the center of the box test was at the center of the object.

3) I lost most of my time trying to improve the box test. The object clipping process is apparently completely stupid. All evidence says that every object is tested, no matter if its 100 meters away. And the tests themselves are awful:

3-2) They don't begin with a basic, Is the box close? test. They do a 2D inside-outside test first. But this test is not doing anything. I modified this test to to reject things on the opposite side, since I thought this would improve the too-thin problem. But the result of this test is not to reject the object, but only to choose a different algorithm for doing subsequent tests.

3-3) None of these tests are lightweight on math. Again, every object is tested, even if nowhere nearby.

4) If every object is tested indiscriminately. I can't see any reason to believe that the same is not done for every mobile NPC. In which case you have a ridiculous amount of clip tests going, like 500+ for every NPC/PC, and the tests are all heavy duty. The cylinder tests are simpler. Luckily NPCs are cylinders, so the fact that they probably test all against all means that they have exponential complexity is less of an issue.


I don't have any spare time to look at this stuff. I was showed lack of discipline to get reeled into it yesterday. But I feel like before very long I want to dig into this all-against-all aspect. And I'm thinking about converting the basic shapes to MHM data as a starting point. Which could facilitate rotating the objects in SOM_MAP.


PS: I wrote about this slight door activation improvement in Random News yesterday, but I wanted to say a little more. Really I did it because of the change I did to prevent warp-like movement resulting from objects now mainly. I did that for a double-door I knew of. And so I thought, this door also has this other problem. So I wanted to better the other half of this door's lot.

I really do not like the cylinder shape in the small doors. I also noticed yesterday that the secret doors are actually much thicker than the wall. So you can get stuck on them sliding along the wall. I think with Ex you do not get stuck, but do hit a speed-table like shape at the door. I don't know if this is a problem in their DATA files or in the program. But I'm aware of it.

  I think there must be something very wrong with the walking motion effects in this build. I can't understand what it is. And I don't know how I didn't notice it before. Or how long it's been like this.

I think I've improved the back and forth motion. But whatever is glitching out makes the improvement practically undetectable.

There's something very off. It's just very subtle. But that's all it takes. I'm going to have to tear the whole thing apart at this rate


EDITED: I should probably start (tomorrow) by see what some older releases look like....

Special parting PATCH

This patch enables mouse-wheels! Finally.

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


Some years ago I disabled mouse-wheeling. I think it still worked in drop-down menus. But it was very inconsistent quality wise, and the listboxes (e.g. events and SOM_PRM's main lists) were embarrassingly awful. It's really dumb because the listviews (some of the multi column lists) always worked wonderfully. SOM_MAP's treeview was very bad too. And the custom view ports didn't work at all I think. So for consistency sake I just put it off.


I thought that I would get around to changing the listboxes to use listviews. I don't like how the listbox is highlighted. Since it looks like it's selected.

This afternoon I just wondered, what a really stupid mouse-wheel implementation would look like, and it looked alright. So here it is.

Patch

OKAY! WTF Gives?! Now I feel like the universe is just toying with me....

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

I don't know why but something in the Visual Studio text editor I always DISABLE was enabled yesterday, it does drag-and-drop copy paste, and managed to turn a number from

test        dword ptr [ecx+edx+8],80000000h

into

test        dword ptr [ecx+edx+8],08000000h

And I'm just damn glad I noticed it before it became something completely impossible to trace back to the source.

So in the last patch, this makes items appear to be invisible.

I'd been trying to make sense of a bug that crashes the Moratheia demo when going into some maps. It has something to do with items.

Off-topic: Yesterday I stumbled across something that appears as if it can only be one thing. I don't want to say what it is just yet. But I'll just tease that it's big and cool and it's basically something everyone's wanted SOM to be able to do that the King's Field games all have, and it's actually inside SOM and working, but SOM_MAP just doesn't have the settings to tell the player what to do with this capability.

I will try to list the clipper/movement enhancements that are the centerpiece of this release.

* Slopes may have walls on the outside. That is to say, you can build a ramp. Or walk on the edge of a pitched roof or up a mountainside path. These are just examples. Really this enhancement should cover arbitrary geometry equally well.

* Further work has been done so that slopes do not have weird bumps in them. I fixed the problem where slopes meet flat polygons the last time I worked on the clipper. But I think I shot myself in the foot and didn't know it until the same problem came back except only along the edge of walls--which is why it went unnoticed. Later I came to understand another problem of going down slopes from the top of a flat polygon. In that case the polygon had to be cleared first causing you to basically fall down onto the slope. This class of problems is eliminated by this release.

* There's now a dampening filter in the X/Z dimensions meaning that when you turn a corner of a structure the transition from one polygon to the one beside it aimed in the opposite direction is no more an abrupt one. This is actually my favorite highlight of this release. It's something I've long wanted to take a crack at. I'm surprised it works so well. Yesterday I was sneaking around like a spy peeping around corners and the entire experience was perfectly tranquil. You can really lose yourself pretending that monsters don't see you. Corners are still hard, meaning you can't really press on them at 45 degrees. The smoothing can only be short lived. It gets weaker as it is applied, since if it went on the clipper would fail in its function to be a barrier.

* Angled polygons now get a lateral cut out test that hadn't existed before. Whereas flat walls would get this test, angled walls only received a top-down test. I don't know if this yet applies to magic missiles, but just as an example, this means that a fireball should have better clearance passing near angled polygons. Of course NPCs enjoy this too. But it's easier to picture as a ball passing through. This upgrade is required to walk over the tops of angled walls, which are necessarily connected to slopes. It's not just that simple because the shape doing the walking is a cylinder that has a width. The technique I've employed to make this work is good enough for shallow slopes. But I'd like to eventually extend the angle that slopes can be moved over, and the present technique (it basically lifts the cylinder up as far as necessary) will have to be discarded to do this (instead of lifting the cylinder up something like every slope polygon will have to form a hull such that any wall on the wrong side of any slope will have to be ignored. That's a lot more complicated but not impractical.)

* The clipper is somewhat simplified, because I was able to make a list of the hit polygons and exclude them from further testing; whereas originally the only way to not test a polygon was to get out of its way. That could cause problems, especially with walls that face each other, because anything would get stuck between them bouncing back and forth, and it was just unnecessary tests, since the original code always did up to 8 rounds of testing. For example, the wall with a square window in it, would capture you between the two walls of the window, and so the rest of the model would let anything pass through it, never being tested. The original model actually had a five sided hole with a triangular top, whether originally that MSM model looked like that, or the MHM model was changed to workaround this defect. This need to move past polygons before clipping could proceed just made certain configurations infeasible.

* I discovered a bug in an extension that lets one leg stand astride a ledge. It was possible to walk away from this and never have the clipping shape return to its full size (dashing or other things would return) and so you could actually walk into a wall at the wrong size, and so get closer to the wall. This is hardly worth mentioning, but because of it I was able to make this feature look much better eventually, but before that because of a fluke accident, I discovered a change that made it much easier to recover from falling off platforms, and I liked the result, so now you can move much more freely over ledges and things without worrying too much about falling off because it's pretty easy to correct if you take a tumble, but you can't be completely asleep at the wheel. Time will tell to what degree this is a permanent feature, because in truth I would rather that it were not possible to fall at all under most circumstances, as if there were guard rails. But this capability will always be around in some form, even if future developments make it much less prominent. (There will be an option to turn off guard-rails completely, but I think you should feel free to look around without fear of walking backward off something, and technically if you can't look over a precipice it's a blind leap--which is not fair.)

* That feature became an unexpected balancing act between climbing stairs and straddling SOM's cyclopean half-meter ledges and also retaining the unexpected fall recovery ability. So I spent a lot more times with stairs, and I think I improved them somewhat. I also lessened the bounce on stairs, or that is if you are walking down short climbs the bounce is much less. I recall that it was not possible to reduce the bounce before. I think it may be unpleasant without some of the smoothing extensions on, including the one that blends two frames, but by now I think these are pretty much essential. In the end I wanted to time the footfalls with stairs when climbing, since when going down the stairs you basically just fall, and the falling sound effect makes it sound like you are walking down stairs... but really you're not... still I didn't want to go to great lengths to do this, so instead what I did is speed up walking when going up short climbs and slopes, not to go faster, but to move the walking effect faster as if more steps are required. I don't think it matches the number of steps on the stairs, but it's something. If only for time being.

* Now in order to hit a polygon something must be on the side of it facing outward. This makes it possible to make much thinner walls, even paper walls. Like in traditional Japanese houses. But it also makes walls that form acute angles behave correctly. For example the exterior set has a diagonal wall that forms acute angles. You can observe (with older versions) that it has real problems, and there's even an unused MHM model of it that you can tell someone at From Software did some experiments to try to work around this problem, but eventually gave up the effort. I don't know if there was some reason the developers thought that polygons should cover the space behind them also. If a model is well formed it should be impossible to get behind them. There is evidence in the programming that this was intentional. But I think if the clipper is rock-solid it shouldn't be necessary to consider things on the wrong side. And its more flexible to users this way, and in the case of the diagonal wall, essential to correct behavior.

* More than anything else I labored over what's probably the most difficult single problem clipper-wise. That is windows like those in the first set of the KF cemetery. Basically a hole in a wall that can be entered. They are difficult because the clipper doesn't consider polygons in any kind of macro sense. It has no idea what the relationship of polygons are. And the window problem runs counter to how things are organized. That is first there is vertical movements, and then lateral movements. That is to say that there isn't true freedom in three dimensions, the system is divide and conquer, resulting in essentially a 1D and then a 2D problem space. You can approach the window either as a 1D or a 2D problem, but either direction throws a wrench into the clipper, because it's truly neither. So I tried many different ways to conceptualize it, and it just kept proving intractable. Note that the real problem is not climbing into the window. That's a simple problem. The real problem is falling into the window, or jumping into it, which basically amounts to falling. What has to be avoided is ending up in a state where you are in the window but also outside the window, because that's a balancing act that really isn't physically possible, and so stretches the credulity of the enterprise. That's the real problem. You have to figure out how to prevent this state. I've still not perfected it since there isn't a cut and dry solution. But I've reduced the probability of this happening by quite a lot. Sometimes it seems like it just happens (although you basically have to be trying to make it happen at this point) but other times you can try maybe a hundred times and not succeed (now after lots of time and effort and refinements) and so I'm more or less content. And I spent so much time on the problem, and being frustrated with it, that I was eventually able to refine the solutions in large part until I'm quite confident in their efficacy and footprint. Not having a straightforward solution, the solution was basically to find an angle of attack that just felt right, and then to come at it from as many ways as possible. There are probably at least 10 places throughout the code with notes on how this modification here or there plays into the overall scheme of getting stuck in windows. It's really quite funny. It's an entire project in itself. I wouldn't describe it as hacks. It's more like the ultimate edge case in a near complete system. But anyway, if not the highlight, this is the crowning achievement of this release. I feel like if the window problem can be beat, then anything else is a paper tiger. And yes, you can crawl in and out of SOM's windows, even though I think there's only one instance of windows among its stock tiles. BTW: A secondary aspect of the window problem, is how to keep out of windows that are too small to fit in, like the square pigeonhole tile. It may be counter-intuitive, but the same programming that makes it possible to enter a window makes it just as difficult to not enter a window. (Recall that the system only deals with individual polygons, although it can make generalizations, like what is the ceiling and floor height and so on; but you don't really have that luxury in the lateral domain. The ultimate solution to the window problem was to temporarily increase the size of the clip shape so any available walls will knock it away from the inside of the window. This requires the window to have a ceiling, which is really only interesting because normally ceilings only keep things from going up, but here it must do as the walls do to keep things from going in... but it cheats by getting the walls to do its bidding. It sounds straightforward if put this way, but temporarily fattening the shape is very delicate and is not guaranteed to just magically have the desired outcome. It requires a lot of specialized handling that is basically contingent on if the shape is fatter than it's expected to be.)

* Oh! Almost forgot. I worked on jumping off the top of a slope. That is one that ends like a ramp. This is a special case, where you keep going up the slope, but when the cylinder shape reaches the top it is completely outside the slope as far as it is concerned. I fixed this by adding some "air time" proportional to the speed more or less, as if walking off a platform at constant speed. But I realized afterward (and it is a somewhat perplexing problem) that I'm really not happy with it. It would be more correct to make the top of the slope act like an infinitely thin platform. Though that's a little unsatisfying too because teetering on the sharp edge of a slope is a little less believable than on a flat platform. But this applies even to very shallow angled slopes. Ultimately my goal was just to have a good experience jumping off the platform. The code that came out of this could be slightly tweaked to add an extension for giving a little extra time to make a jump. In fact at first I applied it a little to flat platforms. Because first person platforming is notoriously fraught. But I decided that the recommended diameter is 1 meter, and that's plenty of breathing room for jumping. (I also restricted it to having a velocity that is going up, both since going down it might be unwelcome and because I'm pretty sure the problem doesn't apply going down, since the slopes extend downward invisibly---as they cut into the cylinder clip shape.)


EDITED: Rereading this I feel like this is some of my best technical writing I can remember. I'm probably not the best judge, but I feel like I've really described these difficult subjects well here. I might be a half-decent communicator. I don't know. Probably just a fluke.