Topic: EXIT: Spinning plates! (Read 9563 times)

Holey Moley · « **on:** March 18, 2018, 07:54:29 AM »

Quote from: http://www.swordofmoonlight.net/archives/exit/2018/03/spinning-plates/

So, I realized recently a bug was introduced into the level design tool — not long ago, but not so recently either — that is so sinister that I stopped everything to prepare a new release in order to minimize the possibility of spoiling anyone's fun.

Truth is, I was looking for an out anyway, since the latest work has spun off into multiple different directions, some completely unpredictable. The genesis of this release sprung from an inspired moment, that I couldn’t have predicted at all, at the time. And ended with only the basics of that idea realized. Instead, the focus of this release became a small side project to find a way for the tool’s two number tables to be able to set a column to the same value for more than one row at a time — in any combination. I wanted to do this since two or three releases ago, because this will be important in the future, in order to fully take advantage of a new way to adjust the order items are displayed in game menus. The basic problem being that the items need to be in the game before they can be so adjusted, and until now there was no easy way to do that than to manually select every one individually and input a quantity figure into these tables.

The reason this mushroomed, is the tables themselves are unique among the element’s of Sword of Moonlight’s tools. And since they are only in two relatively insignificant places, I had not personally spent a lot of time with them, and now that I was doing so, I saw their evidently substandard state, and felt it was high time to bring them up to code, whatever it took.

The other standout highlight of this milestone release (1.2.2) is I was finally able to get to the bottom of why Sword of Moonlight’s button elements appeared different from the bitmaps embedded in the program data, and so all of the button bitmaps have been replaced with composites of the originals and their degraded versions — or how they’ve actually appeared to the end-user up until now. For the gray buttons, it wasn’t simply possible to use the actual image, because its hue is much more red, and so does not appear designed to blend naturally into the background images that the buttons are displayed over.

Up to now, new buttons appeared with this red coloring, and so could be distinguished from old buttons. Now everything is even.

Other highlights to look out for tie back into the most recent few releases: For one, the level design tool can now generate all-or-any-combination-of 3D “maps” at the same time, and can test any one without opening it up into the tool. The idea to do this did not occur to me at the time, but it is a very natural outgrowth of the next-to-last release. The tables work builds on three releases ago. And what I’d originally endeavored to work on builds onto the previous release. I did as much work as necessary in the last day so to not leave anything unfinished to do with it. But it is still not practical, and is only available with the English language package in this release. It is only the beginning of a richer feature set for “items” in games; most address swordplay.

This final item is an ongoing effort, since it touches on many aspects, of which only the first is enabled by this release.

– - – - –

Unrelated, in the interim, I also seem to have done a job restoring the WebGL and SOM database features inside this website, including some enhancements. The work was spurred by the server here having been migrated to a new operating system, which broke some programs at the binary level. I’ve also taken down numerous blog postings from the past, which I would categorize as being of low or dubious information, primarily having existed to signal the “lights are on” on a month-to-month basis.

One last piece of news, which I’d considered making the focus of this month’s blogging, is that a new Sword of Moonlight forum has been created at https://www.reddit.com/r/swordofmoonlight/ in the hopes of A.) attracting outsider participation with a low barrier to entry and casual atmosphere, and B.) establishing a neutral ground zero that can receive a sudden blast of interest in Sword of Moonlight without going down, especially because I have to keep the spam countermeasures here as locked down as can be to not manually deal with the stuff on a regular basis. The forum is not active right now, and will probably remain so, but I intend to add links to it around here before long.

Detailed breakdown forthcoming, tomorrow, or not before long

Holey Moley · « **Reply #1 on:** March 18, 2018, 09:39:05 PM »

Patch

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

Searching in SOM_PRM's NPCs/monster "loot" boxes by typing a letter with the keyboard crashes without this patch...

I remembered there was 2 box IDs when I added search to the profile boxes, and I neglected to investigate what the second was (thinking maybe that the boxes had different IDs on different tabs.) I'm surprised it straight up crashes. I'm unsure what I was trying to accomplish by ever having considered those boxes for this feature.

Holey Moley · « **Reply #2 on:** March 19, 2018, 03:36:06 AM »

Things in this release... saving the big controversy for last...

