Release Xiyue MapEditor - Akaras' mod updated by M2P

Breezer

Mr Mañana
Legendary
Jul 16, 2004
3,370
539
315
Scrollers are essential, and at most I would offer a keybind + mouse drag to alter location in areas you want to pan across... Like dragging your view port across a path (diagonal transform), Scrollers / keybinds you have to go up left up left etc.

Dragging is the way to go as seen across board.

Don't go backwards :)
 

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
Laptop argument is not too strong as I see it, nobody can be seriously working with maps on a laptop, scroll bar or no scroll bar. At minimum I'd hook up standard keyboard & mouse to laptop if I was doing that.

On second thought now, I could map arrow keys to WASD movement, maybe assigning to them much less smaller jumps so they would scroll almost smoothly at full size map view. But I know that doesn't invalidate the argument that scroll bars tell you what map area you are in but only that one about laptops not having NumPad.

I wonder if Akaras could make scroll bars to hide if you don't want them but from what I know how they were implemented, I seriously doubt that would be possible - would need to be able to show/hide 'tab pane' panels into which scroll bars are placed, otherwise hiding scroll bars would leave black stripes where they were as in the first pic here, in the second the panels were removed. I'd wait for his opinion anyway before returning to scroll bar version and replicating the changes I made after that (really weren't that many) .
1640642820152.png 1640642897851.png

The edge tile issue I admit is a perfectionist side of myself more than some practical issue. But scroll bars do narrow map view and you can't ever get enough of it.

On the other hand, it is your perfectionist side when it comes to code. Yes, I realize well that only one code section could be made to make the various 'MiniMap' sizes.
But then I'd have to be able to write code. I only learned to read the code to some extent and got some overall idea how it can be changed and how different sections tie together (references) but writing it is quite another thing. That is similar to understanding and writing foreign language. Like I passably read and even understand spoken French but when it comes to writing it, I am almost illiterate.

Replicating that MiniMap code three times doesn't hurt anything, functionally that is (all else being equal, as they say). Also, I knew well that '/ 1' doesn't need to be there but left it there intentionally after some reflection. I like to leave things unchanged as much as possible in their original state and only tack on additions. Also I was changing the divisor values many times while figuring out what sizes would be practical and how many of them and having this left in helped to spot the lines where that was done in those four sections.

BTW I put 'm2p' comments on most additions I make but I hope that is not seen as some silly authorship mark up, it is meant as a red flag telling others to treat those additions with suspicion if the code would need troubleshooting.
It also marks places where coding improvements might be made. It is possible that when Akaras next looks at the code, he might consolidate those three extra copies of MiniMap code into one. Or I might do it in some months' time if I return to coding courses (and not skip homework code writing assignments)
 
Last edited:

Far

tsniffer
Staff member
Developer
May 19, 2003
20,172
30
2,767
540
Replicating that MiniMap code three times doesn't hurt anything, functionally that is (all else being equal, as they say). Also, I knew well that '/ 1' doesn't need to be there but left it there intentionally after some reflection. I like to leave things unchanged as much as possible in their original state and only tack on additions. Also I was changing the divisor values many times while figuring out what sizes would be practical and how many of them and having this left in helped to spot the lines where that was done in those four sections.

It doesn't hurt functionality, but it greatly hurts maintainability of the code.

I appreciate you don't know how to code yet - but thinking that kind of copy and pasting is okay is not how you'll learn.

Feel free to make as many help threads as you want in the persuit to learn.

In regards to the scrollbars - i honestly think they're required. Even if you don't personally have a use of them, they're a basic UI tool for moving around. Keybinds should be a secondary to usability, not a requirement.
 
  • Like
Reactions: mir2pion and Alecs

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
I throw in an idea, how about a MiniMap panel display in Map Editor like the one there is in Client. And it could be a bit bigger and show whole map, so it wouldn't scroll about as you move around map.

Or popping up panel like Bigmap in Client... I don't think I could do it but the code for it could be taken from the Client and adjusted for Map Editor use. Ideally it would be a MiniMap panel optionally opened in upper right corner, it would show the whole map and the map would have a moving frame overlay that would enclose the area currently displayed in the Map Editor pane. Or just a dot showing the center of the map view on your screen. Or maybe it could even display a smaller scrolling area of the MiniMap, like it is in Client.
 
Last edited:

Far

tsniffer
Staff member
Developer
May 19, 2003
20,172
30
2,767
540
What's your big hatred against a simple reliant scroll bar?

If it's that much of an issue for you I'll write you abit of code to hide it with a keybind.
 

Breezer

Mr Mañana
Legendary
Jul 16, 2004
3,370
539
315
Yeh I'll say it again, keybind + mouse drag AND scrollers.

Or is that too advanced for the Mir Community. I mean its useless to me I'm just throwing out hints, maybe you'll guys come close to my capabilities
 

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
I put the Scroll Bars back, no need to get Akaras involved. And while I was at it, I added those arrow keys to move map by five tiles each press.

If you could do that, it would be useful also for that NoMenu Editor bonus version. That way I wouldn't have to comment out all that scroll bar code for it with every new release (all the other changes I make in that are a few minutes job).

Actually if that button menu could also be hidden somehow without needing intervention in winforms to make it invisible as I do that for the NoMenu edition, that would be icing on the cake.
In that case I wouldn't need to make any NoMenu edition. Tab menu could be vertical on left side and the menu with scrollbars pple could show or hide them.
 
Last edited:

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
Re-worked release #3

Most of the details of this release are posted above on page 3, post #57
Here only the added changes are listed.

Scroll Bars are now back, some additional features were put in

1640898901494.png

- arrow keys now 'scroll' map, each key press jumps by five tiles
- Libraries Tabs now have tighter Tile spacing (thx to Far's help)

1640898633401.png

- Tab bar is now placed vertical on left side of editor window
- map Zooming In/Out steps are now more fine
- map size now practically unlimited

These last three features were moved in from NoMenu editor version. They passed some practical use test and I think they should be adopted in the standard editor edition as well. But I can reverse these changes if they are seen as too radical (vertical Tab bar?), same as I did with the Scroll Bars.

Download link in the OP is also updated.

Release #3 - Mir2 Map Editor v.1.2 [Master & Binary 2021_12_26]
 
Last edited:

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
Thx ✨

---
When the Cell Info panel is open and you inspect cells at extreme right of your screen view, the info panel flips to left to still be visible. But is doesn't flip up at screen bottom (it slides down beyond view). Is that implemented in some setting in winform properties or is that done as I suspect in code?
-----------------------------------------------

The error panel 'Unhandled Exception...' is that a general Windows panel or is it a panel specific to the editor? I don't see it in the code, in winforms.

Reason I ask is that when it pops up during libraries browsing and you have some unsaved work on the map tab, you can click on the 'Continue' button to display library tiles one by one until you fill the current window with them - at which point it allows you to switch to the map Tab and Save your work (else you click the Quit button on the panel and the editor closes without saving).

Now that we have that tighter libraries tiles display, it makes the clicking on the Continue button potentially much onerous task since there can be much many more tiles that needs to be displayed, you get the idea.
1641066901741.png
The solution could be to edit that panel to make the 'Continue' button the default one. Then you would just hold down Enter key to place all library images and dismiss the panel to allow you to Save your map work if needed.
 
Last edited:

Far

tsniffer
Staff member
Developer
May 19, 2003
20,172
30
2,767
540
Grasping all 3 layers at once wouldn't be easy. The back layer (tile layer) only has an image on 1/4 tiles, those which are even X and even Y. So if you were grasping the back and middle/front layers every 3/4 coords you tried to place the images on would either mean the back layer couldn't be placed, or it would need to be moved out of position from the other layers to place.

Theres no reason I can think of you'd want to grasp all layers really - perhaps for deleting all 3 layers at once. Objects should only ever be on the middle/front layers, and tiles on the back layer.
 

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
Thanks for input, luckily after some more labor last night, I got results.

The code for grasping back tiles is there in the grasping method (it was there in the original Xiyue code) but BackIndex was set to zero (disabled) as you see here.
1641858640715.png

- in past, when selecting a large area around an object I wanted to move around on the map, sometime when placing it, it would put some 'garbage' tiles on the map along with the object. By garbage I mean random tiles totally unrelated to the current map. Whenever that happened, I either went back and made a smaller selection (only big enough to just include the tags of the object) or I deleted those extra tiles (but that could mess up other objects on same layer).
I now suspect this 'halfway disabled' code is what was messing things up, especially when making a larger, more 'liberal' selection than what was actually needed. But I will have to go back to do some map work to see if this won't be happening when the code is commented out. It is not some easily replicated flaw that always crops up.


I enabled the BackIndex line (replaced the 0 with M2CellInfo[x, y].BackIndex) and after some trials, I found it grasps back layer if that hex number 0x20000000 is replaced with 0x1FFFFFFF (!). These two hex numbers are used in various places in code in association with BackImage. I tried to google them but found no sensible explanation, likely their use here is mir specific, to do with Back tile libraries or something like that.



However there is an odd thing about this. As you said about BigTiles being special, I believe I know all about that, at least how it works on maps, in code it is a different matter.
The odd thing is, when I grasp a map area using either method, F or F&M layers (making sure I start the selection on even coordinates and end it on odd ones to capture all big tiles and so get predictable result on pasting) it places all three layers on map but ONLY if the mouse click is on (x-odd#, y-even#) coordinates (that is, in upper right quadrant of the big tile) when placing the object. It seems to depend on which coordinates the original selection ended, this determines where one needs to click to successfully place the copied object (so that the back layer is included). Normally I start the selection on both even coordinates and end it on both odd ones.
1641870859674.png Here I deleted trees to make place for copied bridge head.

Normally I would expect the 'placement mouse click' would need to be on even coordinates for successful (and predictable) object placing, since that is where the back tile 'tags' are (the tagged SmTile area, one of the four that make up (Big)Tile). That is also how it works when placing saved Objects.X on map (more on that bellow).

I think it doesn't need any fix, just figuring out exactly the rules for selection and placement as to odd/even coordinates. It seems to work 'as intended'.

=====================

Before you start to protest, I know that we don't want to include back layer with the two current grasping methods. I would only include it if I manage to work in a third grasping method for all three layers. That is easy to do inside this grasping method, just adding another
'if (layer == Layer.GraspingFrontMiddleBack)' and include back layer in it. But I still don't quite understand how that special EditorLayer menu works, if I would be able to add another selection into it (GraspingFrontMiddleBack).

The objection that such third grasping method is not needed, what use it might be... I admit it will have a rather limited use but in those few cases where it comes handy, it will pay off big time in labor saving. I might before long show off some map work that relied heavily on grasping all three layers. As it was, I had to run all of it through saving as Object.X, then loading those back to put on map. A rather roundabout, lengthy way. That is why I was looking for a direct copy/paste method.

I suppose you know that when saving a selection as Object.X, it always saves all three layers. In past, I used that to advantage (since grasping all layers and directly placing back on map wasn't available) but for saving out objects from maps for later use, it is a hindrance. To grasp an object on existing maps and not include back layer with it, you need to close the map, make new blank map and place the object on it, remove back layer by patiently clicking tile by tile (luckily now we can delete delete selected area on any layer separately) then select it and save it as Object.X

An alternative way to save the object without back tiles is to first delete back layer, then select the object and save it as Object.X
The messed up map can then be closed without saving.

There is a way to place Object.X on map without including back tiles that were saved with it - when mouse click that places the object on map is on tile with at least one coordinate odd #, it doesn't place back tiles. Shortcoming is that you can't always place object precisely where you might have wanted it to be. On the other hand, if you want to include back tiles originally saved with the object, you need to place it (mouse click) on both even coordinates.

I plan to exclude saving back layer with Objects.X and make saving it an option. I think that would make it easier to use.
 

Attachments

  • 1641858400417.png
    1641858400417.png
    8.6 KB · Views: 9
  • 1641864914488.png
    1641864914488.png
    52.5 KB · Views: 8
Last edited:

DevilsKnight

I
VIP
Aug 1, 2004
1,612
46
195
I enabled the BackIndex line (replaced the 0 with M2CellInfo[x, y].BackIndex) and after some trials, I found it grasps back layer if that hex number 0x20000000 is replaced with 0x1FFFFFFF (!). These two hex numbers are used in various places in code in association with BackImage.

These are used for setting back limits.

Sent from my SM-G950F using Tapatalk
 
  • Like
Reactions: mir2pion

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
Interesting, I would need to re-test it but I think that with 0x2... in, it didn't place any back tiles, same without it. With 0x7... it works. Go figure

Actually on second thought, I just tried grasping to place the object directly back on the map and it does include Front Limit but not Back one. Back Limit would be the 0x20000000 number. I think now that when I didn't include any hex code with back layer, I didn't know yet how to place selection back on map for the back layer to show up, I must have been misled into thinking these hex numbers have anything to do with catching back layer in the grasp.

After some testing with these hex numbers, the solution is to leave them out altogether. Then both limits are included in the grasped object as they exist on map. Thanks DK, the info that those numbers have to do with limits put altogether new light on this devious problem. :geek:

Here is the whole code with the included but not yet tested 'else if' section for all three layer grasping.
C#:
        private void GraspingData()
        {
            if (p1.IsEmpty || p2.IsEmpty) return;
            if ((layer == Layer.GraspingMir2Front) || (layer == Layer.GraspingInvertMir3FrontMiddle) || (layer == Layer.GraspingFrontMiddleBack))
            {
                if (M2CellInfo != null)
                {
                    var w = Math.Abs(p2.X - p1.X + 1);
                    var h = Math.Abs(p2.Y - p1.Y + 1);
                    objectDatas = new CellInfoData[w*h];
                    var z = 0;
                    for (int x = p1.X, i = 0; x <= p2.X; x++, i++)
                    {
                        for (int y = p1.Y, j = 0; y <= p2.Y; y++, j++)
                        {
                            objectDatas[z] = new CellInfoData();
                            objectDatas[z].CellInfo = new CellInfo();
                            objectDatas[z].X = x - p1.X - 1;
                            objectDatas[z].Y = y - p2.Y - 1;

                            if (layer == Layer.GraspingMir2Front)
                            {
                                objectDatas[z].CellInfo.MiddleImage = 0;
                                objectDatas[z].CellInfo.MiddleIndex = 0;
                                objectDatas[z].CellInfo.MiddleAnimationFrame = 0;
                                objectDatas[z].CellInfo.MiddleAnimationTick = 0;
                            }
                            else if (layer == Layer.GraspingInvertMir3FrontMiddle)
                            {
                                objectDatas[z].CellInfo.MiddleImage = M2CellInfo[x, y].MiddleImage;
                                objectDatas[z].CellInfo.MiddleIndex = M2CellInfo[x, y].MiddleIndex;
                                objectDatas[z].CellInfo.MiddleAnimationFrame = M2CellInfo[x, y].MiddleAnimationFrame;
                                objectDatas[z].CellInfo.MiddleAnimationTick = M2CellInfo[x, y].MiddleAnimationTick;
                            }
                            else if (layer == Layer.GraspingFrontMiddleBack)
                            {
                                objectDatas[z].CellInfo.BackImage = M2CellInfo[x, y].BackImage;
                                objectDatas[z].CellInfo.BackIndex = M2CellInfo[x, y].BackIndex;
                                objectDatas[z].CellInfo.MiddleImage = M2CellInfo[x, y].MiddleImage;
                                objectDatas[z].CellInfo.MiddleIndex = M2CellInfo[x, y].MiddleIndex;
                                objectDatas[z].CellInfo.MiddleAnimationFrame = M2CellInfo[x, y].MiddleAnimationFrame;
                                objectDatas[z].CellInfo.MiddleAnimationTick = M2CellInfo[x, y].MiddleAnimationTick;
                            }
                            objectDatas[z].CellInfo.FrontImage = M2CellInfo[x, y].FrontImage;
                            objectDatas[z].CellInfo.FrontIndex = M2CellInfo[x, y].FrontIndex;
                            objectDatas[z].CellInfo.FrontAnimationFrame = M2CellInfo[x, y].FrontAnimationFrame;
                            objectDatas[z].CellInfo.FrontAnimationTick = M2CellInfo[x, y].FrontAnimationTick;
                            objectDatas[z].CellInfo.DoorIndex = M2CellInfo[x, y].DoorIndex;
                            objectDatas[z].CellInfo.DoorOffset = M2CellInfo[x, y].DoorOffset;
                            objectDatas[z].CellInfo.TileAnimationImage = M2CellInfo[x, y].TileAnimationImage;
                            objectDatas[z].CellInfo.TileAnimationFrames = M2CellInfo[x, y].TileAnimationFrames;
                            objectDatas[z].CellInfo.TileAnimationOffset = M2CellInfo[x, y].TileAnimationOffset;
                            objectDatas[z].CellInfo.Light = M2CellInfo[x, y].Light;
                            objectDatas[z].CellInfo.FishingCell = M2CellInfo[x, y].FishingCell;
                            z++;
                        }
                    }
                }
            }
        }

In this screen I show off the new BigTile size Grid, each rectangle contains 4 cells (SmTiles).
Those little orange squares is where the mouse click was when starting selection, x y both even #. Then down on left the square shows where the mouse click was for back tiles to be placed, @323:84 coordinates. The little circle marks the tile where I would expect to click to place the object.
1641885989152.png

Also made the square and circle markers right under the selection rectangle. The rectangle marks the place where mouse cursor must click for the image to be placed right back on the selection, the circle marks the mouse click position I would expect to click (but in that case, the back tile would not be placed and front layer tiles would be displaced.

Ideally the grasped image at mouse cursor would be shown to right and down from it and you would click in the same place on map where you started to drag the selection rectangle. But even bigger size (or maybe all of them?) Objects.X show up for placing on map at mouse tip to right and up. But at least with Objects.X you know that big Tiles get placed if you click on even coordinates (provided they were saved with the object in the first place).

Also what doesn't help is that grasped object when at mouse cursor, before you place it on map, doesn't show Back tile layer, and you need to click in the upper right quadrangle of Tile grid for Back layer to be placed (provided you started selection on even coordinates as I show here). But in few tries I guess you will figure it out as long as you know that the back layer tiles are there available to be placed.

This is what the above grasped object looks like before being placed on map, I moved it over sandy area so as not get confused by existing grassy area.
1641887819921.png

Those three grass Tiles below the boulder show because the map has some booboo there. I noticed in in several places that cell info shows Back Tile Info not just on the upper left quadrangle but the same info in all four which is weird. Normally you see Tile info only where the big Tile 'tag' is, for example where you need to click to delete the tile - big Tiles don't have tags but that's where they would be if we had them (we don't really need them, so we don't have them LOL).

The orange rectangles show where mouse cursor was for each Tile quadrant. This seems to be rather common on the later issue of Bichon map (the one that has the bridge near WWoods entrance).
1641889478423.png
 
Last edited:

Far

tsniffer
Staff member
Developer
May 19, 2003
20,172
30
2,767
540
I'd be very careful randomly copying and pasting code without understanding what it's doing.

Any time you see hexacdecimal operations means they're storing and checking multiple sets of data in a single value (As DK says, in this case its storing both the image value and the limit in a single property). But other layers also store animation data in there too depending on the map format used.

If you're just trying what doesn't break the code then you're definitely going to end up with a corrupted map.

You should fully research logic operators (shift and bitwise probably not so much for this) and how conversion between hex/binary/decimal work before change lines really.

I used this site (throughout when i wrote my mir3 map editor) for conversion between numbers

 
  • Like
Reactions: mir2pion

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
I believe I finally figured it out. Due to your warnings that things can be easily messed up, I did more testing and thinking and I believe I got it.

That back layer code that I thought was 'left in' actually enables grasping of back limit with the two grasping methods. Front limit is taken care of with the grasping of front layer simply because front layer is grasped in both grasping alternatives but the back limit is not since back layer is not being grasped.

The first line enables BackLimit inclusion in the Grasping of F or F&M (FrontLimit is included regardless).
The second line disables inclusion of BackLayer in the Grasping of F or F&M.

line1 objectDatas[z].CellInfo.BackImage = M2CellInfo[x, y].BackImage & 0x20000000;
line2 objectDatas[z].CellInfo.BackIndex = 0;


I left the code in the original state and added the provision for grasping back layer in an 'else if' statement.

This way it is completely 'clean' solution, the original code stays as it was and it works like a charm.
Currently grasping Front only is on shortcut 4, F&M on 6, placing on map is 5 and I made it Ctrl-6 to grasp all three layers
-------------------------------
Two things that could possibly improve it, one is to have the back layer included visible while at mouse tip waiting to be put on map (not essential but would be nice) and the other is to change the offset of mouse click that puts the object on map by '-1', that is, one smtile to left.

Now if you start dragging the selection rectangle from even coordinates and end on odd ones, you need to click on the tile with x odd and y even coordinate (basically one SmTile to the right of that one on which you started dragging the selection rectangle on).

With the current grasping ways, Front or both Front & Middle it didn't matter since those you can put on the map anywhere but the back layer gets put on map only if you click on certain coordinates (meaning odd/even combination).

Since we are used to place saved Objects.X on map by clicking on both even coordinates (when back layer had been saved with the object and we want it to be added on map), it would be nice to do the same when putting down on map a grasped object that has back layer included.
 
Last edited:

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
I tried to place Back or Front limits in a selected area. Currently you need to make a limit object and place it on map (blindly since it doesn't show at mouse tip) if you don't want to spend the rest of your life clicking tiles.

[...]

I believe I am on the right path with this. Maybe it doesn't work because [cellX, cellY] should be [x, y] ?

Bingo, that did it.
 
Last edited:

mir2pion

TL;DR
Veteran
Feb 21, 2013
3,091
502
175
What are the 'useful' light values?

I know that fishing light is 100-119 but what is the town light posts range? I suppose it is limited and values above the light range and below fishing are not valid choice or is there some other use of light? Maybe mining?

I suppose mining must also be set by light because I don't know about anything in map editor how it would be set. Never yet looked at mine maps from that point of view.