Forum :: EOMap :: EOMap 0.4.0 preview

Yellow,

Moving the map with the arrow keys doesn't work for me.
Re-sizing the palette sometimes makes the editor crash.
Random crashes when switching to palette and back.
The green-ish WALL tile color is too vague, sometimes hard to see on green tiles/objects. Red was a nicer color for it but that's my opinion.

Nice to see map editor updates. Thank you!

Marshe posted: (3rd Nov 2020, 09:34 pm)

Yellow,

Moving the map with the arrow keys doesn't work for me.
Re-sizing the palette sometimes makes the editor crash.
Random crashes when switching to palette and back.
The green-ish WALL tile color is too vague, sometimes hard to see on green tiles/objects. Red was a nicer color for it but that's my opinion.

Nice to see map editor updates. Thank you!

I am not sure if removing the arrow functions was intended or not. You can move around the map by holding down the scroll wheel on the mouse. I have been able to reproduce a consistent crash with the latest 4.2 and have let Sausage know to further debug what is going on there. Be cautious using this build to make or edit large maps. I would recommend you wait or use the previous build 4.1 if you have it. 

I don't believe the color of any of the tiles changed compared to the official release, so you might be talking about a third-party distribution of eomap with different graphics. I'll make sure I add a way to swap out the tile spec graphics with ones installed along-side the program, if you want to replace the ugly puke colored wall tiles.

There's an issue with resizing the map tile window(ANY change at all crashes it within 1-2 seconds). Using the current version from this thread.

---
Fallen Evolution Adminsitrator | Demi#5030

The "Save as" function appears to be broken in both 0.4.1 and 0.4.2.

Just crashes the application immediately for me.

---
Want to learn to pixel?
Pixelsource.org

Curious if Sausage has addressed any of these issues yet seeing as it has been a few weeks since the last version update.

---
Fallen Evolution Adminsitrator | Demi#5030

Trying to compile the current version from github and having an interesting time of it.

What version of physfs are you linking against, Sausage? I'm getting this "unsupported" error from PHYSFS_mountMemory at startup.

---
Want to learn to pixel?
Pixelsource.org

Cirras posted: (4th Dec 2020, 03:58 am)

Trying to compile the current version from github and having an interesting time of it.

What version of physfs are you linking against, Sausage? I'm getting this "unsupported" error from PHYSFS_mountMemory at startup.

3.0.2 -- That error is most likely due to the "builtin_data" array not being a valid zip file. You probably need to create the builtin.zip file yourself and remove the zip command from the build file. Its contents should be the contents of the "data" folder. You can also just remove the call, and it should use the data directory on disk.

The proper way to build it would be mingw-w64 on debian, or msys2 on windows with pkg-config, cmake, make, gcc and zip installed. Not sure how you'd integrate it in to an IDE on Windows. I'll look in to if I can support building on Windows better.

You can also replace it with PHYSFS_mount("./data/", nullptr, 0); to have it read the files from the data directory on disk like it did before.

Sausage posted: (4th Dec 2020, 07:30 pm)

Cirras posted: (4th Dec 2020, 03:58 am)

Trying to compile the current version from github and having an interesting time of it.

What version of physfs are you linking against, Sausage? I'm getting this "unsupported" error from PHYSFS_mountMemory at startup.

3.0.2 -- That error is most likely due to the "builtin_data" array not being a valid zip file. You probably need to create the builtin.zip file yourself and remove the zip command from the build file. Its contents should be the contents of the "data" folder. You can also just remove the call, and it should use the data directory on disk.

The proper way to build it would be mingw-w64 on debian, or msys2 on windows with pkg-config, cmake, make, gcc and zip installed. Not sure how you'd integrate it in to an IDE on Windows. I'll look in to if I can support building on Windows better.

You can also replace it with PHYSFS_mount("./data/", nullptr, 0); to have it read the files from the data directory on disk like it did before.

Already tacked in a zip equivalent for windows. The cmake custom command was running through Visual Studios without any obvious issues - looks like bin2c was just shitting itself due to opening the input file in "r" mode. It needs to be "rb" mode for the zip to be opened in binary mode on windows.

Thanks for pointing me in the right direction.

---
Want to learn to pixel?
Pixelsource.org

Cirras posted: (5th Dec 2020, 11:18 am)

Sausage posted: (4th Dec 2020, 07:30 pm)

