- Feb 9, 2015
- 953
- 118
- 85
Makes me laugh seeing people implement literally 0 new maps on servers when things like this are capable of being done , no excuses
Good work
Good work
Pretty speechless if i'm honest.
- Thread starter Chalace
- Start date
- Feb 21, 2013
- 3,127
- 515
- 175
Good finding, I just assumed the object would stay on middle layer (and so didn't check on it) and the map.mir3 would then have to be opened... makes it much less laborious this way (can just leave one 'dummy' file "Invert Mir3 Layer.Mir3" in save location and overwrite it on subsequent conversion). I am very much pleased I could be of some help.
While checking on this (I believed you but I am that kind of pest
), I found (as you likely already found too) that the conversion works only one way, from mid to front layer, not in reverse as I also wrongly assumed since 'invert' suggests toggling between the two layers upon subsequent conversions. This implies (and I checked on it this time) if you have mixed - mid and front layer object, the conversion makes it all front layer.
-----------------------------
As to the cliffs, why don't you invert your whole map to *.mir3 and exactly as you found out, as soon as you confirm the save of the .mir3 map, it is converted in the editor.
I did mention it created some 'mess' inverting the whole map. I looked at it again, checking exactly what goes on, converted Bichon 0.map and found that something like five % or less of those muddy pathways which are on mid layer did not convert, stayed on mid layer. It happens in random places and I can't see any reason why just in those places (btw it happens @ the same coordinates on different conversions tries).
Mind you, if you run another conversion on converted map, these remaining mid layer muddy path tiles get replaced by tree parts or parts of some random objects but upon another conversion again, they return to mud tiles and it switches between these two upon subsequent conversions, just stay on that first or third of fifth conversion or better convert only once (I repeated the process looking if that would catch the remaining unconverted tiles).
I had misgivings about converting those muddy pathways to front layer but those turned up to be unfounded. It doesn't matter which layer they are on since they are all built by single tiles, you can't move behind them no matter which layer they are on.
Bichon map cliffs are all on front layer to begin with but 'I assume' ! the conversion faults happen only with some single tiles on middle layer, not when they are image strips on that layer, like the cliffs. Waiting to hear if my assumption holds this time around.
-------
As an afterthought, we all have noticed that mir3 maps often have some misplaced tiles, I wonder now if this conversion would fix that (like if they somehow were converted twice or an even number of times, which would create the faulting I described above, replacing some mid layer tiles by random tile strips).
Second afterthought, the above finding would seem to make the middle layer superfluous. The only advantage it has over the back layer is you can place even big tiles at any coordinate vs placing on the back layer where it works only on every second coordinate, when both are even number (because Tiles are multiples of the basic default SMTiles size).
What this means is that the middle layer could be 'fixed' to place the image strips correctly, even if such fix might interfere with the current functionality of single tile placing (which may very well be the case). In that case, a picture could be made into a map background by cutting it into strips (less laborious process than cutting into single tiles).
While checking on this (I believed you but I am that kind of pest
), I found (as you likely already found too) that the conversion works only one way, from mid to front layer, not in reverse as I also wrongly assumed since 'invert' suggests toggling between the two layers upon subsequent conversions. This implies (and I checked on it this time) if you have mixed - mid and front layer object, the conversion makes it all front layer.-----------------------------
As to the cliffs, why don't you invert your whole map to *.mir3 and exactly as you found out, as soon as you confirm the save of the .mir3 map, it is converted in the editor.
I did mention it created some 'mess' inverting the whole map. I looked at it again, checking exactly what goes on, converted Bichon 0.map and found that something like five % or less of those muddy pathways which are on mid layer did not convert, stayed on mid layer. It happens in random places and I can't see any reason why just in those places (btw it happens @ the same coordinates on different conversions tries).
Mind you, if you run another conversion on converted map, these remaining mid layer muddy path tiles get replaced by tree parts or parts of some random objects but upon another conversion again, they return to mud tiles and it switches between these two upon subsequent conversions, just stay on that first or third of fifth conversion or better convert only once (I repeated the process looking if that would catch the remaining unconverted tiles).
I had misgivings about converting those muddy pathways to front layer but those turned up to be unfounded. It doesn't matter which layer they are on since they are all built by single tiles, you can't move behind them no matter which layer they are on.
Bichon map cliffs are all on front layer to begin with but 'I assume' ! the conversion faults happen only with some single tiles on middle layer, not when they are image strips on that layer, like the cliffs. Waiting to hear if my assumption holds this time around.
-------
As an afterthought, we all have noticed that mir3 maps often have some misplaced tiles, I wonder now if this conversion would fix that (like if they somehow were converted twice or an even number of times, which would create the faulting I described above, replacing some mid layer tiles by random tile strips).
Second afterthought, the above finding would seem to make the middle layer superfluous. The only advantage it has over the back layer is you can place even big tiles at any coordinate vs placing on the back layer where it works only on every second coordinate, when both are even number (because Tiles are multiples of the basic default SMTiles size).
What this means is that the middle layer could be 'fixed' to place the image strips correctly, even if such fix might interfere with the current functionality of single tile placing (which may very well be the case). In that case, a picture could be made into a map background by cutting it into strips (less laborious process than cutting into single tiles).
Last edited:
- Jan 18, 2014
- 1,823
- 275
- 125
That would convert everything, which would mess up a lot of details.
I could have just converted the object and dropped it on of course. but it was old and I changed a lot of the structure after putting it into the map.
But it's redundant now that I know I can't use a front layer for them, as I need to be able to place objects both under and on top.
I just need to throw in some odd front tiles where needed
e.g The red circle - will need to use 3 or 4 front layer tiles to fix (I could make the rock middle but I don't want to end up having to make 2 sets of everything) Whereas, if it was all front layer I wouldn't be able to place objects on top, like the bush.
--
The SMtiles (muddy pathways) should really be the middle layer, so as to allow you to place detail objects on top of them, should you wish.
Post automatically merged:
You have to remember I've been playing with this for a couple of years now. and the others, longer.
Sure, you can pick up the editor and Akara's objects and make some fun stuff in a few hours, but you need to have the mindset to actually do it.
When I've had maps taking weeks/months to make, if you're not mentally enjoying the process it's just not going to get finished. (which has happened a few times)
Encouraging other people to try it is half the reason I post this stuff.
Last edited:
- Feb 21, 2013
- 3,127
- 515
- 175
I think that posting here feeds your own drive as well.
As to the problem you have (the red & green circles), its because you don't want to make (relatively) simple maps that avoid such conflicts, like the default maps in client. Some mappers back off when they run into such problems, others, like you and including me, try to make it, and some do make it (likely you), others like me may get stopped in their tracks and put things on hold, but not give up hopes of making it, eventually (which may also mean never). It is natural that one enjoys most going beyond what the default maps offer, but there is a limit to it, like when a challenge becomes a drag due to too much labor involved (you can do just about anything on maps if you put in enough effort, the question is only which straw will break the camel's back).
Mappers life would be so much more simple and enjoyable, if only we had an extra layer sitting on top of the front one.
As to the problem you have (the red & green circles), its because you don't want to make (relatively) simple maps that avoid such conflicts, like the default maps in client. Some mappers back off when they run into such problems, others, like you and including me, try to make it, and some do make it (likely you), others like me may get stopped in their tracks and put things on hold, but not give up hopes of making it, eventually (which may also mean never). It is natural that one enjoys most going beyond what the default maps offer, but there is a limit to it, like when a challenge becomes a drag due to too much labor involved (you can do just about anything on maps if you put in enough effort, the question is only which straw will break the camel's back).
Mappers life would be so much more simple and enjoyable, if only we had an extra layer sitting on top of the front one.
I will have to mule it over, but at the moment, I don't see the problem. I am just wondering, if your cliff promontory above is made of single tiles, then you can have it converted from middle into front layer and that bush will still sit on top of it as it should. But if its made of image strips on middle layer, then you should have a problem displaying it properly placed in the client in the first place and all other problems become mute (same for the cliffs that came up in the prior posts).
- Jan 18, 2014
- 1,823
- 275
- 125
If they were single tiles, on the front layer, I still couldn't put a bush on top. As it overlays the tile anchors. Which is why they need to be middle, so I can place detail objects on top.
Funnily enough, in-game the rocks behind look fine somehow.
So there is still some difference in the draw between editor and client.
- Jan 14, 2014
- 704
- 158
- 165
I've been messing with the code for the map editor a little bit today... and trying to change the layout so it works differently (takes much longer than I thought it would to add a few features)
hopefully the changes I make will be useful for everyone... I know some of the things "should" be improvements but maybe some things won't work as well as I hope but we will see :P
- Added a couple of buttons in a "Tool" panel that is supposed to work similar to how it would in a painting programme... So far I just added a select tool and a "nothing" tool that deselects everything (probably would become like a move around the map tool)... This tool panel would be where the tile painting tools and object placing tools would be located
- I added a properties panel that displays things relating to the tool that is currently selected from the tool panel... at the moment for example I set it to display textboxes showing cell data when you select a single cell with the select tool... but for each tool it would be different for example the tile painting tool could have a checkbox to easily show/change what layer you are painting on currently
- The Select tool is modified from the grasping feature... added a "delete all selected cells data" button as a test for the right click menu... but the plan would be to add a copy, cut, and paste option so you can select an area then quickly move or copy it to a new location (using the properties panel to only select what layers you wish to move)
- Added a right click menu item for Copying a selected area as an Object .x file
- Added a confirm dialog to the clear map button (as requested earlier in this thread)
- Hidden some of the less used buttons into a file menu (File, Edit, View)...
- Moved the Map panel so it is on the main part of the screen rather than hidden in tabs
- Added scroll bars to the map so you can quickly move to anywhere on the map (WASD and Jump are still included it just gives more options to make it easier to navigate around)
- Added a couple of shortcut keys (zoom + - ) ... will add more as I work on more tool buttons
hopefully the changes I make will be useful for everyone... I know some of the things "should" be improvements but maybe some things won't work as well as I hope but we will see :P
- Jan 18, 2014
- 1,823
- 275
- 125
...
I need to do quite a bit more work before it becomes usable again as I have disabled most of the old buttons and dropdowns so I can work on the layout... not quite sure yet how to go about improving the displaying and selecting of tiles from the menus but I'll see if I can come up with a few ideas
hopefully the changes I make will be useful for everyone... I know some of the things "should" be improvements but maybe some things won't work as well as I hope but we will see
Any of these changes would be great. no denying that.
For the displaying/selecting tiles, I don't think there is much needed, they are already numbered with images.
The ability to jump to 'x' number would suffice, as I mentioned before. right now you have to scroll through 20k images to reach your target. (this is also the main source of crashes for me)
- Baring in mind the only times you generally go through them is when you already know the index number you want.
- Feb 21, 2013
- 3,127
- 515
- 175
You are right, the tags are replaced on the front layer by whatever gets placed last and it shows around the object outline where the partly showing tiles were deleted.
In this case, if the inversion of the whole map is not an option, only option that remains is to copy sections of cliffs, place each on new map, click invert button and also save as object, then place the object back on your map over the existing middle layer cliff section which should make it easy to align, later when you are done, show middle layer tags and delete them... But you may find it easier to save out your objects like this rock outcrop, if you don't have many of such, and after whole map inversion, place them back over the inverted ones and then delete those.
That rock sorting itself out in-game is interesting. Usually it is the other way around.
- Jan 18, 2014
- 1,823
- 275
- 125
@Akaras If you can do something about this I would love you forever.
Non-resizeable list, literally impossible to know what's what, without scrolling through everything.
Non-resizeable list, literally impossible to know what's what, without scrolling through everything.
- Jan 14, 2014
- 704
- 158
- 165
I will be looking into making that whole screen work in a different way... I have a few ideas I want to try that may or may not work
- A search function? with tags assigned to objects?... so you might have tags such as sand, grass, stone linked to one object and you can filter the results to only show objects with those certain tags. (I'll make tags editable when an object is clicked so you can easily add/remove tags)
- The list menu I'll probably hide in a different tab on the objects screen (with more space to view file names) and the main part should hopefully be changed to an image list much more like how the .lib editor shows the preview list images in each file... the preview list will probably be a modified .lib file that has image previews and file names (and search tags) so when you click on an image it then loads the object file (rather than loading the object data for everything in the list each time you load up the programme)... but I will keep the filename list accessable somewhere for those times you know the object name and dont want to scroll through an image list
- As a test I might try and have an area at the bottom of the screen where the tile and objects list is displayed that is resizable so you can click things without moving from the map screen (depends how cluttered it makes the screen so I'll test see how it works)
- Feb 21, 2013
- 3,127
- 515
- 175
I believe dragging scroll bar down with mouse to the approximate tile location, instead of scrolling with mouse or clicking into scrollbar to go down page by page, allows me to reach those higher numbered tiles without overloading the program. Scrolling about eventually pops up that notice and I found if you patiently keep clicking on the Continue button, each click draws one tile and when all are drawn in your screen view, the notice goes but then it pops up at the next scroll as new tiles should come into view. Maybe it tells something to those who understand how programs work? Like a buffer overfill or something of the sort?
Is that like what iJam did in his modifed editor version? I didn't find it too useful because it made the Tiles, Objects & object.X view panel too narrow. But I like very much the idea of showing tiles/objects in a strip underneath the map view as it would allow placing tiles in sequence much easier. Resizable height wise would be just icing on the cake. Maybe make it closable or minimizing to next to nothing and leave the access to the libraries in the tab also, as both options would be handy I imagine.
Speaking of iJam's editor version, wonder if you would work some of its added features that suit your editor scheme into yours.
As to your overhaul of the selection and copy paste working on the layer you select... if that would also work on back tiles, that would be amazing.
As a suggestion, I find the Cell Info panel at the mouse tip a bit cumbersome. You need it but need to close it as soon as you have identified the tile and want to place it on map. It just gets too much in the way, can move in jerks if your mouse tip gets too close to the map edge, we all know what I am about. It could be split into two separate info panels with one showing only the coordinates plus the tile number and its location in libraries and the other panel showing the rest. Or the original panel can be left as is and the coordinates and tile info could be made into separate second Cell Info panel (items that you use often). Or even better, make it so you would see these values change in menu at top as you mouse over tiles (probably workable for coordinates only but still would come handy). If you do, don't make it iJam version where it constantly shifts all menu items position to the right of it when it goes from one to two to three digit coords.
I also dreamed of when you select Show Grid (or even without grid showing), that you would some values pertaining to tags, index number would be sufficient, so it is not cluttered (generally you know what layer or which library you are in anyway, for that can use the Info Panel). Also tags should have some colors, different for different layers while you are at it, the black lines tag marking is not easily visible under some conditions.
Can tell how great it is that changes to the editor are in the works. Maybe release it for Christmas?
Last edited:
- Jan 18, 2014
- 1,823
- 275
- 125
How you scroll doesn't really seem to matter, it's still loading every image you see into memory(you can physically watch the memory usage go up as you scroll). but yes, dragging the bar just loads less as you take large jumps. All 3 methods eventually crash. Usually when I go too fast. The same happens with the objects list occasionally when I'm going through them too fast.
Specifically, why it crashes I don't know. It's not the memory limit as a simple test just presented the error on 200k & 350k.
- Most of the time swapping to another library file and back lets you continue as though nothing happened.
- Except for the objects list error, that requires a restart, as you get the big red cross across the image window and top toolbox.
In any case, I've lived with it long enough to not really be too bothered by it, even when the error occurs, you can still save the map, etc. Would just like the jump to save time when I need specific back images.
--
I'll second the concerns for this. The main reason I stuck with this editor, above all else, is for the full-screen map window.
Simpy detaching the map window would be my preferred choice, given. So we have 2 windows to move around however we prefer.
I fully understand that other people may like the look of Ijams, and not everyone is using multi-monitor setups. however, I don't foresee any scenario in which I would give up the full-screen view. It just puts the overall view off balance. (That makes sense in my head)
- Feb 21, 2013
- 3,127
- 515
- 175
Agree, also can live with it, it is not a game breaker. Described it mainly just in case someone might know why it happens since likely it is not an uncommon fault to happen in programs.
Today tested if that "Free Memory" button would help in this case but it doesn't. Don't really know in what situation you would use it to some profit.
As to the map view, big window gives you bigger context view and the bigger the map view the better (mostly you need to work fully zoomed in). The map window could be made detachable, or the other way, the tabs would open in resizable floating panels like most graphic programs have it nowadays. But also having map in its own detached window would likely increase the map view since it wouldn't need to have the the program buttons or even menus at top, which take up quite a bit of space by themselves. I also can hook up second monitor if the editor would be able to use the increased view.
In this connection, the other day I checked out the TileCutter program which I only tinkered with once before when it was released and Chalace, correct me if I am wrong - you said you needed to cut up that small map into four pieces so it would fit into the Cutter program... is it right that if you had a multi monitor setup, like four monitors in a square configuration, you would have been able to work on that whole map without cutting it into four pieces? Or else if you had a monitor with some really huge resolution? And would it help get by without such arangement if you could zoom out from that grid to view the whole map, the grid tiles would be smaller but for selecting cuts it wouldn't really matter?
Ideally all or most buttons or menu choices that now need to be mouse clicked should be assigned a key to them. I could try to find my earlier post where I figured out a useful assignment of F keys to most essential tabs and menu choices. Once this would be in place, if somebody would want different keys assigned, I imagine that it should be fairly easy change to make in the code, right?
Good tip, goes to show the longer experience with the editor. That popup notice used to give me the creeps in my early days with the editor but before long I also found you can save just fine and relaunch the program.
Today tested if that "Free Memory" button would help in this case but it doesn't. Don't really know in what situation you would use it to some profit.
As to the map view, big window gives you bigger context view and the bigger the map view the better (mostly you need to work fully zoomed in). The map window could be made detachable, or the other way, the tabs would open in resizable floating panels like most graphic programs have it nowadays. But also having map in its own detached window would likely increase the map view since it wouldn't need to have the the program buttons or even menus at top, which take up quite a bit of space by themselves. I also can hook up second monitor if the editor would be able to use the increased view.
In this connection, the other day I checked out the TileCutter program which I only tinkered with once before when it was released and Chalace, correct me if I am wrong - you said you needed to cut up that small map into four pieces so it would fit into the Cutter program... is it right that if you had a multi monitor setup, like four monitors in a square configuration, you would have been able to work on that whole map without cutting it into four pieces? Or else if you had a monitor with some really huge resolution? And would it help get by without such arangement if you could zoom out from that grid to view the whole map, the grid tiles would be smaller but for selecting cuts it wouldn't really matter?
Ideally all or most buttons or menu choices that now need to be mouse clicked should be assigned a key to them. I could try to find my earlier post where I figured out a useful assignment of F keys to most essential tabs and menu choices. Once this would be in place, if somebody would want different keys assigned, I imagine that it should be fairly easy change to make in the code, right?
Last edited:
- Jan 18, 2014
- 1,823
- 275
- 125
Working on large maps, going through lots of different tilesets/objects, memory usage grows fast. Use this to prevent reaching the 2GB cap. Especially on my current map, I use it a lot. I'd be restarting the editor every 15 mins otherwise.
The lack of a zoom function was the issue. The limitation is a combination of your resolution and the source image size. You can only resize the app as big as your screen.
I was using a 5760*1080 setup at the time. However, the source image was 2* the height.
Sure, you could have moved the monitors around and made a 3840*2160 setup, and done it all in one go.
(I would have needed a 3rd GFX card and 4th monitor of course)
- Jan 14, 2014
- 704
- 158
- 165
I do still want to keep the map fullscreen so don't worry about that... the side bars would be resizable so shouldnt cramp up the screen but I might just stick to having the tool buttons along the top similar to how they are now (although different) I started making it as a left side panel but I don't think I need as much space as I thought and along the top seems a better place to put them
I could look at making the map a new window if you prefer that way... the idea for the tile/objects tab to be at the bottom was just something I wanted to test to see if it could be something that could work without cramping up the screen space too much but if it is on a different window they could both be full screen
the copy paste selected area I wanted to have a checkbox displayed on the menu for each layer then when you use the tool it only copies whatever layer/s are selected... yes including back layer (I would have to solve the issue of pasting backImages onto odd number cells but thats not a major issue)
for the cell info panel I agree with what you said... I used it to identify cell data and then it gets in the way when I want to edit... I liked the way I had the cell data on my map editor when I was working on it mine it was at the top of the screen and you could edit the values directly in the boxes... maybe here we could have a side bar or something that you can turn on and off when needed
thanks for the feedback on the ideas... I like to edit and test things without having a plan that is set in stone so I'll change things (hopefully for the better) as I get feedback...
I could look at making the map a new window if you prefer that way... the idea for the tile/objects tab to be at the bottom was just something I wanted to test to see if it could be something that could work without cramping up the screen space too much but if it is on a different window they could both be full screen
the copy paste selected area I wanted to have a checkbox displayed on the menu for each layer then when you use the tool it only copies whatever layer/s are selected... yes including back layer (I would have to solve the issue of pasting backImages onto odd number cells but thats not a major issue)
for the cell info panel I agree with what you said... I used it to identify cell data and then it gets in the way when I want to edit... I liked the way I had the cell data on my map editor when I was working on it mine it was at the top of the screen and you could edit the values directly in the boxes... maybe here we could have a side bar or something that you can turn on and off when needed
thanks for the feedback on the ideas... I like to edit and test things without having a plan that is set in stone so I'll change things (hopefully for the better) as I get feedback...
- Jan 18, 2014
- 1,823
- 275
- 125
I think just keybinding the current function would be the best option here. The clunkiness at present is simply down to the number of clicks & movement it takes to turn it on/off. Furthermore, your eyes are already in position from maneuvering your cursor to the cell.
Too much information is just as bad as too little, there is really no need to have it displayed all of the time.
--
In all honesty, the same can be said for most of it. the drop-down menus eat a lot of time & brainpower just for simply swapping tasks.
When you have to do it every other action it all adds up. Even a row of buttons would be better.
Last edited:
- Feb 21, 2013
- 3,127
- 515
- 175
I noticed the TileCutting program resizes its grid according to the size of loaded image and for the image bigger than your screen view, it seems to continue beyond the edge of the viewing area.
This might mean, that for large images like your map, the grid is still there beyond the viewing area and if the program had a provision to automatically select the whole grid in order to cut into single tiles, it would do so for the entire map image and save tiles including all those ones found beyond the screen view also.
The thing is, most map objects, like those you would want to cut into image strips, usually fit into view with maybe some exceptions. And those that don't fit are likely those you would want to cut into single tiles anyway, which the program I believe (or hope) can be made to do for you (courtesy of Akaras' coding magic of course).
And taking this whole automation (auto selection into single tiles) still further, I imagine it should be possible for the program during saving into library also to generate a text file with the list of tile numbers it saved them under, and ideally it would append tile row number after the tile numbers which would make the reassembly of cut up image a simple, if laborious process, but still much less laborious than when you have to figure it all by yourself.
But ideally the program would also save .map or .X files besides saving into library, saving you the task of re-assembly.
But lets focus on the editor, I totally second that having a number of buttons in place of the drop down menus. And if there were keyboard shortcuts, I would sure use those most of the time. Like biggest pitfall in this respect is the Undo/Redo which is also in right click menu but I do find myself mouse clicking the arrow buttons for some reason. Ideally it would be toggled by some keys (preferably without modifying key).
A while back, I didn't know that Smtiles is short for Smalltiles, the standard or default size map tiles. Tiles should really be called Bigtiles by this logic, because they are quadruples of Smtiles. That would explain why their placing on back layer needs to be only every other grid coordinate with the tag being restricted to even numbered coordinates. That restriction makes the back layer to only accept Tiles, default grid sized Smtiles and image strips (which are just Smtiles assemblies) can't be placed on it.
It was puzzling me because I copied a town and pasted it on new map and that transferred front and middle tiles and when I started working on grass back tiles (since those didn't copy), I found I had the edge of the grass area offset by one grid coordinate relative to the town (compared to the original town setting) and could do nothing about it short of pasting the town onto new map again, moving it by that one tile... I left it as it was but things like that could be a problem in some cases. I should have placed some grass down and only then positioned the town relative to it, not the other way around.
I am glad you (and Chalace and others) overlook when often I re-state what is obvious to you, making it look like I think you don't know...
This might mean, that for large images like your map, the grid is still there beyond the viewing area and if the program had a provision to automatically select the whole grid in order to cut into single tiles, it would do so for the entire map image and save tiles including all those ones found beyond the screen view also.
The thing is, most map objects, like those you would want to cut into image strips, usually fit into view with maybe some exceptions. And those that don't fit are likely those you would want to cut into single tiles anyway, which the program I believe (or hope) can be made to do for you (courtesy of Akaras' coding magic of course).
And taking this whole automation (auto selection into single tiles) still further, I imagine it should be possible for the program during saving into library also to generate a text file with the list of tile numbers it saved them under, and ideally it would append tile row number after the tile numbers which would make the reassembly of cut up image a simple, if laborious process, but still much less laborious than when you have to figure it all by yourself.
But ideally the program would also save .map or .X files besides saving into library, saving you the task of re-assembly.
But lets focus on the editor, I totally second that having a number of buttons in place of the drop down menus. And if there were keyboard shortcuts, I would sure use those most of the time. Like biggest pitfall in this respect is the Undo/Redo which is also in right click menu but I do find myself mouse clicking the arrow buttons for some reason. Ideally it would be toggled by some keys (preferably without modifying key).
Post automatically merged:
I feel like a kid in a candy shop with loads of money to spend, like everything is in reach.
A while back, I didn't know that Smtiles is short for Smalltiles, the standard or default size map tiles. Tiles should really be called Bigtiles by this logic, because they are quadruples of Smtiles. That would explain why their placing on back layer needs to be only every other grid coordinate with the tag being restricted to even numbered coordinates. That restriction makes the back layer to only accept Tiles, default grid sized Smtiles and image strips (which are just Smtiles assemblies) can't be placed on it.
It was puzzling me because I copied a town and pasted it on new map and that transferred front and middle tiles and when I started working on grass back tiles (since those didn't copy), I found I had the edge of the grass area offset by one grid coordinate relative to the town (compared to the original town setting) and could do nothing about it short of pasting the town onto new map again, moving it by that one tile... I left it as it was but things like that could be a problem in some cases. I should have placed some grass down and only then positioned the town relative to it, not the other way around.
I am glad you (and Chalace and others) overlook when often I re-state what is obvious to you, making it look like I think you don't know...
Last edited:
- Jan 14, 2014
- 704
- 158
- 165
In a day or two when I get a chance to mess with the files for a few hours I'll start doing what you have suggested and make a start with just updating the buttons at the top and assigning a shortcut to everything (I'll put the map panel back in its original tab for now) ... did someone say they had a previously made a post suggesting what shortcut keys to use ?
I'll try and keep it just a simple quick update rather than spending a lot of time adding features that may sound good to me but might not be as useful as I originally thought lol
I'll then release what I have and after that I'll either try and move the map to another window... or I'll work on the object screen image list (which I'm looking forward to get started on so this may be first hehe)
oh and that issue with the tilecutter... you are correct mir2pion it was originally just made to create small map objects, at the time I totally overlooked that some of the maps could be made from huge images that stretched far off the screen... it would be a fairly simple fix just to add scroll bars but I have not got around to doing it before
I remember wanting to make it save the object it had cut from the tiles as a .x file but at the time I couldn't think how exactly to set the index numbers that specify which file the newly created tile images are located (because it would be creating a custom objects.lib and may already have images saved in it that could mess up the numbering in the object) ...I could find a way to do it even if just getting the user to input the index and starting frame number of the .lib file
I'll try and keep it just a simple quick update rather than spending a lot of time adding features that may sound good to me but might not be as useful as I originally thought lol
I'll then release what I have and after that I'll either try and move the map to another window... or I'll work on the object screen image list (which I'm looking forward to get started on so this may be first hehe)
oh and that issue with the tilecutter... you are correct mir2pion it was originally just made to create small map objects, at the time I totally overlooked that some of the maps could be made from huge images that stretched far off the screen... it would be a fairly simple fix just to add scroll bars but I have not got around to doing it before
I remember wanting to make it save the object it had cut from the tiles as a .x file but at the time I couldn't think how exactly to set the index numbers that specify which file the newly created tile images are located (because it would be creating a custom objects.lib and may already have images saved in it that could mess up the numbering in the object) ...I could find a way to do it
even if just getting the user to input the index and starting frame number of the .lib file
Nice to see you working on the editor Akaras, When I used this version I had the map tab open at all times and buttons across the top (made mapping faster) F-Key or Numbers 1-0 shortcuts would be pretty decent to swap between tabs.