Topic: EXIT: Unfinished Business (Read 13463 times)

Holey Moley · « **on:** April 11, 2014, 04:14:24 AM »

Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2014/04/unfinished-business/

Two weeks — and it’s new release time once again. What’s new is some old stuff around control mechanics from last year has been finalized so to be presentable in game form.

Namely the player can go anywhere jumping and climbing wise without running into problems around ceilings, and transitions between levels and within levels should now be seamless.

There are also critical fixes pertaining to the prior release for anyone not keeping up with patches, and the in-game menus are a little bit nicer now thanks to a good idea that happened between releases; the idea was to let text in the menus be scooted over to make more room, so that there is no longer any abbreviated text to be found in the built-in English translation.

Last but not least there is a new feature that lets the player character behave as a monster does when they get hit. It replaces the old experimental approach to this, and is super easy to setup. I must add that I was particularly pleased with this unexpected addition, and very pleasantly surprised by how it turned out. I regard it as a natural fit; the best part of working on Sword of Moonlight for me has to be the developments I never saw coming…

For me it’s an absolute joy, a supreme joy, and so far an absolutely private joy of my own for myself. What a shame. I encourage everyone following Sword of Moonlight to get involved. You can wait but you will miss out on the formative period if you do.

Details will be coming right up...

Holey Moley · « **Reply #1 on:** April 11, 2014, 04:59:32 AM »

First of all this is SomEx 1.1.2.12. Only the SomEx.csv file in the TOOL folder has changed. Use it to update, or just download from http://csv.swordofmoonlight.net/SomEx.dll/1.1.2.12.zip.

In this release changes have been made to extensions including: do_pedal no longer exists, do_som is now do_2000, and do_hit and do_hit2 have been added in order to replace the "knock back" or rebound functionality of do_pedal.

The old do_pedal is now standard, and is not configurable. To not use it you must use do_2000, which shouldn't be used really except for diagnostic purposes, but in theory could be used to make a game play like Sword of Moonlight 2000.

Use do_hit if you want the player to be invincible after they are hit, like the monsters are, and like in classic video games. Use do_hit2 if want a second hit to connect, and a third and so on too. Or don't use either if you don't want a hit response.

The way SOM works, using do_hit may make some damage never register. It depends on how the monster's attacks are setup I think. But I don't know much about the subject. I recommend do_hit2 for the time being. It will probably be added to the new project default configuration files, but is not added by this release.

Technically these are separate extensions, however if you turn on do_hit2, it automatically turns on do_hit... and if you turn off do_hit, it automatically turns off do_hit2, since in both of these cases doing the former without the latter is meaningless.

Unlike do_pedal, there are no Detail extensions for the new approach. It's a much cleaner tack IMO. The behavior is not defined. In this release if the player is hit resulting in HP loss they will play out their hit effect, just as a monster does...

The player is knocked away opposite the attacker at a rate and distance that depends upon the dashing speed... to be clear, the damage dealt by the attack is not a factor. At the same time the player will either duck as if tapping the Action button, or if already ducked/holding down Action they will rise back up, and their action will be interrupted. Jumping, climbing, and crouching are not possible while being hit. They will be interrupted, although you may still attack in this release.

If using do_hit the player is invincible while recovering from a hit. If hit again during this period when using do_hit2 the player is still knocked back, but the ducking pattern does not repeat itself, or more importantly it does not cut into the already playing ducking animation, as that would be obnoxious.

In addition the player's ability to move is hampered while being hit. This is no more than a speed bump, it does add some gravity to the experience, but the actual reason its there is because since you are moving at dashing speed, we don't want the player's movement speed to suddenly ramp up at the same time. This workaround could be easily avoided by changing the way these things are communicated to SOM, but I haven't felt like doing that just yet.

All and all I am much happier with this arrangement than how things were with do_pedal. In truth while this effect could be disabled, it was one of those things like jumping that needed more attention. Since the release last year that fixed the damage formula, it occurred to me that there was a proper means of doing the rebound effect right there, by using the data from the actual damage event (the old approach while better than nothing IMO was based on indiscriminately considering the sources of 3D sound effects relative to taking a hit in the HP dept.)

And finally. While unrelated the menus have been markedly improved. There are no more abbreviations, and the default menus have slightly improved arrangements. How this was achieved is you can now place < and > in front of the menu text to shift if one character to the left or right (<< for two) or use $ to center text in the middle of the screen, which you'll probably only want to do for the Yes and No menus.

Centering Yes and No helps a lot on with widescreen menus, since there is no way to line the text up after performing the bug fix that makes the fonts fit into the vertical space allotted for them.