First, things not in this release: unless mistaken, there are no changes/enhancements to the player. Just tools. All 3 of the classic tools see some action.

*SOM_SYS's slideshow like presentations have a "play" button, that lets you save your work without watching it playback. This might have been a patch to the previous release, but it's a development since the last blog posting nonetheless.

*The simpler, single-column lists now have a keyboard navigation aid, in the form of their text is yellow (the color SOM uses to denote selection) when they are active. This has long been a bugbear of mine, since it's been impossible to tell if they are active or not all of these years.

*There is a "multi-selection" model for these lists, but I'm rolling it out selectively. So far it's only used by SOM_MAP's map selection screen. Where it is used to run all of the selected maps through mapcomp.exe. When 0 or more than 1 map is selected, the Copy, Paste, etc. functions are visibly disabled. Eventually (it will probably take a while) multi-selection will be extended to all of these functions where it makes sense. Copy/paste is an especially involved job for things like events, and when I get to it, it will be possible to copy and paste between programs.

*A couple releases back the ability to build maps using the MHM models was added. It occurred to me that that work could easily be translated over to the map selection screen, so that now there is a button on that screen that is identical to the one on the main screen that interfaces with mapcomp.exe. The difference is that it applies to the selection on that screen. When there are multiple maps selected, it fills out the progress bar to indicate each MPX file generated.

*Much later it occurred to me that the test function could also work on that screen. I wanted to separate it from the multi-mapcomp button, so instead I made it a small button, with a triangle inside of it... not the ticker like triangle button, but with the Shift-JIS triangle, modified with a technique for turning Japanese characters 90 degrees so it looks like a play/pause button.

OH YEAH! Before I get off the map selection screen. It was thanks to working on it so, that I discovered the "sinister bug" from the blog post that precipitated this release.... or made me to wrap it up hastily so a release could fix the bug. Basically, I don't know how far back this bug goes, but it's been around for at least a few release cycles. What I'd done, is failed to consider, or managed to break something through excessive revisionism, the case where a nonexistent map is opened. IN that case, the bug would fail to recognize that the map changed, and ever since late last year, extensions keep track of the current map so that 00 doesn't have to be the first map. The repercussions of this are grave... boiling down to basically making it impossible to create a new map...

I'd guess that this problem went all the way back to when I first instituted this change of workflow. Except that I can remember making new maps what seems like not very long ago, in comparison to when that change was made. So just by my foggy memories, I think I probably had it working properly at one point, but later managed to break the solution, some releases ago. I'm always trying to simplify the code that deals with the tools, because it's become a kind of sprawl.

*On the event programming screen, there is now a sorting function, so that the list of "instructions" to choose from are in alphabetical order. It's up to the language packages to enable this, by putting the box in LBS_SORT mode. The English pack does so, but the Japanese does not. (EDITED: I could be wrong, but I think that the sorting is more sophisticated than simply going by the binary representation of the first character... because the collation comes out quite nice.)

*There's also a new button on this screen, that I had to disable in order to rush this release. It was half finished. It's going to add a way to insert marginalia into the programs in the forms of lines that have a custom text, and can have additional lines of text when opened. Programmers call these "comments" inside of code. The idea is to provide a human readable description of the programs, so they are easier to maintain and browse.

*I think while I was working on that new button, since I decided to make it very big, and to emulate the text-on-wall messages from the King's Field series with it, that I found renewed interest in a longstanding problem with the tools' buttons. The problem was that they looked different from bitmaps in the programs. That meant that language pack designers couldn't rely on their button graphics to appear how they are designed to. And not only could I not figure out why it happened, I could not emulate it either. So as a result, whenever new buttons needed to be added, they would look different from the original buttons. So basically, I finally got to the bottom of this, and prepared new button graphics for the tools to use, that are visually somewhere between the bitmaps and the discolored/tone-mapped/posterized buttons that defined the look of SOM's tools until now...

This change, while comparatively simple, is what I consider the defining change of this release. It's why I've turned over the minor milestone number in the version from 1.2.1 to 1.2.2. The reason it's 1.2.2.2 is the last number is technically a "build" number, and I designed Somversion.dll to interpret a 0 in that number as an error, and later decided that odd build numbers would be reserved for demonstration builds, and so the first valid release number is 2. (I guess I will have to explain this every time the larger number rolls around

)

