Topic: EXIT: Layer feature unearthed, now restored (Read 15601 times)

Holey Moley · « **on:** September 09, 2018, 09:30:22 PM »

Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2018/09/layer-feature-unearthed-now-restored

I feel like there should be a lot to say about this, but I am perhaps too exhausted to say it. So, in brief, some months ago (I can’t recall how many) I began to notice some mysterious code within Sword of Moonlight, that I thought must indicate something was removed, to do with playing more than one level at a time. I thought it could be “layers” or a corridor between levels, or both of these things. I looked into it once or twice since. I even felt it may have been a load balancing system.

A month or so ago a person appeared who was working on figuring out the contents of King’s Field II’s disc for the PlayStation. Speaking with them got me to take a look myself, since it’s something I’ve been meaning to do. I wasn’t much help, but I did notice that there is two layers on each of the game’s zones. The other layer is interleaved with the first. I realized that’s the only place it could be, going by the size of the files that remained. That was a few weeks ago or more. Ever since then, I began work on making a layer system available to Sword of Moonlight, starting with its strange code from before.

I didn’t stop at getting the extra layer working, since layers is actually a big deal for Sword of Moonlight! I stopped everything to complete work on it. It also gave me a chance to investigate the MPX file format containing level definitions, and the MapComp program that produces its file format. I had pictured myself doing this at the beginning of the year, in fact, but couldn’t help from getting sidetracked. And so, I was glad to have gotten the year back on track, right on schedule.

By now I know everything there is to know about that code from before. I kept coming across it in different forms time and again. I think I’ve seen every trace of it by now. It was a layer system more or less identical to the newly developed feature. In fact, I used what bits and pieces of it I could, in order to not waste it, and to be able to say that it is a part of Sword of Moonlight having origins in its earlier days with From Software.

EDITED: This release's devlog: http://www.swordofmoonlight.net/bbs2/index.php?topic=67.0

Please SVN Update and follow the updater. While there go into the language settings and update your TOOL language package. Alternatively the files directly involved are listed below.

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

Language packages
English (TOOL)
http://www.swordofmoonlight.net/text/English/Neutral.zip
Japanese (TOOL)
www.swordofmoonlight.net/text/日本語/最新.zip

To add layers, go into the Map menu, and select two maps. Doing so enables the Compose toggle/button. The map with the lower number is the base map. Only the base map has EVT and MPX files. It is the level. Its layers are subordinate. To add more layers, up to 6, clicking/toggling the Compose button for each.

After this process the layers will become shortcuts to the base map, which will open to the chosen layer. Where the map title is shown on the main screen is now a layer switching menu.

A layer gives you more freedom to flex your creativity as an artist. They let you put tiles on top of tiles (or even right on top of each other--inside one another.) Layers are not above or below each other. That would be too restrictive, and pointless. They can intersect at any point, and are just useful for having more combinations of tiles.

The map's starting point (for testing purposes) is assigned to a layer when right-clicked, and likewise everything on the map lives on a layer. This notion of belonging to a layer is lost on the MapComp program, and unlike the original system is not passed to the player via the MPX files...

All that it is for is so when tiles are moved up and down, if things live on the same layer* as the tiles, then they will move up and down with those tiles.

*Technically layers can belong to a group, which I've called a z-index. If you make your layers out of order, the current system shows the raw z-index in the sliders that change what layer(s) that things belong to...

This z-index system isn't going anywhere, but I've thought about sorting the z-index values according to the layer order, to make them more intuitive. However, really, changing what layers things live on is something that is not normally required.

There is a new LYT file format added to the MAP folder. LYT stands for "layer table" and I took the name from the LVT (level table) file format. Likewise, there is an MPY file format that complements the MPX format. And MPY file is so far identical to many MPX files stored back-to-back in the file, but without things that are stored in the MPX file, like the vertex buffer, and MHM files, and all of the level's NPCs, etc.

SOM_MAP makes LYT files, or you can make them by hand. MapComp makes MPY files. Once you add layers to your MAP file it will not work with MapComp without SomEx.dll. This is because it tries to incorporate the layers, but it crashes because the memory the code wants to use for layers has been removed from the EXE, i.e. MapComp.exe.

