CaveEditor again (beta, maybe alpha)

What about this suggestion?

Unnecessary. You can do it simply by documenting the executables for both mac and pc, like what was done for the profile.dat converter. All you need to do is find the mac address, pc address, and default unedited value for every non-assembly-related offset.

 

Unnecessary. You can do it simply by documenting the executables for both mac and pc, like what was done for the profile.dat converter. All you need to do is find the mac address, pc address, and default unedited value for every non-assembly-related offset.

Um... I don't think you understand my suggestion. It essentially means outputting a "patch" in a format that both Mac and Windows editors can understand. The use of such a file would be to port a mod between the platforms; with the patch file, porting would consist of copying all the data files, then opening the editor and importing the patch. Without a patch file, porting would be a much more involved task.

(Though, that assumes that the mod has no assembly hacks. Mods with assembly hacks may be a little trickier, even with a patch file.)

Your alternative suggestion does not satisfy my suggestion, though it would be a necessary step in order to actually import a patch file.

 

It essentially means outputting a "patch" in a format that both Mac and Windows editors can understand.

I hope you will include the missing information...
else:
Death penalty-

 

Shmitz, I think it was, determined the character limit of TSC files is 17,999, including spaces and line returns; anything above that can cause problems. Can you implement a character counter so we can know if we reach that limit?

Also, this would only work if the script editor uses fixed-width text, which I'm pretty sure it does if I remember right, but do you think you could put in a background line as a guide for when text needs a line return? One that could be set for normal text and text indented with a facepic. That way we could easily check our text against the line by just hitting return at the beginning, and then proceeding as normal with our formatting.

...If that makes sense.

 

Shmitz, I think it was, determined the character limit of TSC files is 17,999, including spaces and line returns; anything above that can cause problems. Can you implement a character counter so we can know if we reach that limit?

I dun thin this is neccesary, as I told wistil how to fix this problem way back. It's a very easily changeable value and wistils a smart guy, I think he's got it.

 

Oh, okey. I did nae know that.

Oh, if it wasn't suggested previously, a copy-and-paste function would be nice for the image editor. I know you didn't want to implement a full-fledged editor, but it's easier to have it all in one, and just one more simple function would be nice. You don't have to, though.

 

We use Tiled as the map editor for games my company makes, and there are some things it does really well. There are also some things it does very poorly at, but oh well. Some features I like from it (that are applicable to cave story) are being able to refresh images if you edit them outside of the program, and being able to select an area and do a fill in just that area.

 

I'm confused, is dooey a spamboot now?

 

no, he was responding to something that I said, no matter how offtopic I may have been.

 

Nice way to sell you iShit stuff in a CaveEditor thread.
Guess i'll report that one as spam?
Use PMs or a prvate discussion.

No one cares about iShit.
Just look at the revolution called the "iPad".
Yeah it's a iPod Touch without the phone featurs.
and it's larger.+
doesn'tt fit in any pocket.
can't do the same shit as a netbook/notbook.
and costs like 3 times more.
Awesome!

Dude he asked, so I answered. Since when does two offtopic posts constitute spamming? If you hadn't posted this, it probably would never have been mentioned again, and we could have returned to talking about Cave Editor. So please, drop this discussion right now and stop contributing to the derail.

I'm going to ignore your mention of the iPad because I have no idea how that came up, I never mentioned it.

 

dooey100 is right you know, though he could have sounded less advertisey. Now get on topic guys.

Um... I don't think you understand my suggestion. It essentially means outputting a "patch" in a format that both Mac and Windows editors can understand. The use of such a file would be to port a mod between the platforms; with the patch file, porting would consist of copying all the data files, then opening the editor and importing the patch. Without a patch file, porting would be a much more involved task.

It is you who fails to understand.

1. You cannot hope to create such a patch file without fully documenting the mac and pc executables.
2. Such a patching system requires a patcher and a file. It is more efficient to create a program to search for changed offsets in your mod and applies them directly to the executable, which is what I was suggesting. Creating a patch file is pointless since it requires you to create a patch, then patch the file right after. There is absolutely no use for the patch outside of that, which makes it entirely redundant.
3. What I am suggesting will be editor independent.

Basically instead of:
ext = ".bmp"

..you will have:
[pc address] [mac address] [default unedited value]

..for each offset. This can be done for any other platform as well, as long as the executable is fully documented (which is the reason why there are no mods for mac yet, because no-one wants to bother documenting the mac executable). Plus you can also run a check for information redirected by CE-based mods (map data was it?).