*I'm still not to the most interesting news, that is also the genesis of this release--or releases if there is indeed another--and so far, all the completed features I've described are little things I'd not anticipated working on, that happened to occur since the prior release. There was one feature I wanted to pencil into my schedule, but didn't know if I would get to it, that I started to work on just as a lark in the little time I had one day while waiting for a ride into town...

What I was exploring then, was how to basically do a "check/uncheck all" feature on SOM_SYS's hero inventory box. This was a feature anticipating future work on the player's Inventory menu, that had begun a few releases back. I tried adding a widget to that screen, until I realized that really what made sense was just to have changing a number, change every row that was selected. I'd already decided it would use a multi-selection scheme, and the widget was going to set to a number, and not to 0 or 1. And so that made more sense, aside from being slightly less obvious to end-users.

*So I did just that. Except that I ran into numerous problems while doing so, so much so I knew I had to stop everything to care for SOM_SYS's hero inventory table. It appears identical to SOM_PRM's shop inventory table. And so I thought it was, until like the 3rd or 4th day of full-time work on it... at which point, in order to make the tables not "flicker" when clicking on their input boxes, I had made them to use an LVS_EX_DOUBLEBUFFER mode, except that while this seemed miraculous at first, it wasn't until I returned to SOM_SYS from mainly doing tests with SOM_PRM, that it just so happened that SOM_SYS was somehow programmed very differently, and for whatever reason, did not play at all nicely with this alternative mode...

So it probably took me at least a full work day, if not two, to get SOM_SYS to behave. What ultimately did the trick, suggests that there is something very different about these tables, or that someone who worked on SOM realized there was a problem, but didn't apply whatever fix was entailed to SOM_SYS's table.

*There are several problems with these tables. But I won't recount them. Just know that they are all dealt with. And the keyboard navigation from inside the input boxes that appear when clicking on their column cells, is now enhanced to match the regular boxes scattered throughout the tools. To select multiple rows, you have to drag on the first column, but must find a place after the letters that make up the names to begin dragging. I'm not sure if this is just how Microsoft designed it, or if clicking the labels just preempts the "lasso" process. Initially there is not a visible lasso, but one does appear after a box is clicked. That is because I had the DOUBLEBUFFER mode wait until it's necessary, and it changes how the lasso appears... whereas how it would otherwise appear is as a dotted line, that I long ago made to not be shown in SOM's tools, because I think it doesn't match their artistic styling...

In addition to this, you can hold Ctrl down and click names to select them. And also hold Shift or Ctrl+Shift to get other behaviors. And I made it so if you hold Ctrl while clicking a box, it will not pop up the input box, but instead will just select that item, as it would always do if you selected the label and then used the keyboard to navigate into the columns.

Because I spent so many days working on these two tables, I want to say (as boring as this might be) they are the main contribution provided by this release. It was because they disrupted my work so, that I began to feel like this was going to be a two part release one way or another, or that it would end up some kind of never ending mega release. When the "sinister bug" appeared, I decided to use it as a natural closing point for the first half of this combined effort.

AND LAST BUT NOT LEAST I want to speak on the much less pedestrian element of this release, that was its genesis. I do so want to. But I feel like, I want to make it a separate post. And that it might have to wait until tomorrow. Well, the details can wait. But what it amounts to is a big overhaul of SOM_PRM's item screen. There are new features, and things like all items can be assigned a weight (and down to 1g) and equipment now has a lot more pages to fill out with KF's 3+5 figures sets of hit-points...

Unfortunately, while these things can be filled out with SOM_PRM, they don't do anything yet. But this is to be a first step. The reason I did this now was twofold: For 1) I've been asked before about adding something like this, especially for Verdite's game (Moratheia) even though I'm pretty skeptical they will ever find enough time to devote to it. 2) One reason I've been dismissive of working on this kind of thing, is I just couldn't see a path forward. But it was after the previous release, that I became flooded with ideas that all seemed very appropriate to me. So on some level, I'm excited to be able to make progress in this direction. I wanted to strike when the iron was hot. Of course, the previous release paved the path that made it all possible, by its having done all of the technical work (It added Strength & Magic figures to NPCs and traps, and this release adds them to non-equipment items also. Generally speaking they've been added anywhere that it makes sense to assign items from the magic table, similar to how sword-magic is assigned to weapons. Except in that case Strength & Magic is not required, as they come from the hero.)

