CaveEditor again (beta, maybe alpha)

Glad to see you back Wistil.

While I am here I would like to make a request. Can you add a map "export to file" and "import from file" feature? If so then can you also give an option of exporting either all of the map data or only data for maps 000 to 094? Being able to save mapdata directly to file without the use of a hex editor would be quite useful.

 

Just curious: Has the thermotidal nucleation implosion error adding-new-maps-but-them-not-having-backgrounds bug been addressed?
And glad to see thou returneth.

 

While I am here I would like to make a request. Can you add a map "export to file" and "import from file" feature? If so then can you also give an option of exporting either all of the map data or only data for maps 000 to 094? Being able to save mapdata directly to file without the use of a hex editor would be quite useful.

Are you talking about exporting/importing just the .exe map data or everything to a single file? Either way I can see it being useful.

Just curious: Has the thermotidal nucleation implosion error adding-new-maps-but-them-not-having-backgrounds bug been addressed?

Yes the background error is fixed. I just verified it to make sure.


It good to be back. I don't think there will be many more updates to Cave Editor before I consider it complete though. The big things I still want to incorporate are:

• Illustration display in the script editor
• Adding all exe offsets used to the config file for die-hard hackers
• Clean up the GUI some
• Add script formatting to options to config
• Add copy/paste function for map tiles
• Add Import/Export maps
• Finish assembler part of NPC editor

With carrotlord's assembler (which is an amazing feat) CE doesn't need to reproduce that feature.

Other than that it's just bug fixes. I need to work some on actual modding myself so I can use this editor I've made!

 

Are you talking about exporting/importing just the .exe map data or everything to a single file? Either way I can see it being useful.

Just the exe map data. It is useful because exporting map data is a requirement for porting mods to other formats such as mac, gp2x, linux and psp. Exporting map data with CE might make the process a little more straightforward to the average user, not to mention faster. Plus using a hex editor to do so every time becomes irritating after a while.

I don't know about everyone else but simply being able to click "Export Map Data" to get a map data file would be something I would find highly useful.

 

Cave editor might start needing an "advanced options" button

 

Two words: keyboard shortcuts.

Ctrl+S to save changes, PgUp/Down to change map and similar.

That would make my life a bit easier.

Also, can I request a bigger font in script editor? On my 22', 1680x1050 reading whole lot of not-that-big letters makes my tired quickly. So, please, think about it

Great tool, by the way

 

There already is a quicksave feature for maps. As for font size, if you hold CTRL and scroll with the mouse wheel, the text magically enlarges, so hurray problem solved, unless you don't have a mouse with a wheel in which case that's too bad.

 

There already is a quicksave feature for maps.

Quicksave for script would be useful too.

As for font size, if you hold CTRL and scroll with the mouse wheel, the text magically enlarges, so hurray problem solved

Oh

 

there's a save button in the script editing window, not sure how much quicker you can make that.

 

I don't know about everyone else but simply being able to click "Export Map Data" to get a map data file would be something I would find highly useful.

That'll be simple. I can add that for this next update.

Two words: keyboard shortcuts.

Ctrl+S to save changes, PgUp/Down to change map and similar.

Ctrl+S does save changes in the map editor now and the scrpt editor next release. Any menu item that has a shortcut listed next to it is set already. The PgUp/Down thing sounds interesting. I'll look into something like that.

Also, can I request a bigger font in script editor? On my 22', 1680x1050 reading whole lot of not-that-big letters makes my tired quickly. So, please, think about it )

What Noxid said. Plus you can change the default font size in CaveEditor.txt now along with a bunch of other stuff.



I'm working on the map tile selection for copy/paste right now. Once that's done I'll have a new release up. (maybe tonight)

 

there's a save button in the script editing window, not sure how much quicker you can make that.

When I'm writing something, it makes difference to just slam two additional keys to save, or to move my right hand, pick the mouse and point it at the magical button, then continue writing. Maybe that's because as I'm typing a lot, I hold my hands differently when typing than while using keyboard + mouse, and I'm just used to press ctrl+s when typing. It's a matter of personal taste.

But thanks Wistil for planning to add this little feature.

 

Spoiler

(Spoilered for irrelevancy)

(I only have 1024 MB RAM but 2.4 GB of virtual memory...)

If I understand correctly, virtual memory (aka swap space) is only used for putting applications in the background; the front application needs to run fully in real memory, as do any processes doing stuff in the background.

While I am here I would like to make a request. Can you add a map "export to file" and "import from file" feature? If so then can you also give an option of exporting either all of the map data or only data for maps 000 to 094? Being able to save mapdata directly to file without the use of a hex editor would be quite useful.

It's funny; I seem to recall making a similar request awhile back (though I was calling for endian-indepence, ie a plain-text format, and I was also calling for more than just the map data) and you argued against it.

But that's not important. I would like to ask Wistil to please include a byte-order mark in the file if he implements it. That could be as simple as writing the integer 0xFFFE (or some other non-symmetric constant; 0xCABE maybe? B is pretty close to V, after all!) to the file before the actual data.

 

I would like to ask Wistil to please include a byte-order mark in the file if he implements it. That could be as simple as writing the integer 0xFFFE (or some other non-symmetric constant; 0xCABE maybe? B is pretty close to V, after all!) to the file before the actual data.

