Sword of Moonlight > Devs
EXIT: Unfinished Business
Holey Moley:
--- 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.
--- End quote ---
Details will be coming right up...
Holey Moley:
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:
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 :goodnight:
Holey Moley:
^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:) ---//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
--- End code ---
I changed ja to jmp by writing 90e9 over 0f87.
Holey Moley:
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.
Navigation
[0] Message Index
[#] Next page
Go to full version