Wistil probably has little interest in creating a patch file that no-one can use or will ever be able to use just because you and everyone else here are too lazy to document the mac executable. Nor a patch file that is ultimately redundant.

Now if you wanted a patch file for distribution then that would be useful, but it still needs to be editor independent and you may still need to fully document the executable if you want it to be platform independent as well.

Find out what each and every non-assembly-related pc version offset does, its address, its default value. Repeat this for the mac version. Do this and someone would be able to create a program with little effort. It's what I did for the save converter. Even if no-one creates a program (unlikely) then it is still possible to use your documentation to port a mod manually.

p.s. Also it might be best to keep in mind that the byte order is reversed in mac executables.

 

1. You cannot hope to create such a patch file without fully documenting the mac and pc executables.

False. A patch file such as I described is nice because it doesn't require full documentation. The editor simply needs to know what has changed, not where. It then knows where to make the change. It doesn't need a complete list of what is stored where.

2. Such a patching system requires a patcher and a file. It is more efficient to create a program to search for changed offsets in your mod and applies them directly to the executable, which is what I was suggesting. Creating a patch file is pointless since it requires you to create a patch, then patch the file right after. There is absolutely no use for the patch outside of that, which makes it entirely redundant.

I'm not going to argue about which is more efficient, because I honestly have no idea.