Cirras posted: (4th Dec 2020, 03:58 am)

Trying to compile the current version from github and having an interesting time of it.

What version of physfs are you linking against, Sausage? I'm getting this "unsupported" error from PHYSFS_mountMemory at startup.

3.0.2 -- That error is most likely due to the "builtin_data" array not being a valid zip file. You probably need to create the builtin.zip file yourself and remove the zip command from the build file. Its contents should be the contents of the "data" folder. You can also just remove the call, and it should use the data directory on disk.

The proper way to build it would be mingw-w64 on debian, or msys2 on windows with pkg-config, cmake, make, gcc and zip installed. Not sure how you'd integrate it in to an IDE on Windows. I'll look in to if I can support building on Windows better.

You can also replace it with PHYSFS_mount("./data/", nullptr, 0); to have it read the files from the data directory on disk like it did before.

Already tacked in a zip equivalent for windows. The cmake custom command was running through Visual Studios without any obvious issues - looks like bin2c was just shitting itself due to opening the input file in "r" mode. It needs to be "rb" mode for the zip to be opened in binary mode on windows.

Thanks for pointing me in the right direction.

If you could post the finished edit here when done or PM it to me that'd be great.

---
Fallen Evolution Adminsitrator | Demi#5030

I updated the first post to fix all the bugs making it unusable. I thought I added RLE bitmap loading at some point but I guess Apollo will just have to cope.

There are still crash issues with the 0.4.3 build (eomap6.exe):

Reproducing a crash via opening map 00270.emf (official EO dragons map) by toggling the maximize to full screen button to full then back to windowed. A slight work around is to open a known good map (00005.emf Aeven) and then opening the problematic map immediately after. The crash will not occur, however there is a delay in rendering which seems to be trying to execute zoom out during the window resizing process. 

Wall tile rendering is still broken as it always has been. This could be fixed when extra wide wall tiles exist by altering line 257 in Map_Renderer.cpp:

current:  draw_x -= tile_w / (1 + (i == 1)) - 32;

replace: draw_x -= *check if wall layer* ? -16 : (tile_w / 2) - 32;

I didn't investigate enough to determine the ID referenced by the wall layer, however my client matched the rendering code minus necessary offset variables for things like earthquake that had to be added. This fixes oddities such as the Imperial Castle exterior map and the fire void campfire offsets. 

Sausage posted: (2nd Nov 2020, 05:30 am)

[FE]Demi posted: (1st Nov 2020, 04:00 pm)

Quick question here about the mapper. I'm not on the coding end of literally anything so I'm generally unaware of what I'm about to ask. Would it be possible to implement a world map editing mode? Essentially having sections of the exe screen where you can place maps and render them into the mapper, outside of the map being edited/created, to make more geographically accurate maps? Was always hoping to see a feature such as this get implemented into a mapping program for EO. As I said I'm just unaware of what can be done with this map program as is.

Its a very cool idea, but there's no way I would ever bother creating something like that for EO, let alone in a brushed up revision of a single-file map editor.

That would be large paradigm shift and you'd probably want everything else in the ecosystem built around the idea of one monolithic world space. You would be dynamically creating map IDs and coordinates depending on how you choose to slice up the world, which EOSERV would have no way of being able to compensate for, so effectively you'd have to create what you want, slice up the maps one time, and never be able to adjust how you sliced up the maps, because you'd risk sending players in to walls and random maps if IDs or coordinates changed around.

Maybe Demi is looking for something simpler such as clicking on a warp tile properties has the option of "Load this map in another window", it stays in the same process and shares the palette with the first window. But other than sharing the palette, each window is editing its own map with a full menu bar.

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Added EOMap 0.4.4 to the first post. If this release goes well it might be the next official version. I still need to figure out what causes issues with maximizing the window, though.

This version seems stable, although it is still missing RLE bitmap support. Looks like photoshop made images are DOA. 

Also, music control needs to be defined:

/* Music control adding */
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Interrupt Different Song, Play Once");
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Always Interrupt, Play Once");
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Finish Differnt Song, Play Once");
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Interrupt Different Song, Play Repeat");
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Always Interrupt, Play Repeat");
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Finish Song, Play Repeat");
	SendDlgItemMessage(dialog, DIALOG_MAP_PROPERTIES_MUSIC_CONTROL, CB_ADDSTRING, 0, (LPARAM)"Stop All Songs");
	/* End of music control adding */