Holey Moley · « **Reply #3 on:** March 19, 2018, 09:11:10 AM »

*There are also two new extensions for changing the color of text in the tools: http://en.swordofmoonlight.org/wiki/SomEx/list_of_extensions#black_saturation & #white_saturation that I added in case there is too much contrast for some.

*When Window's taskbar groups icons together, the group should be called "Sword of Moonlight" now, but I'm uncertain why this wasn't always the case, except that Microsoft keeps changing how these things work, and I just noticed that yesterday the descriptions in the EXE version data was being used instead... or that of the first window in the group's program. I've yet to test this with versions of Windows prior to version 10.

I only added these things yesterday, just prior to putting the release up.

This release depends on the English language package, which must be updated. There are archives listed here (www.swordofmoonlight.net/text/) now. Unfortunately, I've never gotten around to coming up with a more convenient system for managing language package updates automatically. I've made plans before, but have yet to enact any of them.

Holey Moley · « **Reply #4 on:** March 20, 2018, 04:51:17 AM »

This is an image from the following link/topic/thread.

http://www.swordofmoonlight.net/bbs2/index.php?topic=276.0

It was taken during development, but appears very close to the final thing. You can see that new buttons are more red, as explained in prior posts. (They are no longer this way, as of this release.)

When I began work on this release, it was these changes that I had in my mind. Still, I did intend to explore some other matters. But this is the starting point.

What's new is worn equipment can now have a destructive aspect. Not like "durability" but like in case you were able to use the equipment as a weapon. Which in some situations, is obviously desirable, and in others, less obvious, and in others still, likely completely useless. Still, all equipment has equal access to this functionality, so to not further complicate matters.

Originally weapons were to have a defensive aspect in order to be symmetric. However, because there are only so many bytes in the PRM files, and changing their format is undesirable, I decided to make a trade-off. In the end what "character" SOM has is a function of its conscious trade-offs. Still, trade-offs don't mean that SOM is limited to what is suggested by the default/basic experience. And what is featured by default is itself a trade-off.

The worn equipment can also be used as a shield. I call this active-defense; as opposed to passive-defense. Basically, what it means, is that the audience must actively put the equipment between themselves and harm's way...

Weapons have this quality, but do not enjoy passive-defense. IOW, they're contribution is considered to be negligible. However, it's not impossible to make some weapons act like worn equipment in this regard, but in order to do so, they would have to make the same trade-offs worn equipment does.

That is, in return for relinquishing their passive-defense, weapons gain two additional hit modes, for a total of four. Whereas worn equipment is limited to just two modes.

A "hit mode" means that the equipment can have different variables in terms of the 3+5 physical/magical elements, or however a game chooses to interpret the 8 figures. In order to infuse SOM with more character, the set of 3 elements are given different treatment from the set of 5...

That is, the hit modes cannot differ in terms of the 5. And there is a special ability similar to giving bonus Strength/Magic that can only give to the 5, but not the 3. However they can differ in terms of their "sword magic" ability. Not shown here is bow & arrow weapons, which will use the "sword magic" box to assign arrows to their attacks, and so will not have sword magic.

In total there are four screens of these dual 3+5 figures. However the first and last screen share the passive-defense field, so there is really 3.5, and weapons do not have passive-defense, and worn equipment have only 2 hit modes, so that there is really only 3. Plus the extra attacks and bonuses disable a number of the boxes. Still, there are a lot more variables to fill out.

In addition, all items can be assigned a weight, now down to 1 gram. And all items can be assigned a magic effect from the magic screen. For equipment the effect functions like the second sword magic in KF2 or some of its odd equipment. As for items, the idea is to associate a visible effect with the items, and also this can be used like destructive magic in a bottle.

I scrambled to finish these new additions, just so SOM_PRM works. They do not yet do anything, although, it should be trivial to implement something like associating magic with items. I just didn't work on it. (I know how to do it. Or at least I do since a few releases ago.)

My intention for now is to complete these expansions in stages. The first stage is to be able to input values for the new variables. And subsequent stages will be to show the values in the game menu, and to add the features to the player. In a few case that is straightforward, but for weight and "hit modes" it's less clear how to proceed. They are to some degree optional.