However... executable files have a specific format, and there is no guarantee that a certain value will be at a certain offset, particularly since Cave Editor properly observes the Windows executable format (unlike Sue's, apparently). Wistil has already moved the maps to a new location in the file. He could easily do something like that again, causing your type of patch to break. My suggestion, however, is independent of where the value needs to be stored in the foreign executable and would survive such a change.

As for your redundancy argument... it seems to assume that everyone has access to both Mac and Windows computers. A more realistic scenario is that someone creates a mod and distributes it for one platform, with the patch file included so that users of another platform can apply the patch to a fresh executable and also play the mod. In general, the person creating the patch file would not be the same as the person using the patch file.

(A version with a patch file but no executable could also theoretically be distributed, to save bandwidth... but there's not really good reason for that, since bandwidth is fairly cheap nowadays... I think?)

3. What I am suggesting will be editor independent.

My suggestion is also editor independent, and easily extensible as well. Though, to be fair, your version is just as easily extensible. It's less flexible though.

Basically instead of:
ext = ".bmp"

..you will have:
[pc address] [mac address] [default unedited value]

This is more work than my version. With this suggestion, patching would involve the program scanning a file in a foreign format to examine various areas of the file, reading the value there, and then applying it to the local executable file. The main point here is that it would have to read and write every single known value. (This because the executable being patched might not be a fresh copy.)

With my version, it would simply have to read and parse a simply-formatted text file and, for each line, write a value to a particular location in the target executable. It would not have to worry about the foreign executable. (It would still have to write every value, including the defaults, in case the executable isn't a fresh copy, though.)

..for each offset. This can be done for any other platform as well, as long as the executable is fully documented (which is the reason why there are no mods for mac yet, because no-one wants to bother documenting the mac executable). Plus you can also run a check for information redirected by CE-based mods (map data was it?).

It's more because no-one has made level editors. You can make a mod without hacking the executable, you know. It wouldn't be as sophisticated, but it's possible.

And you're still wrong that the executable needs to be fully documented. It doesn't.

Wistil probably has little interest in creating a patch file that no-one can use or will ever be able to use just because you and everyone else here are too lazy to document the mac executable. Nor a patch file that is ultimately redundant.

Can you let Wistil speak for himself, please? Thanks.

Now if you wanted a patch file for distribution then that would be useful, but it still needs to be editor independent and you may still need to fully document the executable if you want it to be platform independent as well.

Yes. A patch file for distribution. Wasn't that what I said?

And no, you won't need to fully document the executable. Why do you even think that?

Find out what each and every non-assembly-related pc version offset does, its address, its default value. Repeat this for the mac version. Do this and someone would be able to create a program with little effort. It's what I did for the save converter. Even if no-one creates a program (unlikely) then it is still possible to use your documentation to port a mod manually.

Keeping in mind that it's possible some values will be duplicated in the Mac executable; it's a Universal application, which basically means it contains two copies of the code in two different assembly languages (PowerPC assembly and x86 assembly, the latter presumably being what everyone here uses in their assembly hacks). Most of the data would probably be separated from the code, but some numeric constants may not be. (In fact, it's possible the file may have more than two copies of the code; there may be separate 32-bit and 64-bit x86 code.)

p.s. Also it might be best to keep in mind that the byte order is reversed in mac executables.

Are you sure about this? It may be, for backwards compatibility with PPC, but it may be worth mentioning that newer Macs run in the same endian as Windows. That is, we're both little-endian. It's equally likely that Rosetta (the PPC emulator) will automatically byte-swap as necessary for the benefit of PowerPC code. I don't really know which is the case.

 

False. A patch file such as I described is nice because it doesn't require full documentation. The editor simply needs to know what has changed, not where. It then knows where to make the change. It doesn't need a complete list of what is stored where.

Sure, you can create a patch without fully documenting the mac executable, but for the patch creator to build the patch it needs to know what each offset does, else you can't ever hope to build a patch. Furthermore the patcher cannot apply the patch to the mac executable without knowing which offsets to apply each value to. The idea of producing an effective patch without fully documenting at least one executable is foolish.

The use of the patch for distribution on macs is ultimately flawed because the data folder's content is stored within the mac executable last I heard.

I'm not going to argue about which is more efficient, because I honestly have no idea.

However... executable files have a specific format, and there is no guarantee that a certain value will be at a certain offset, particularly since Cave Editor properly observes the Windows executable format (unlike Sue's, apparently). Wistil has already moved the maps to a new location in the file. He could easily do something like that again, causing your type of patch to break. My suggestion, however, is independent of where the value needs to be stored in the foreign executable and would survive such a change.

So the patch stays the same yet you must alter the patcher? I hardly see the difference.

As for your redundancy argument... it seems to assume that everyone has access to both Mac and Windows computers.

Wrong. It's either "mac computer + windows cs mod executable + unaltered mac cs executable" or "windows computer + mac cs mod executable + unaltered windows cs executable". Where did this "both windows and mac" nonsense come from? Basically you download the pc mod and the original mac executable on a mac os and then patch the mac executable with the changes in the pc executable.

A more realistic scenario is that someone creates a mod and distributes it for one platform, with the patch file included so that users of another platform can apply the patch to a fresh executable and also play the mod. In general, the person creating the patch file would not be the same as the person using the patch file.

(A version with a patch file but no executable could also theoretically be distributed, to save bandwidth... but there's not really good reason for that, since bandwidth is fairly cheap nowadays... I think?)

A multi-platform distribution cannot work for assembly hacks since it is written differently for each platform, so such a patch cannot be used for distribution. It is better to simply patch the executable then port assembly by hand. A proper patch for distribution will need to be platform specific and can be put together alot more easily, so lets not worry about that for now.

Are you sure about this? It may be, for backwards compatibility with PPC, but it may be worth mentioning that newer Macs run in the same endian as Windows. That is, we're both little-endian. It's equally likely that Rosetta (the PPC emulator) will automatically byte-swap as necessary for the benefit of PowerPC code. I don't really know which is the case.

The mac save data was in reverse byte order to the windows version, why would the executable be any different?

 

Unfortunately Celtic Minstrel, many on the edits made in the games settings are located in the assembly of the program. Also, until there's at least a rudimentary editor for the mac version (I'm not aware of one) I don't see haw listing that map 5 is now using the Weeds tilesset or that the start event have been changed to 201 is useful.


Minor update.

In the map editor, I notice that the NPCs don't refresh as often as they should (for example, when you change an NPC's type, the text/sprite on screen doesn't change appropriately until you move the NPC).

Fixed.
Also, you can now sort by either category, name, or ID number. Plus, it's all stored in CE_NPC.txt now and is much easier to edit if you want to.

You can now see the graphic (for those that CE finds graphics for) in the npc.tbl editor. Upon viewing the npc.tbl a little more while testing, I don't think that the display box that I have is accurate. Specifically, things like the sunstones appear shifted from how they look in game. I'll look into that a little later.
A delete all entities command was also added to the menu.
All in all minor updates but needed ones.

 

Sure, you can create a patch without fully documenting the mac executable, but for the patch creator to build the patch it needs to know what each offset does, else you can't ever hope to build a patch. Furthermore the patcher cannot apply the patch to the mac executable without knowing which offsets to apply each value to. The idea of producing an effective patch without fully documenting at least one executable is foolish.

If the patcher is built into the editor, then it will know which offsets to apply each value to. That's the whole point – the editor knows where to put everything, but the patch doesn't specify where. It only specifies what.

The use of the patch for distribution on macs is ultimately flawed because the data folder's content is stored within the mac executable last I heard.

Not true. On Mac, applications are "packages", which are folders disguised as files. The package folder contains things like information that the Finder needs, the actual executable file, and the data folder. So, the data folder is inside the application package, but it's not inside the executable file. I can go into the data folder and edit TSC scripts, for example.

So the patch stays the same yet you must alter the patcher? I hardly see the difference.

Um... I don't think you'd need to alter the patcher. What I meant by that is that if some new offset were discovered, the format of the patch file would remain the same, even to the extent that a patch using that new offset could be used with a version of the editor that doesn't know about the offset (it would just ignore the relevant directive).

Wrong. It's either "mac computer + windows cs mod executable + unaltered mac cs executable" or "windows computer + mac cs mod executable + unaltered windows cs executable". Where did this "both windows and mac" nonsense come from? Basically you download the pc mod and the original mac executable on a mac os and then patch the mac executable with the changes in the pc executable.

Yes, that's right. I'm not sure how that has anything to do with redundancy.

A multi-platform distribution cannot work for assembly hacks since it is written differently for each platform, so such a patch cannot be used for distribution. It is better to simply patch the executable then port assembly by hand. A proper patch for distribution will need to be platform specific and can be put together alot more easily, so lets not worry about that for now.

I am aware of this; there's probably nothing that can be done about it (though it may be possible to directly translate between assembly dialects). The patch can still be used to handle all the non-assembly work, then you could port the assembly by hand.

The mac save data was in reverse byte order to the windows version, why would the executable be any different?

No idea. But it's possible.

Unfortunately Celtic Minstrel, many on the edits made in the games settings are located in the assembly of the program. Also, until there's at least a rudimentary editor for the mac version (I'm not aware of one) I don't see haw listing that map 5 is now using the Weeds tilesset or that the start event have been changed to 201 is useful.

You seem to understand what I mean. I understand your reluctance to implement it when there's no Mac editor available, but if you could put it on a "to do eventually" list, that'd be great.

For the record, I have grand plans of making a Mac editor. I'm not sure if/when they'll come about. I've already created utilities to aid in the editing of TSC scripts, and am in the process of making an npc.tbl editor... but those are probably the easiest parts. For modding, one would need at least a map editor as well.

 

For the record, I have grand plans of making a Mac editor. I'm not sure if/when they'll come about. I've already created utilities to aid in the editing of TSC scripts, and am in the process of making an npc.tbl editor... but those are probably the easiest parts. For modding, one would need at least a map editor as well.

Good luck.

 

The list for "Tileset" dropdown in the NPC.tbl editor in this is all like, wrong and incomplete and stuff. Here's a list I just made by testing each possible value.

0 = title image
1 = "2004.12 Studio Pixel"
2 = current map tileset
3 = null
4 = null
5 = null
6 = bg fade sheet
7 = null
8 = itemimage.pbm
9 = ????
10 = ????
11 = arms.pbm
12 = armsimage.pbm
13 = The text that appears from <MNA
14 = stageimage.pbm
15 = "Loading" image from title screen [behaves oddly]
16 = mychar.pbm
17 = bullet.pbm
18 = null
19 = caret.pbm
20 = npcsym.pbm
21 = Map tileset 1
22 = Map tileset 2
23 = npcregu.pbm
24 = null
25 = null
26 = textbox.pbm
27 = face.pbm
28 = Map BG
29 = something to do with the text for weapon names in menu; changes the gfx depending on last weapon viewed
30 = Something to do with the description text for inventory; as above.
31 = more of the above. But also different.
32 = ????
33 = null
34 = ????
35 = The credits image with sue and kazuma and quote on the sky dragon with a chopper in the distance. Blue.
36 = ????

Null means the offset leads to 00000000
???? means there was a value there, but all my graphics dissappeared as if it were 00000000, so I can't tell what it was.

 

Thanks Noxid!
I will have to update my list now. I'll even place it inside the ini file, which will also be holding all the data from those other external text files. Sadly, I am still using data that was developed mainly back in 2006-2007.

 

Wistil, can you pretty please make Cave Editor compatible with a double-resolution Cave Story, with double-sized bitmaps?

 

He means quadruple-resolution and quadruple-size bitmaps, of course (twice the width and twice the height).