CaveEditor again (beta, maybe alpha)

[Lace]

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

[dooey100]

Originally Posted by Schokobecher

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.

[andwhyisit]

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

Originally Posted by Celtic Minstrel

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.

[Celtic Minstrel]

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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?)

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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.)

Originally Posted by andwhyisit

..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.

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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?

Originally Posted by andwhyisit

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.)

Originally Posted by andwhyisit

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.

[andwhyisit]

Originally Posted by Celtic Minstrel

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.

Originally Posted by Celtic Minstrel

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.

Originally Posted by Celtic Minstrel

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.

Originally Posted by Celtic Minstrel

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.

Originally Posted by Celtic Minstrel

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?

[Wistil]

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.

Originally Posted by wedge of cheese

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.

[Celtic Minstrel]

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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).

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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.

Originally Posted by andwhyisit

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.

Originally Posted by Wistil

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.

[andwhyisit]

Originally Posted by Celtic Minstrel

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.

[Noxid]

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.

[Wistil]

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.