Weight is going to play a much more important role for weapons. Maybe it's appropriate that it's been moved up to below the profile box, but to be honest, it's there because there was no room elsewhere. I'm going to make it so it is the weight that fully determines how fast a weapon swings and recovers itself. Or weight WRT strength. The recovery function will eventually be made optional as well. And once everything is in place, it will probably be off by default.

I have no plans for how to use the additional "hit modes" but I intend to use F8 to change hit modes so that at least they can be tried out, since SOM_PRM doesn't show swing animations. The PRF files have to be changed to describe multiple hit modes. And SOM_MAP will need to be used to change the hit mode... or IOW they will depend on event programming. (It might be possible to use extensions to describe a multi-hit-mode model, but if so, only time will tell. In the meantime I have no ideas.)

As this line of work develops there will be new capabilities added to the event programming model in order to facilitate developing multi-hit events. Until complete, these extra settings are limited to the English/Neutral.zip language package.

EDITED: I keep calling these "hit modes" but that is just because that's what the language package in the screenshot says. The built-in English translation will probably call it Attack Mode when pressing F8. And the [Damage] section of the Ex.ini file may already have a meaning for hit_mode. I struggle with what to call any of this stuff myself. Most video game jargon doesn't translate into spoken English.

Holey Moley · « **Reply #5 on:** March 23, 2018, 03:58:46 AM »

Patch

I broke some of the custom highlighting in SOM_MAIN and SOM_EDIT
s tools when I worked on those inventory tables that this patch addresses.

P.S. I've been having a minor crisis about what to call the Juma-no-Hari item from KF2. I finally settled on "Magic Vessel" for it. And have been updating the English/Default.zip language pack furiously the last so many days. (This is the item that temporarily increases magic power. It's name doesn't translate into English easily. You just have to make something up that feels alright.)

P.P.S. Yesterday I had a bad experience standing at certain points in the Moratheia 2.1 demo. I thought there was a bug in the Brightness settings. But it turned out to be because I'd changed my newer Samsung monitor to Gamma Mode 2 that I never used before, and whatever the heck it does, it can lose its mind, even with a static image. The weirdest thing was when I found the perfect spot where the strobe effect happens, and I took a screenshot, and it was able to reproduce the effect by itself! (It's a shame because I liked Mode 2 as a compromise. I'd been using 3 but it was too dark for Moratheia, so I used 1--or off?--for a long time, but then decided I'd settle on middle ground... but anyway, some new crazy monitor shit to be weary of.)

Holey Moley · « **Reply #6 on:** March 23, 2018, 09:56:46 AM »

Patch

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

This fixes the grouping outline when SOM_PRM's magics change from offensive to defensive. (I had to do work on these outlines to handle the new equipment tab changes, and there was old code that did a heavy-handed wipe of the background that is no longer necessary and actually making the outline go away. It also streamlines its text replacements with a new technique developed during this release.)

Holey Moley · « **Reply #7 on:** March 27, 2018, 07:32:43 PM »

Unrelated Patch

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

I noticed the script editor's brightness slider (on the hue set up screen) was glitched. (It was refreshing the entire desktop, which is what happens if 0 is given to a certain Windows API.) What had happened is it used the same ID as SOM_MAP's new overlay opacity slider, which I guess I failed to isolate.

ALSO I got an idea to make double-clicking the walk/dash/turn speed sliders default to values that I'm trying to make standard (based on human averages) whereas it normally puts a slider in its 0 position (which is sometimes in the middle) and while adding this, I noticed the walk/dash sliders actually have a bug owing to the text boxes and sliders having different ideas about how each other work...

So I had to fix this bug (a blame it on From Software bug) at the same time. It's a small thing, but basically the sliders did not show the right position until they are dragged, and the boxes would get stuck, and oddly, seemed to only move at whole number increments. But it could've been a function of being stuck.