SOM_MAP's "objects" are the only thing that used the layer field for a different purpose. I was able to determine at the very end that it was definitely intended to be used as a layer field, but for some reason the field had been changed so that when the MAP file is saved, the object-type from the PR2 (PRF) file ended up in that field instead. Because it only writes the field, it means that SOM_MAP doesn't use this field this way. And neither does MapComp use it. So, I determined it best to restored the field to the layer use-case...

As a side-effect of this, in order to work with older MAP files, it is necessary to tell if the files are using the newer layer facility or not. Because of this, the maximum z-index in this scheme needed to be 9. So this set a ceiling on what the limits of the layer system would initially be. Likewise, the player (oddly enough) has room for 6 layers (7 including the base layer) in the memory ahead of where the original layers would have been (where the base layer currently is) and so the new system just uses negative numbers to refer to the layers. This is a pretty weird turn of events. It's hard to imagine why there is so much vacant memory in the data structure (it's not global memory) but there is, and it sets a limit to 6.

As a result, I've decided to limit the layers to 6, and reserve 1 extra z-index for things that you want to not live on any tile (so no tiles/layers can ever move them up or down.) You should use 7 for this purpose, but technically you can place anything on any z-index at any time. New layers take the next available z-index. 0 belongs to the base map. A hand edited LYT file can group layers, but it's not recommended, and is more a provision for later, if the ability to use MAP files other than 00.map through 63.map is facilitated--either for base maps or layers only.

What SOM_MAP currently facilitates is called the "basic layer system" that just uses the simplest workflow possible. If your base map cannot be the lowest numbered MAP file, then it must be renamed in the MAP folder, and any events that connect to it must be reassigned by hand to its new MAP number.

The LYT file can be hand edited to customize the layer menu. The Compose button inserts maps into the LYT file according to their MAP file numbers however. The only part of the layers that is used is the top half of the MAP file. If you make a MAP a layer, the bottom half of its file appears to be missing, but it is retained, and will reappear if made back into a standalone map.

When you work on a layer, you are really working on two MAP files, and so will save both. What you see is a composite of the layer, and the base map. The only thing you can change about the layer is its title. And its tiles of course. Everything else is as if you are working on the base map.

Holey Moley · « **Reply #1 on:** September 09, 2018, 10:02:29 PM »

(DualShock 4 experience & Last minute control changes info)

EDITED: Earlier today I took out a DualShock4 controller I ordered 2 or 3wks ago. It was not a fun experience. It turns out that the shape of its output is a perfect circle, more-or-less. This differs dramatically from the DualShock3's (or technically what I use is a SIXAXIS) almost perfectly square shape!

It's criminal that controllers can output such different shapes... under DirectInput no less. I have no memory of a controller with a circular shape. I don't know if that is common now or what. The DualShock2's was square also.

The controller code I've developed in the last month or two, somewhat in response to VR that now largely hinges on making the square fit into a circle, when applied to a circle, produces a somewhat smaller circle. As result, the DualShock4 was not hitting the 1/sqrt(2) requirement for moving diagonally at full speed ahead.

Since, I'm far from having a friendly UI for controller customization, I'm trying to just be able to accommodate all controllers... but I think that something must be done in the following months. Since the files I uploaded late yesterday, but before this advertisement, I've update the files, to lessen the mapping from a square to a circle, somewhat because the squares were not quite squares. (Edited: technically it's not even correct, since while not square, the points were still in terms of a square. But it's just a compromise for the time being.)

But I do not believe that this is enough to bridge the gap between the two extremely different controller shapes.

I was surprised that Sony has included DirectInput drivers with the DS4! But I opted to not use them... yet, because I will have to add a new mode to the Ex.ini templates to match them, since they don't use the standard mappings. And the L2 and R2 triggers range from -1 to 1 basically, which is kind of strange, and when they get assigned to turning or moving functions, they just take off hard in the negative direction!

So I tried this software called DS4Windows which I've lately had to rely on just to get my SIXAXIS to work (it shares a component with the SIXAXIS solution I've used for a while now, that expired a few weeks back.) It has settings for customizing, much what I'd like SOM to facilitate. To get the DS4 to play nice I had to set "anti-deadzones" to 0.1 since the DS4's deadzone is much smaller than the DS3's, and its "sensitivity" settings which seems to scale up, I've set to 1.05 so that it is slightly more square like as necessary.