The changes made to the layout lines wise are even more dubious. They work just by blanking out some text and replacing it with text tacked onto a line just above using the special (non-printing) \n newline character.

These menu fixes are so effective that I am not going to worry about the menus anymore for as long as possible. They won't likely be looked at until 2015 at the soonest at the rate things are going considering everything there is to do between then and now.

PS: I really wanted to get this stuff out of the way before moving on to more important things. I think I will probably work on the "look over your shoulder" function before the end of the year. I have a "use every part" of the controller philosophy, and right now there is a big gap where you can't use the attack buttons when the gauges are depleted. I want to fill that gap in. It feels unfinished to me without arranging for that.

Holey Moley · « **Reply #2 on:** April 11, 2014, 07:51:43 AM »

Patch already (unrelated to this release)

There is already a patch up that fixes a chain of brokenness introduced by the last patch in the last release (http://www.swordofmoonlight.net/bbs2/index.php?topic=176.msg1561#msg1561)

Probably no one has updated yet anyway.

But it turns out there is also a problem with SOM_MAP that only happens in Release mode builds. I almost always just happen to be using a Debug build so I never noticed it until just now...

What happens is if you try to Save the map an error box pops up saying there is no disk space! It's one of SOM_MAP's custom error messages. I'm going to look into it tomorrow. But what works is to use the Convert option to make the 3D map. It will ask you if you want to save, and oddly enough if you choose Yep it doesn't complain!

Because it seems to work going that route it's hard to imagine what could be happening. Debugging a bug that only happens in Release builds can be really inconvenient. But I'll get to the bottom of it. It's not like I have any other option.

Patch: http://csv.swordofmoonlight.net/SomEx.dll/1.1.2.12.zip

EDITED: BTW, if anyone can confirm for me that you are (or aren't) experiencing the Out of disk space error message that would be a big help. Good night

Holey Moley · « **Reply #3 on:** April 12, 2014, 07:18:40 AM »

^I've added that patch with a fix for SOM_MAP's "Save" button...

It's a strange as hell bug. I don't know if anyone else is experiencing it but me, or what is at the root of it. The fix I applied was just to ignore the results of the test that SOM_MAP uses to decide to throw up the Disk-Full error message and give up.

It seems to want to see if there is 1MB of room on the disk. It seems to use a secret API that resides in KernelBase.dll, which is not even part of SOM_MAP's import table, so I don't know where it got the address from. It might be part of a C-runtime or something. I think that subroutine fails, but SOM_MAP assumes success, and then there is garbage in the memory that reports the free disk space, which may or may not be more than 1MB.

I expect this is just a bug that you may or may not see manifest itself. It may exist in the other tools too. I don't see how the existence of SomEx.dll could be a factor in this. I tried to play Deus Ex a while back, purchased from GoG.com. It would say I had 0 disk space. I thought this was because it was on a network drive, but it could be that it was experiencing the same problem. It's from around the same time as SOM.

Code: (EDITED: Here is the relevant code:) [Select]

//EDI here is 0x77d63cbb KernelBase.dll
//Release mode returns 0 via ESP+2c, debug 0x749bf44c ???
/*(both modes return 0 via EAX, so it's possible that ESP+2c holds garbage)
00413644 FF D7            call        edi  
00413646 8B 44 24 2C      mov         eax,dword ptr [esp+2Ch] 
0041364A 85 C0            test        eax,eax 
0041364C 0F 87 36 FE FF FF ja          00413488 
00413652 72 0E            jb          00413662
//100000h is probably 1MB
00413654 81 7C 24 28 00 00 10 00 cmp         dword ptr [esp+28h],100000h 
0041365C 0F 83 26 FE FF FF jae         00413488

I changed ja to jmp by writing 90e9 over 0f87.

Holey Moley · « **Reply #4 on:** April 13, 2014, 12:40:58 AM »

FYI: There is going to be at least one more patch for this release. There is a set of variables that hold the position of the player character from the previous input frame that are not carried across the warp threshold.

Also I forgot about one thing I meant to take a look at, where when transitioning from jogging to walking by way of releasing the Action key it seems like you get sucked forward. It's because of the sudden change in speed, and not having a real acceleration model setup yet...

There is a similar problem I've long been aware of, but only just noticed again yesterday, where if you push up against a wall while dashing and then stop pushing the push back response stops midway and then you get sucked back suddenly, in much the same way as above.

Both of these cases can depend largely on settings, but this is the experience for the default configuration files that were added two releases ago, so what I would like to include in a patch instead of a fix will be a generic approach to detecting if/when the rate of change is sudden so great to be visually unpleasant, and then compensate by applying some cosmetic dampening.

PS: Also, it will be Monday before I'll be able to begin working on this.

Holey Moley · « **Reply #5 on:** April 15, 2014, 04:59:59 AM »

Because a tree fell across a road through the woods on the property I live, and because it clipped a power line on its way down, I was a day late getting back to work. The tree is still there, so I may lose another day yet to that (I was hoping it would be in the way of the power company, but no)

Anyway, after investigating into the remaining defects in the input animation-like effects identified above, I decided that it was foolhardy too have ever looked upon the inertial sliding effect as a complement to the leaning into obstacles effect (technically this is an interesting but also desirable side-effect of the way things work)

While at a glance it does make the leaning effect much more pleasant, it was never intended for that, and doesn't always interact seamlessly depending on the settings used. In fact the problem is with the recommended settings it isn't seamless while dashing, and may only be just so while not dashing within a limited window (I don't really understand the interactions so it may just as well be okay at any speed. I haven't run extensive tests)

So, what I've chosen to do is to fadeout the inertial effect where there is resistance. That seems like a pretty sane thing to do anyway. And helps to offer a bit of friction. And means it won't interfere with any extensions around wall impacts.

That said. The experience feels inadequate as is. I think I must come up with a new effect for this before I can release another patch.

PS: Earlier I'd already addressed the remaining issue around warping, but did not upload a patch.

As for going from jogging to walking... I am pretty sure that is a bug. Since there are 3 jogging gaits (by default) that converge into the lowest gait, the bug depends of which gait you are in when you stop jogging. For the recommended settings if you are in the upper gaits you actually speed up before the dash has decelerated.

Holey Moley · « **Reply #6 on:** April 16, 2014, 09:49:57 AM »

Patch!

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

This is a really fantastic patch...

There is a braking system for jogging/sprinting to walking transitions. It just makes sure you don't find yourself in the paradox of walking faster than dashing by not letting the speed exceed what was the high speed going into the brake.

And there is a new system for shoving off of the wall. Or to say what happens when you push into something and then let the stick go into neutral... that is for a keyboard just releasing the key, for a self-centering thumbstick just letting go. It's pretty dicey business but I haven't experienced any real problems with it. That said it can be hard to tell if the controls are acting up or not because SOM has a really unsteady framerate that (the "fps" in the F5 overlay are averaged and updated at a regular interval and only in integrals of 5 so not to be distracting)

This is the last patch addressing controls. I want to get back to the mainline work now. Hopefully that will eventually lead to a place where the framerate is no longer so unsteady.

I feel like the existing control features have been nitpicked as far as they can be for now. I think they are a nice compromise in terms of value for attention afforded them.

I am going to get the source code up for this release tomorrow, and work on the do_hit extension documentation in the wiki. Then move onto working on the monster attack descriptions and some other stuff around translation duties before deciding on what to get to next.

PS/Off-topic: One more thing I am going to take a look at is the activation radius for NPCs. I think it needs to be relative to the outer shape of the player so that it can clear a counter in order to get at a shop NPC (behind a counter) no matter what the shape setting is. It may already work that way, but I don't think so.

And speaking of shape. I just may look at implementing a squeeze system so that the shape won't get in the way of were the player can go. I like a nice big half meter radius myself, so it would be ideal if you could squeeze into tighter spots if necessary. Tighter than a meter across that is.

Both of these changes would greatly benefit the King's Field remake/sample.

Holey Moley · « **Reply #7 on:** April 17, 2014, 06:45:36 AM »

Patch

Last patch (one post up) introduced a zero divide that is likely to be encountered when getting hit with do_hit. It will kill the player.

Holey Moley · « **Reply #8 on:** April 19, 2014, 09:39:28 AM »

Important/unrelated Patch!

This patch is a must have to keep SOM_PRM from crashing when opening the NPC page.

I removed the page from some code because it didn't seem to be needed, but the only reason I can think that it wasn't needed may have been because I didn't have any NPCs setup for the project I was using for testing at the time.

(For some reason SOM_PRM reads back the contents of the profile menu when the page is first loaded. My guess is it has to do with the variable record sizes in the Enemy and NPC PARAM folder files. I thought maybe it was because the Enemy page has more than one page, but that doesn't seem to be the case)

Holey Moley · « **Reply #9 on:** April 19, 2014, 10:41:06 AM »

EDITED: As luck would have it, I just noticed a related bug and re-uploaded the patch just now (exactly 2hrs have passed)

The related bug had to do with SOM_PRM doing the same thing as described in parentheses in the post above, only again on the second page with the attacks, so when changing to the sub page with attacks, the wrong attacks would be found the first time.

Holey Moley · « **Reply #10 on:** April 20, 2014, 05:06:03 AM »

FYI: Just uploaded a patch that fixes a feature that was circumvented by the warping handling added in this release.

The feature just kills you if you've been falling for more than 10 seconds. It's handy to authors since SOM doesn't always reset the game when you fall off of a map piece. I think it depends on if there are neighboring pieces and you pass below the "abyss" depth, which defaults to -10m I think.

What was going on is once you'd began falling at a great rate due to gravity it would appear to be a warp. So a check was added to see if you are moving at a speed great enough to look like a warp (currently an instantaneous move greater than 1 meter) and just assumes you are not warping if so, just so that the 10 second reset timeout can happen.

PS: What's interesting is even if a "Warp" event was detected at its source, so we knew for a fact you are warping, I wanted to leave the option available to authors to use a short less than 1 meter warp distance to line the player up exactly before triggering an animation for them to watch, or as a way to move the player along.

Holey Moley · « **Reply #11 on:** April 20, 2014, 01:52:29 PM »

Yet Another PATCH

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

Earlier today I uploaded new tool EXE files, and added English versions to the English language pack...

The reason was I changed a number of drop down menus so to not have scrollbars. I assumed, and I think rightly so, that that would mean the menus would display all of the items they hold. HOWEVER, it turned out that that was NOT the case. No, by Windows logic you have to use the arrow keys on the keyboard (mouse wheel won't even work) to find the well hidden items.

So! I had to add another patch that manually sets the heights of these menus so that they will not be cutoff.

The reason I did this is to make it easy to maintain language packs, since extensions may add things to these menus (as the previous release did) and it shouldn't be on language pack maintainers to deal with that, and it's too much work/error prone for SomEx to maintain a list of what menus do/don't need scrollbars.

Holey Moley · « **Reply #12 on:** April 29, 2014, 01:23:24 AM »

Quote from: Holy Diver on April 16, 2014, 09:49:57 AM

PS/Off-topic: One more thing I am going to take a look at is the activation radius for NPCs. I think it needs to be relative to the outer shape of the player so that it can clear a counter in order to get at a shop NPC (behind a counter) no matter what the shape setting is. It may already work that way, but I don't think so.

So I looked into this. It turned out that my KF sample project was just using a really ancient Ex.ini config file setup that still used _range instead of _radius for event activation.

I think this is still probably a good idea, but the default setting easily clears a counter. In fact, it's just about perfect. I think the reason SOM uses this distance for activation could've been a last second change to make it possible to talk to NPCs behind counters. Of course that could've also just been experience from developing KF games for all those years. But in a KF game for all we know the counters could've been part of the NPC model, since they were only used for that singular purpose.

While it's a good distance for talking to NPCs behind counters, its a preposterous distance for reaching out and touching things with your hands.

Holey Moley · « **Reply #13 on:** April 30, 2014, 03:42:01 AM »

FYI: I just noticed that the "slip" effect that basically keeps you from hovering out over a ledge is broken... most likely by this release, particularly the part that changes up how the ceiling is interacted with.

I'll look into it tomorrow, hopefully nothing will stand in the way of restoring the effect. I've noticed this for a while actually but didn't realize what was happening since I was noticing it when fighting with the ceiling.

Strikeout: player_character_slip was disabled in the configuration file

(same story as above)

Holey Moley · « **Reply #14 on:** May 07, 2014, 01:04:02 AM »

Patch

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

This patch addresses a debugging window that would popup in SOM_MAP reported by Arbalest, and a bad behavior in SOM_MAP in which if you opened the Maps menu and cancelled out (or similar menus in the Warp event setup dialogs) the last map in the menu would become the target for som_db.exe and mapcomp.exe (playtesting/conversion to 3D)

Also, as a reminder (since I don't see it mentioned in here) the monster PRF files and English language pack were updated a while back to include rewordings/translations for the attack descriptions that slipped past the release they belonged in:

http://swordofmoonlight.net/text/English/Neutral+Default.zip

For Japanese Update the DATA/ENEMY/PROF folder.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Unfinished Business

Author Topic: EXIT: Unfinished Business (Read 13463 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,

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: Unfinished Business

Author Topic: EXIT: Unfinished Business (Read 13463 times)

Sword of Moonlight|

Devs|

EXIT: Unfinished Business