SO all in all a script editor fix, a legacy bug fix, and a new sliders defaults feature. (I think the New Project Ex.ini file actually overrides these sliders, so that they don't appear to change anything. I've worried about this for a while. And wondered if there is anything that can be done. Not that this helps it. It is really just made almost pointless. I also tried out a reset button, but felt it didn't fit into the layout.)

EDITED: For the record, the first version of this patch, about 3 days ago, messes up SOM_MAP's 3D sliders. There's a new download up now. (It assigned the slider position and text box number to the other and vice versa.)

Holey Moley · « **Reply #8 on:** April 20, 2018, 05:58:21 PM »

Unrelated Patch

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

This fixes some (apparently) unfinished business from way back when a wraparound feature was added to the item menus, wherein (somehow) I neglected to ensure the that 3D model is refreshed... I remember working on something like this, but I seem to recall it was related to the map items or something like that, and I still have no idea how I didn't notice this being a problem at the time.... it's possible I knocked out some code that's absence made it necessary to do this manually.

ALSO INCLUDED is a fix for the new mapcomp feature, that makes it possible to set the lighting/hiding options on a one-off basis. I did a quick fix to replace these settings when the MAP file is being read, and for some reason it didn't always end up on the right line in the file... and so missed them. I believe it can only be off by 1 line, and so the fix, though I don't quite understand it, should hold together for the time being.

There's also a minor fix for differentiating the title bar when setting up the "dead body" objects in SOM_MAP. Hardly worth mention.

Holey Moley · « **Reply #9 on:** April 27, 2018, 04:18:04 PM »

Yesterday I had a reason to boot up the test computer I use for testing features with Windows XP and Windows 7's Classic Mode...

While I was there I tested some of the features from the last few months.

Lately it's been inconvenient to do tests. I assumed that there would not be issues, but AS IT TURNS OUT there are issues all across the board... basically nothing works properly... it's enough to make me want to cry.

Windows 7 is not even old. And I don't think the problems there are limited to Classic Mode. The player won't even start! And the new MPX compiling features added to SOM_MAP are completely out of order.

It's hard to do tests, because the computer is very underpowered, and ever time I turn it off or reboot it wants to install 100 updates... the main reason I've been avoiding it is I reinstalled everything on it when I got my new workstation, and I've only now seem to have gotten it to dual boot without wiping out the boot-record.

I'm going to have to do a thorough review. So that's going to slow down any plans I had for the coming weeks. It's scary how everything can work on my Windows 10 system, and completely not work on other, older, or weaker systems... usually that's because things shouldn't work, but just happen to. These reviews always turn up good finds. Which is why I continue to support XP.

Holey Moley · « **Reply #10 on:** April 29, 2018, 11:22:13 PM »

IMPORTANT PATCH

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

The problem per Reply#9 was SOM_MAP's map number was not 0-terminated, so that it appeared to be junk after the second digit. I didn't notice the problem until now, either because on Windows 10 the buffer was filled with 0s initially, or because I neglected to test it with a SOM file that didn't explicitly provide the map number. Also my shortcuts usually provide map on the command-line.

The reason that the player had failed to work, is it didn't know which map to use... or worse, tried to use a bogus (nonexistent) map file's name.

Windows XP was still exhibiting problems with SOM_PRM and SOM_SYS's inventor lists. I was able to fix the problem, but am sad to report that XP can't really use the new multi-row selection feature. It can kind of use it if you hold down the Control key and blind navigate, pressing Enter to see which cell you are on, however, I'm uncertain where said navigation begins (maybe the top) and obviously it's impractical. (The underlying problem is that XP clears the selection when clicking in the number input columns. It would not be simple to fix, and so being Windows XP, I'm inclined to let it go.)

Holey Moley · « **Reply #11 on:** May 01, 2018, 07:06:14 PM »

SOM_PRM patch

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

Fixes crash on selecting a separator among the enemy profile selection.

Fixes untranslated attack descriptions. Like the mantis's. (A procedure had been returning the smaller/compressed size of the the translated PRF file, instead of its original/uncompressed size. While working on the new tools I kept thinking that I didn't include the entire PRFs in the data packs... but it was actually this bug the whole time. Thankfully it truly affected one monster ... and I noticed it.)

(edited 2.5hrs later: For the record, the patch is replaced to restore the do_stipple extension.)

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Spinning plates!

Author Topic: EXIT: Spinning plates! (Read 9563 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,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Spinning plates!

Author Topic: EXIT: Spinning plates! (Read 9563 times)

Sword of Moonlight|

Devs|

EXIT: Spinning plates!