So, unfortunately, this means that the analog controls are still unsuited to a lot of controllers, and it's just going to be a PITA to make things work well. With controllers this disorganized I wonder if PC games stick to their keyboard/mouse guns just to avoid officially supporting controllers.

Unfortunately DS4Windows seems unstable. (Edited: the default BT Poll Rate setting seems to be a culprit here, at least with BT.) But I'm glad I had a chance to test the DS4 with SOM. Running DS4Windows makes it impossible to use my SIXAXIS until my workstation is restarted, so I much choose which to use day by day.

LAST BUT NOT LEAST I was very unsatisfied with how tightly wound the DS4 is. It's impossible to trace anything remotely resembling a circle. I hope it just needs breaking in. I can't understand how FPS people (who apparently dictate controller design now) prefer it over the SIXAXIS. Which I'm still preferring... because cinematic camera control is my preference.

EDITED: I also noticed the "half-gait" system was not ratcheting properly. It is a pseudo gait used to add half diagonals to the first gait. Hopefully it's better now.

EDITED: I don't understand the DS4's analog stick's grip redesign. It just puts a lot open air under my thumb, and so makes it readily loose contact. Don't see how it helps at all, unless it's something to do with sweaty gamers.

Holey Moley · « **Reply #2 on:** September 13, 2018, 06:38:48 PM »

Running sideways patch

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

This patch addresses issues with the recent change from square joystick coordinates to circle shape with regard to speed/movement transitions in the lateral direction when dashing.

Note: these changes are managed by the do_dash extension. But disabling that extension is unpleasant because it also limits turning speeds when dashing so that higher/user-friendly turning speeds aren't unwieldy.

Holey Moley · « **Reply #3 on:** September 18, 2018, 05:57:39 AM »

Stair climbing patch

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

I'm working on KF2 right now. Its setting has many stairs, that are similar to the exterior set's stairs. It's not fun on the stairs. So it is a good opportunity to improve walking on them, which is quite tricky with analog controls that more or less simulate a pair of feet.

This patch goes a long way toward a good experience. It's not bad, but it's just the beginning, and is more or less a bunch of cheats. It started with wanting to be able to move on the stairs at slow speeds. In the present state, the first 2 gaits were denied access to the stairs. So I had to change things so that slow movement could overcome the wall parts of the stairs...

The fight that the stairs provide is kind of cool. So I wanted to keep it when moving at standard speeds, but change the dynamic at slower speeds. The intention is to provide the impression of slowing down to negotiate the stairs, but not to deny access. And slow movements are very cinematic, and so very desirable.

After it was possible to move up and down the stairs slowly, many more problems became apparent, and so have been addressed one by one. Some of the problems include falling off the step before slowly moving to a safe place to stand, and a sense of moving to fast upward, or bouncing too much when going down (which right now is no different from falling down, aside from slight differences in the bounce effect.)

To lessen the interference on KF2's stairs the error_parachute Analog extension is reinstated with a nonzero default value. I haven't noticed any problems because of this, but it seems like it helps to ensure smooth landings when jumping around. I could never put my finger on why, but every now and then a jump will land unpleasantly for a little while, and I think it was because I'd disabled this extension (or set it to 0) and so I hope I didn't disable it for specific reason!

KF2's lighthouse's stairs are especially too steep. They are too narrow to stand on. I think I will have to play around with the MHM models eventually. They are 1/4m tall, but also 1/4m deep, which is not enough space to move on. Fortunately other stairs tend to have more room to stand, as does SOM's exterior set's.

EDITED: There's also a fix for a problem with right-dragging SOM_MAP that seemed to start a few days ago. I'm afraid it's a temporary Windows Update thing. I simplified the way dragging works, which seemed to make the problem mostly go away, and is conservative enough that I don't think it will be a problem for different versions of Windows. My mouse may just be funny, but I can't see the cursor visibly twitching.

Holey Moley · « **Reply #4 on:** September 18, 2018, 07:13:39 PM »

Patch-patch

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