No. It needs to be raw PC format map data. Plus you have to understand that the different mapdata formats aren't only differentiated by byte order. The linux release has both Japanese and English map names, the mac release has two different mapdata formats that show a sense of confusion in regards to byte ordering, as well as 3 extra bytes per map block in both, and the psp release follows the pc format.

 

It's funny; I seem to recall making a similar request awhile back (though I was calling for endian-indepence, ie a plain-text format, and I was also calling for more than just the map data) and you argued against it.

But that's not important. I would like to ask Wistil to please include a byte-order mark in the file if he implements it. That could be as simple as writing the integer 0xFFFE (or some other non-symmetric constant; 0xCABE maybe? B is pretty close to V, after all!) to the file before the actual data.

Celtic, sorry if this seems contrary my previous request. When I'm deciding which suggestions to include in comes down to effort involved versus usefulness with some personal preference. andwhyisit's request required less than 20 lines of code and can be used to effectively move maps from one exe to another. Your request was quite a bit more involved and required addition code added throughout the map editor GUI to track changes and isn't readily "useful" at this point in time (in terms of allowing changes to be transported cross platform).

Also, adding that extra byte for identifying the format seems a little more confusing than using a unique file extension. So instead, the file extension .cemap was used which could be used to identify the endian of the data.


For now, a new update.
Tile copy/paste function (it's not quite to my liking yet but it's getting there).
Map info import/export (for single maps only).
and Ctrl+S to save in script editor.

 

For now, a new update.
Tile copy/paste function (it's not quite to my liking yet but it's getting there).
Map info import/export (for single maps only).
and Ctrl+S to save in script editor.

Oh my... I'm liking the copy/paste function...

 

No. It needs to be raw PC format map data.

It doesn't have to be... but it's at least better than nothing.

I still say we should have an additional export option to export all the other stuff that is changed within the executable, such as starting health, starting map, or whatever.

Do the .cemap files contain the complete map header data from the executable, or just the data for one map?

the mac release has two different mapdata formats that show a sense of confusion in regards to byte ordering,

Yes, because the mac version is two executables packaged into one file.

 

I still say we should have an additional export option to export all the other stuff that is changed within the executable, such as starting health, starting map, or whatever.

http://byuu.org/files/upset_v04.tar.bz2

this might help. it's a UPS patch utility, and in the ROM Hacking circles it's used for copying the changes made to a vanilla copy of the rom into a file that, therefore containing only what you have changed/made, is perfectly fine to post wherever, unlike the ROM itself. theoretically, because it's literally just copying the changes, you could use this to make patches for whatever changes you've made to the .exe, although i'm not entirely sure as i haven't tried it myself.

for those who know what an IPS is, UPS is basically an IPS without the file size limitations, i.e. it can change more stuff or something although i'm not clear on the technical details.

 

Do the .cemap files contain the complete map header data from the executable, or just the data for one map?

Complete mapdata header.

 

http://byuu.org/files/upset_v04.tar.bz2

this might help. it's a UPS patch utility, and in the ROM Hacking circles it's used for copying the changes made to a vanilla copy of the rom into a file that, therefore containing only what you have changed/made, is perfectly fine to post wherever, unlike the ROM itself. theoretically, because it's literally just copying the changes, you could use this to make patches for whatever changes you've made to the .exe, although i'm not entirely sure as i haven't tried it myself.

for those who know what an IPS is, UPS is basically an IPS without the file size limitations, i.e. it can change more stuff or something although i'm not clear on the technical details.

That only works when the file being patched is the same. I'm not asking for a patch format that can be used to transfer changes from one copy of Windows Cave Story to another; I'm asking for a patch format that can be used to transfer changes from Windows Cave Story to Mac, Linux, PS2, whatever version of Cave Story you want. The UPS format falls short of this goal, and while it would be technically possible to use it, it would be a whole lot of work on the Mac side translating Windows offsets to Mac offsets in the executable. (The map data export is a step in the right direction, but it still misses certain information.) What's needed, then, is a patch file that stores the data according to what it means, not where it belongs; then Cave Story editor programs on the various platforms simply need a mapping of meanings to locations in order to interpret it.

Actually, I might have a go at writing something like that myself... I could look at the Cave Editor source and figure out the offsets from there, I expect.

 

The UPS format falls short of this goal, and while it would be technically possible to use it, it would be a whole lot of work on the Mac side translating Windows offsets to Mac offsets in the executable.

Compared to what? You still need to convert from your patch to the Mac format as well.

Actually, I might have a go at writing something like that myself... I could look at the Cave Editor source and figure out the offsets from there, I expect.

If you really want to do this then there is one thing you need to understand...

Do not attempt to make it human readable. You need it to be as machine readable as possible if you want people to use it and develop for it, so store your values as bytes. For instance:
0x00 Starting Health
0x02 Starting Map
0x03 Starting X Pos
0x05 Starting Y Pos
0x07 Starting Event
0x09 Intro Map
0x0a Intro X Pos
0x0c Intro Y Pos
0x0e Intro Event
etc.

..and document the patch file in the readme file (like the example above) for developer use.

Still think it's a bad idea either way but a bit of advice can't hurt.