As for the Train Morph, it will just act like air, it's not affected by water at all (I've tried the Submarine-water). A problem with the "Submarine" Train is, that the status of the tiles which are covered by Rails/Castle Walls/Cross-Sections is overwritten, so they will become "air" as well and are no longer treated as water. That's why you should never use Object-coins in Submarine areas, but Sprites only.
The file is only needed in case you want the exact same Yoshi colors like Golden Yoshi uses in his SMW2+2.
You actually don't really need the file, you can also simply extract them from the SMW2+2 ROM, same location; you can copy from SMW2+2 0x1FA240 to 0x1FA32F and paste it into your ROM
The program is written in C#, so you can try what you can do with DotPeek, which is a decompiler. However, since Romi has left the site a long time ago, it's unlikely he will release the source code of the project anytime soon.
Romi and tehaxor69 are both gone, so it's very unlikely a new editor for the game will be available anytime soon, also we most likely won't get any source code to work from.
However, what kind of new features would people like to have anyway? I can only think of more graphic support and stuff like a BG2/BG3 tile editor. Other things can be done by other tools, for example start point and midway editing.
Yeah, you will get the support needed in order to create a YI hack if you ask. However, you must understand, that the game has far less possibilities than SMW, for example you can't customize much stuff, real custom objects and sprites do not exist, you must stick to what the original game has to offer mostly. You can edit some graphics and palettes for neat effects, though.
As for the low activity, yes, there doesn't seem to be much interest, but that might also be caused by the problems the level editors for the game make. EggVine is not beginner-friendly at all and Golden Egg will mess with ROM-space allocation on its own. That might also prevent newbies from becoming interested, since you need to time to start and find out how to make good levels. Not to mention you need many other applications for things like start point and midway editing; also using a Hex-Editor from time to time is required.
I don't know about Zeldara, but I don't really have 'problems', it's mostly because I have to work 8 hours a day plus university homework and exams and other stuff. Then I still use a lot of time to see my friends and do other things in my spare time, so not much left for SMWC, but I try.
Hm, keeping Golden Egg and managing ROM space on your own is somewhat complicated to achieve and will cost you some effort. For example you could have one ROM to "mess" with and another one to transfer the level data to.
For example, you copy a fresh YI ROM and then overwrite all the existing levels with free space (I could even write a simple tool to do that). Afterwards, you make some levels with the other ROM and transfer the data to whichever location you want to have in the ROM with the overwritten levels. Note, that other ROM changes would have to be made as well, such as Start Point and Midway editing. By doing it like this, you will have some more effort than normally, but full control over ROM space allocation.
The other method is to switch to EggVine and get used to it; it's really not that hard. If the limitations annoy you, you can also overwrite the levels with free space and then plan in advance how much space you need for each level and do the "level expanding" stuff to make room for levels.
Other than that, it would also be possible to allow for flexible ROM space allocation by writing a tool to find free space and level space in a ROM, extract the level data, then overwrite everything with FF-bytes and re-insert the level data in a clever way. But that requires time and I don't know if I will do this sometime soon.
I'm currently trying to code a tool, which rearranges level data in a YI ROM. Now my question is, does anyone know a clever way, which doesn't take hours to compute, which solves the following problem:
Let's say I have 3 fields of free space, 2500 bytes, 4000 bytes and 3000 bytes.
Now I have some level data which is 1200 bytes, 400 bytes, 700 bytes, 600 bytes, 2700 bytes, 1800 bytes, 1900 bytes.
Now, the intuitive way of solving this is using the "greedy" technique.
First, I sort both types of data, so I have [4000, 3000, 2500] and [400, 600, 700, 1200, 1800, 1900, 2700].
Afterwards, I fill each field of free space.
I take the first field with a size of 4000, then I look for the number that comes closest to that value from below, which is 2700 and insert it. Afterwards 1300 bytes are left and the next best fit is 1200. 100 bytes are left, but there is nothing, that could fit into that, so I move on to the next field.
There we have 3000 bytes, so I insert 1900 and have 1100 left; next is 700, then 400 and I am done, 0 bytes left, perfect.
The last field has a size of 2500 bytes, so I choose the 1800 bytes and then 400 bytes; the process is finished. We now have:
I think there once even was a patch to determine the Tiles chosen for Tileset #01 for each single room index. However, I can't find it right now and I also think it was kind of buggy...
Another option you have is to enable those tiles for any World except for the World determined at 0x354A.
Aside from that, the Tileset-Changers are unable to load the Tiles normally used for the World 6 Bone-Tileset, so you can still use that to have the "normal" Tileset #01.
Thanks a lot for the input =)
@Ragey: Of course I'm separating Objects and Sprites, to me Level Data means either Object or Sprite Data. I just had to use huge numbers for my example. But yeah, the largest amount of Object Data in my Hack in one level is 3356. But I'm not programming this for my Hack, since it's done, actually I want to reduce the damage done by Golden Egg's auto-relocation. However, one more thing making this more difficult, is that Golden Egg doesn't use FF-bytes when relocating, but 00-bytes instead, which are used way more often for other stuff than free space as well.
@Smallhacker: Yeah, it sounds pretty familiar to that one, maybe a good attempt is to use "greedy", but instead of checking for only one level, implement a second check, which tests if two smaller levels at once fit better.
@HuFlungSno: The amount of freespace varies depending on how much the ROM is affected by Golden Egg's arbitrary ROM space management and is greatly increased if graphics were re-compressed properly, since the freespace behind graphics can be used as well. I'm using C# for programming.
I'm currently working on a tool to automatically rearrange level space in a YI ROM. I'm kind of stuck at the moment, since I'm thinking about a good algorithm to re-insert the levels. Another problem is, that Golden Egg does not leave fields of FF-bytes when relocating level data, but fields of 00-bytes, which is very inconvenient for me.
Sadly, I'm incapable of programming an editor for the game, which has better features (especially visualisations) than Golden Egg, my understanding of the ROM's inner working is too low...
However, the new tool will hopefully give you satisfactory results; I will also implement a feature to extract level data and a feature to select a folder full of extracted levels, which are then inserted into a chosen ROM.
Okay, but here is how you do it by hand:
1. Pick a level you wish to insert and the type of data you want to insert (objects or sprites); for the example I will use the sprites of level 0x7A.
2. Find out the space consumed by the new data. So you simply check the file size of the extracted RAW Level Data, which equals that size. Note it down.
3. Find the pointer to the level data in the ROM. First, find the pointer.
For object data, you calculate (0xBF9C3 + 6 * <LEVEL>).
For sprite data, you calculate (0xBF9C6 + 6 * <LEVEL>). Once you found the pointer offset, note it down. For the example, the pointer offset is (0xBF9C6 + 6 * 0x7A = 0xBFCA2). Jump to that offset.
There are three bytes there.
In the example, these are [5E BC 14].
4. Find the level data.
It's best to use LunarAddress to find out where the pointer points to.
You read the bytes backwards, so [5E BC 14] becomes [14 BC 5E] and give it to LunarAddress.
It spits out 0xA3E5E. Jump to that offset.
5. Now you want to find out how many bytes are consumed by the level data, so you can turn it into free space/overwrite it.
The best thing is to open the level in EggVine.
Opening level 0x7A gives us 195 bytes of maximum usable (<== which is the important number) Sprite Data.
Note that number down, you might need it now.
6. Now we turn that into free space or overwrite it. Compare the sizes of your old level data and the new level data*.
If the new level data is smaller or equal the old data, you overwrite the old data (STEP 7A).
If the new level data is greater than the old data, you have to look for a new spot (STEP 7B). *IMPORTANT: EggVine does not calculate the level header for Object Data nor the ending FF-bytes for both Data Types, so for objects add 12, for sprites add 2!!!
7A. Simply copy the entire new level data and insert it into the ROM, beginning from the original location of the data (in the example, if the new Sprite Data is smaller or equals 197 bytes, I paste it beginning from offset 0xA3E5E).
Afterwards, if the new data is smaller than the original data, insert FF-bytes where old data was (in the example, I have 7A.spr, which is 155 bytes. I insert it from 0xA3E5E and insert the remaining 42 FF-bytes after the new data).
7B. Go back to the offset of the data (0xA3E5E in the example) and insert 195+2 FF-bytes from there (in Translhextion you can simply paste one byte multiple times).
You can reload the level in EggVine. If there are now 0/0 usable bytes, it was most likely successful.
Now, that you have erased the old level data and got yourself some free space, which may be used again by something later, it's time to look for some space the new level data fits into, so you look for a bunch of FF-bytes in the ROM (in the example, 7A.spr is 278 bytes, which fits into the space beginning from 0x11554A).
Once you have found a good place, copy the entire content of your RAW Level Data and paste it into the ROM. Note down the start location of where you pasted it (in the example, the sprite data of level 0x7A has been pasted beginning from 0x11554A).
The level data is now INSIDE the ROM, however, the game cannot access it yet.
Now you give LunarAddress that start address where it says PC, and it will convert it back into SNES LoROM format (in the example, 0x11554A becomes 0x22D34A). Jump back to where the pointer to the data was (in the example, that is 0xBFCA2). Reverse what LunarAddress gave you and overwrite the existing pointer with that (in the example 0x22D34A becomes [4A D3 22]). Now, save the ROM. You can check the level in the editor of your choice now.
About your second question, I think Golden Egg just leaves the data AFTER the graphics untouched. The data before the graphics (usually 0x11554A-0x1201FF) cannot be overwritten unless someone dumb tries to mess with YCompress. Also, for inserting in YCompress, using 11 instead of 1 in the command line will not overwrite other existing data after the graphics (except if the compressed size has increased).
Also, be careful with YILEX. Always double-check the file size and the size of the level data in the REAL ROM. I cannot guarantee that it's flawless.
Aside from that, if the tutorial hasn't been clear enough tell me where you have problems.
As some of you might now, I'm currently coding a tool to reallocate all Level Data in a YI ROM, so when Golden Egg leaves a mess, this tool will clean your ROM up a little. For the sake of reallocation it is important to know where the Freespace in the ROM is located. What you can see above is a diagram showing the amounts of freespace in an otherwise unmodified YI ROM, that got all its Level Data turned into Freespace. Here is how you read it: RED: Not a single byte of Freespace here
BLACK/GREEN: The greener it is, the more Freespace it has YELLOW: All bytes are Freespace here
Note, that some of this Freespace (especially very black fields) can't be really used for inserting Level Data, since I simply checked for two consecutive [FF]-bytes and counted [FF]-bytes from there onward. It can occurr, that an internal table or some piece of code or graphics has a few consecutive [FF]-bytes, which doesn't really count as Freespace, then.
Also, I know, that Golden Egg leaves fields of -bytes when relocating Level Data, so I have to find a method for taking these into account as well.
Thanks for the advice, Alcaro.
However, two consecutive [FF]-bytes can already be Level Data. I guess it's the same in SMW, but in YI, Object and Sprite data are separated and thus have different pointers and formats.
The Object-Format is like this: [Header(10)][Object 1(4/5)]...[Object N(4/5)][FF][Screen Exit 1(5)]...[Screen Exit N(5)][FF]
Having zero Objects and zero Screen Exits makes Object Data look like this: [Header(10)][FF][FF] <= 12 bytes minimum size
However, the Sprite-Format costs a lot less bytes in comparison and is like this: [Sprite 1(3)]...[Sprite N(3)][FF FF]
Having zero Sprites makes Sprite Data look like this: [FF FF] <= 2 bytes minimum size
Having such a tiny requirement of space for Level Data causes some problems, even when hacking the original game. Since the ending sequence for Sprite Data can be used for a whole set of Sprite Data itself, Nintendo made use of this and produced data crossovers of Level Data.
This can be seen when looking at the Sprite Data of level 0x19 and 0x51. Level 0x19 does not contain any Sprites, so the pointer for the Sprite Data points to the ending sequence of the Sprite Data of level 0x51. If you now delete a Sprite from Level 0x51, EggVine will cause a problem, because it will turn
...[Sprite 77(3)][Sprite 78(3)][Sprite 79(3)][FF FF]
...[Sprite 77(3)][Sprite 78(3)][FF FF][00 00 00]
thus manipulating the Sprite Data of 0x19, because the ending sequence turned into Sprite 0x000 and it continues to read data until the next ending sequence. The problem is unlikely to occurr in Golden Egg, though; it simply relocates the whole Level Data of the current Level almost every time you save (producing different problems, namely unripe automatic ROM space management).
I don't exactly have an algorithm right now, but it is already possible to prioritize freespace.
Once a ROM is opened, all the levels are replaced with freespace in the program and you can check and uncheck each field of freespace (currently the threshold is hardcoded at 30 [FF]-bytes). The program will do a little auto-priorization for you, so the former level-space will be prioritized and the huge field of free space going from 0x11554A to 0x1201FF. You can prioritize each field of freespace manually, but the program also has an option to prioritize each field of a size bigger than X or unprioritize spaces smaller than X.
When performing the actual reallocation then, the program will first make use of the prioritized fields of freespace and take the others after that.
It also offers stats about the Level Data. It is possible to choose for each Level Data, whether you want to reallocate it (of course it's recommended to reallocate all of them) and shows how many bytes of Level Data are chosen for reallocation, how many bytes of freespace have been found all together and the amount of freespace prioritized. You will be warned if you've prioritized less freespace than level space to reallocate.
It will also be possible to select a Directory on your Windows System to read RAW Level Data from. You can then check and uncheck all the validated Level Data from that Directory to insert into your ROM.
For example, if you have a file 00.obj in that directory, instead of just reallocating the internal Object Data of Level 0x00, it will turn the Object Data of Level 0x00 into freespace and insert the file 00.obj as new Object Data of Level 0x00 into your ROM; having this, Levels will become (mostly) portable.
Of course there is also an option to extract all the RAW Level Data from the ROM and save it into a certain Directory. Currently, it automatically extracts all Data, but I will make it possible for the user to choose which Level Data to export.
On another note, currently the program works with checked List Boxes, which can be a little unclear sometimes. I'm thinking about implementing a block view, as provided in the screenshot above. Having a 2-dimensional view will make it possible to see everything at once without scrolling. That will work for checking which Level Data to reallcoate.
I have to think about the freespace, though, since for that you need more information (not just booleans), such as start address and length.
Alright, so here is the un-checkedlistboxed version of the external level selector (which determines, which levels from a folder on your computer are inserted into the currently openend ROM), that was replaced with a panel with some nice rectangles on it. Below you have a few options to check many levels at once.
As you hover over the panel, the currently selected level is shown below. By left-clicking you alter the checkstate of the Object Data of the selected level, by right-clicking you alter the checkstate of the Sprite Data of the selected level.
Green entries are checked, black entries are unchecked and grey entries don't exist (in this case, the complete level 0x01, the Sprites of level 0x03, the complete levels 0x0A to 0x0F and 0x3A to 0x3C and the Objects of level 0x3D. 0xDE and 0xDF don't exist anyway, so they are not even represented by rectangles).
Feel free to leave comments about that concept, but I found it to be much better than having a checkedlistbox, which requires endless scrolling if you have many levels.
To stop this from happening you must alter the Level Mode.
IIRC the following values are safe: 3,5,6,B,C
However, if I were you, I wouldn't build the level around the warps; if you have to change the Level Mode, certain BG3 effects might stop working (like fog and snow).
The alternative is to either place your warp so, that there is no BG2 behind Yoshi or you can use an instant warp or a door as well (note, that doors take up 1 out of 4 SuperFX slots).
Ah, thank you. That's very helpful. I would like to come out of pipe (downwards) just because of how the last section ended (i.e. going down into a pipe) but it's not crucial.
Yeah, I was not saying that you should change the warp as soon as you have to change the Level Mode; I personally always changed the Level Mode and looked for things, that wouldn't work right then. If everything is fine, all you do is change the Level Mode. However, when I wanted some neat BG3 animation or something that only works with a certain Level Mode, I preferred that over having a pipe.
(In my Hack this can be seen in some snowy Levels, where there's an instant warp instead of a pipe, because of the BG3 snowstorm effect only working with Level Modes 8 and F.)
Of course the levels are not erased as soon as you open the ROM. The program will make two copies of the ROM in memory, one with the original content and one with the levels removed. I found that necessary, since, depending on the levels checked to reallocate, the amount and position of freespace can vary. These copies do not affect the ROM file on your system, that's why I said "levels are replaced with freespace in the program", maybe I should have explained a little better.
I'm also really trying to release it soon, unfortunately I have yet to find out how to solve the issue with the -bytes being freespace and implementing an actual algorithm. I'm also trying to make it as easy and fast to use as possible.
On another note, very nice screenshots you got there, which levels are they from?
Sadly that's quite a flaw Golden Egg has there. It is not possible to view out-of-bounds Objects, thus the Editor throws these messages. You must check the Objects at the given positions. Move them upwards a little, so you can see them in full height. Then, adjust the height and move them back down. You can still open your Level in EggVine and select the option to view out-of-bounds Objects, you can then simply adjust them, save and go back to Golden Egg (make sure you only have the ROM opened in ONE Editor at a time).
These red boxes are called Screen Exits and you need them to warp Yoshi to different levels. And I am 100% sure they cannot cause such a problem. In case you want them to go away, click the pipe symbol in GE and goto indexes 75 and 78, then uncheck the checkbox there. Even when placed out-of-bounds (which is impossible in GE) Screen Exits are harmless. If you still can't solve it, you can send me an IPS patch for your ROM and I'll send you one back with the level fixed and an explanation.