Uh, last night's patch had a change I added yesterday that I don't think I mentioned, that was designed to have more of the "bob" effect when walking very slowly, so that it doesn't feel like gliding like a ghost or a robot on wheels...

I thought it was continuous when stopping (approaching zero) but I noticed today that it was too dramatic when coming to a rest. And so this patch scales back that effect considerably in order to smoothly (hopefully) bring movement to a close...

You can think of it as changing how you move your legs in order to go more slowly/deliberately. The current "bob" defaults are practically imperceptible when walking, and doubly so when moving slowly. I kept watering it down, finding it to be an annoyance. And it's more noticeable in VR, so the current baseline is more based on what VR will be like than otherwise. I don't know if I reduced it further for VR's sake or not. But it's definitely easier to notice.

Even though it's hard to see, I have a feeling that the visual system still detects the motion, and will notice it's absence as "robotic" movement.

(EDITED: I did look for issues yesterday. It's possible I have them now, or can see them, because the computer is in balanced-performance mode. So Windows won't go nuts and rev up the fan.... more to keep background tasks from going wild than SOM. But it does limit game performance also.)

Holey Moley · « **Reply #5 on:** September 22, 2018, 10:02:38 AM »

Multi-feature Patch

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

There's a lot of good in this patch. I will probably forget one or two things, but will try to describe what's in it of the top my head...

1) A new deceleration system is added to do_dash. It just uses two variables for the jogging transition and sprinting/running transition to determine if deceleration is required after the Action button is released. All the deceleration means is it will take longer to slow down than when doing a button tap dash/dodge maneuver. It's just so it doesn't feel like running into a wall when you letting off the Action button. If it takes longer the stop is less jarring.

2) A fix for looking up and down is added in order to keep tiles from disappearing on the side when looking down from high places, or up at very tall structures. It may not be ironclad but is well tested for medium range draw distances. In general I don't recommend long draw distances because there is not an LOD system, and things get ugly and performance degrades when triangles become pixel sized or smaller.

It's never really been a problem before, but the fix is needed both for KF2's lighthouse, and the high cliffs and waterfall.

3) I just now worked on a problem with climbing the lighthouse, wherein a system that was put in place to keep from climbing into things like windows when a wall would prevent the PC body from entering was interfering with climbing the stairs while hugging the walls. I am not 100% certain, but I think that I simply never encountered this problem before because SOM doesn't come with any models that put a wall next to proper stairs. It has only the exterior set's stairs, and they don't really touch walls. (I think the problem would have occurred if those stairs were placed beside the exterior column piece.)

EDITED: To be clear, the wall test applies to climbing with the Action button, but not (or no longer) to normal climbing, onto platforms that are short enough to be automatically walked on top of.

4) SomEx.dll now depth-sorts transparent scenery. The way it was originally done I think was very CPU intensive. It simulated drawing everything, so that the depth was in the final screen space. That's a lot of math. I can't think of a reason that just calculating distances is not just as good. The sorting method somehow produced fighting, so that in the Moratheia demo for instance, a glass jar would shift around (fight) as you walk around it, viewing from different angles. This could just be because the center points used by the sort are not very good. I intend to improve upon them before too long. But in any case, the new sort doesn't change the order when center points are close together. It avoids this catastrophic glitch.

Sorting transparent models/parts of models is not an exact science. This patch also has MDO materials for MSM textures. It's added for KF2's water and even though maybe it could have been accomplished with only "objects" instead of level geometry, I have a feeling the ice cave is fully transparent, and would not be possible without the feature. So it's time has come. I'm still working on the new material system, which includes UV map animation. That is not technically part of MDO that I know of, but it's part of the system, and to be used to animate the water in the starting zone. That is not in this patch. (Edited: transparency works, but I haven't investigated MDO's blending modes, and so this patch is limited to standard alpha blending.)

I'm preparing a KF2 demo that will include builds pretty similar to this patch. I'm trying to polish up the experience so that it's serviceable.

P.S. I also intend to do a little bit with VR before putting the demo out. I mainly want to go back to the old system that seemed good at eliminating drift, but did not look as good. I have to develop a system that decouples the image's location from the sensor data, since it's too chaotic with the better anti-drift settings.

P.P.S. I have a new lead on position tracking for PSVR (https://github.com/HipsterSloth/PSVRTracker) which is good news, although it's an unfinished/experimental code base. It's still surely much better code than I could've developed in short order myself. I'm confident position tracking will come online for KF2 before 2020. But don't expect it in a demo anytime too soon.

Holey Moley · « **Reply #6 on:** September 25, 2018, 04:52:07 AM »

NEW RELEASE PATCH

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

The new layer feature is broken without this patch

The MAP file is stored upside down. Somehow this never became an issue for the layer system until I noticed a problem today. Without this patch, the tile heights of the base map that is used to produce the starting points for everything on the layer map are inverted along the vertical dimension.

It wasn't a problem for saving the base MAP because it was read right-side up, and then written (saved) right-side up, and so in that case, two wrongs did make a right

Holey Moley · « **Reply #7 on:** September 28, 2018, 05:05:40 AM »

3RD TIME'S THE CHARM

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

Last patch saves the base map off by 1 row

P.S. This patch also includes good PlayStation VR upgrades, and I worked all day yesterday on climbing stairs, and climbing around KF2's pier in various ways (with the water plane acting like a frozen ice rink.)

Going down stairs needs work also. It has to better differentiate between climbing and falling, that is a whole new feature. I'm not going to work on it before uploading the first KF2 demo/backup in the next few days. In the meantime it's necessary to walk down stairs slowly, which means tapping with the keyboard. I have mixed feelings about it, but I reckon that walking down stairs at full speed should go smoothly.... and running should probably also.

Holey Moley · « **Reply #8 on:** September 28, 2018, 01:09:20 PM »

Patch

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

This reinstates the ability to initiate slow-moving climbing with the lower 2 gaits.

It's something I worked on, but (mistakenly) thought it was no longer needed, and so removed it prior to publishing the latest patches. It wasn't needed to walk on stairs, but is if you are not already on the stairs (it works on the stairs because the clip radius shrinks down so it's possible to stand astride the steps.)

(I was also eager to remove it because it was causing a glitch, but I revisited the problem, and realized I'd come up with the same solution, except that in the course I'd eliminated the source of the glitch, not knowing it at the time.)

Holey Moley · « **Reply #9 on:** September 30, 2018, 06:51:48 AM »

Patch

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

In my free-time yesterday I managed to make climbing deplete the gauges, and looked at a problem with running up stairs wherein the last step at the top of the stairs will slingshot you forward in an unnatural way...

The problem with stairs has to do with the difference between the clipper location and the camera location, where when the resistance provided by the stairs gives way the two catch up again and it just feels wrong.

In the middle of working on the problem I used the opportunity to make running up stairs feel more intentional. The solution to the problem is to momentarily tighten the coupling between the two locations. But I went further, and timed it so the tightening ebbs and flows with the walking animation, in order to create the impression of skipping over steps as would be required to move so speedily on stairs...

In addition I was able to loosen up the coupling on the vertical dimension so that it feels more bouncy. This actually helps to make it seem more smooth. Without it feels too glitchy for one reason or another. I think I slowed running down a little on the stairs too, beyond the natural resistance provided by the wall like parts of their steps.

I'm mainly providing this patch because I intend to use it for the first public sharing of the KF2 project I've been sitting on this month.

P.S. I've decided to not specialize movement in the case of descending down stairs. Instead, I will look at how to make falling down stairs less dramatic! So that it's possible to run down them in some sense. I've decided this because it's been possible to make running up stairs work so well, and so I don't want to compromise on going down them. My main concern, is I don't want the audience to have to think about if a platform constitutes stairs or not. If they want to use the top of stairs as a jumping off point, then it should work just as well as any other surface. As should falling off of a stairs like configuration of polygons. At the end of the day I am committed to SOM treating polygons generically for purpose of interactions.

Holey Moley · « **Reply #10 on:** October 01, 2018, 01:10:17 PM »

Patch

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

I noticed a problem with climbing onto corner pieces. At the same time I worked on making the press to climb more forgiving, which is something I've always meant to find the time to do.

How the change works is if the button is pressed while pushing against a wall it can suppress the action button for opening doors (if there is something to climb on) but otherwise, climbing still works (now) if the button is pressed too soon, but climbing is possible by the time it is released. In that case, the Action button still goes through (can open doors) but will also climb.

Without this change, it's pretty frustrating to climb, because it has to be done very deliberately. I have designs to change the buttons so that doors are opened with the attack buttons, however that's not so far come about, and is an unproven design.

For now, I just want to polish movement as much as can be for a KF2 demo.

On one, if climbing accidentally reveals a secret door, or opening a door accidentally climbs, it's not ideal. But on the other hand, if the goal is to climb, and instead a door is opened, then it could be catastrophic if the door prevented the climb (all bets are off if its opening animation ejects the character, but such is the spice of life.)

EDITED: I believe that menu/text screens still cancel climbing. It's possible to fix, but there are a lot of parts involved. It looks better to cancel than to not.

Holey Moley · « **Reply #11 on:** October 14, 2018, 02:28:06 AM »

SOM_PRM patch

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

This patch fixes a crash when doing a search from an item slot that is after the last filled slot, which can also happen when doing Ctrl+C for copy, since that was trying to do a search. (For ASCII control code 3, that is ^C I think.)

I also noticed the Cut button throwing up a bogus message that just says the name of the item being cut... I have no idea what this is about, or if it's always been there. I tried to hide the box, since it would be a lot of work to definitively find the code that creates it and remove it that way. Possibly other boxes can be disabled. Hopefully not.

Lastly, I noticed that closing from the taskbar did not bring up the Save? prompt. That is likely a problem for SOM_SYS also.

Holey Moley · « **Reply #12 on:** October 14, 2018, 06:44:46 AM »

Minor feature patch

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

This patch keeps MapComp (objects) and SOM_DB (NPCs) from crashing on instances that don't have entries in the OBJ.PRM and NPC.PRM tables.

I thought that this was unnecessary, but it turns out that these types are a problem. In general this is an area of interest that can use some attention. Originally SOM_MAP just deleted these kinds of instances from MAP files without much recourse.

Holey Moley · « **Reply #13 on:** October 15, 2018, 06:45:04 AM »

Oops!

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

The last patch got objects wrong... seemed to work, sorry. This patch works with the DualShock4 without any third-party service. Still feels funny though... I am warming up to a release built around controller calibration in order to better support a range of controllers.

EDITED: The next patch improves the controller support by defaulting to its circular shape, instead of trying to reshape from a square to a circle as is done now by default. This makes it technically better than using DS4Windows for basic functionality for the time being.

Holey Moley · « **Reply #14 on:** October 15, 2018, 09:38:29 PM »

DualShock4 patch

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

This patch disables the new feature that morphs square joystick inputs into a circle shape for the DS4 (not using DS4Windows) since it's shape is known to be a circle! This solves the problem with moving at full speed along the diagonals...

Support for the controller found its way into yesterday's patch by accident, since I'd been working on it earlier in the day. It didn't occur to me to solve the problem in this case, by simply exempting it now that it is detected/given special treatment.

The DS4 and Xbox (XInput) controllers don't use the mapping from the Control Panel, since they are mapped internally to more conventional layouts, in order to be easier to configure, since SOM's control settings are not on a per controller/product basis. Like the X and O buttons need to be remapped to the first 2 buttons, because that's what SOM uses for confirmation/cancel dialogs. I don't know why Sony chose to not make them the first two buttons for this purpose to begin with. Sony mapped Start to the Share button, and Select to the Options button, which seems weird, since they are on opposite sides. The triggers have to be mapped to buttons to be usable. SOM doesn't envision triggers as buttons. Leftover buttons have to be moved to make room for these virtual buttons.

P.S. I think SOM uses the first button for cancel, but in any case, I think I'm biased to preferring the Japanese convention for cancel/confirm, and maybe there should be an extension to flip these. No one has requested it. But I set up the mappings to use this convention.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Layer feature unearthed, now restored

Author Topic: EXIT: Layer feature unearthed, now restored (Read 15601 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: Layer feature unearthed, now restored

Author Topic: EXIT: Layer feature unearthed, now restored (Read 15601 times)

Sword of Moonlight|

Devs|

EXIT: Layer feature unearthed, now restored