Banner
Views: 863,589,116
Time:
16 users online: BreadWheatmann, BWGLite, Dark Prince, Drippz85, Edidoo, Fullcannon, Gammed Z, Green Jerry, Infinity, JX444444, kaigem,  MiniMawile303, ModernKiwi, OrangeBronzeDaisy, Rykon-V73, TheInsanity115 - Guests: 76 - Bots: 57 Users: 47,794 (2,069 active)
Latest: Wave95
Tip: Don't put a coin over a question block. It will create an invisible solid block above the ? block if the block is hit first.Not logged in.
SMW2 Yoshi's Island offsets and helpful info
Forum Index - Non-SMW Hacking - Yoshi's Island Hacking - SMW2 Yoshi's Island offsets and helpful info
Pages: « 1 232 33 34 35 36 37 38 39 40 41 42 »
It's perfectly fine, yeah.

--------------------
Your layout has been removed.
@xxxzzz1:
To dispose of once and for all:
It says "Bad ROM", because the CRC-32 checksum is incorrect.
Your Emulator will automatically calculate the individual CRC-32 checksum of your ROM once loaded and compares it to the number given at 0x81DC (for headered LoROMs, that is). If the result your Emulator calculated doesn't fit to the number at that address, it will say "Bad ROM". Originally, Emulators were designed for unedited ROMs, until ROM-Hacking has been developed. If an original ROM from Nintendo is loaded into the Emulator and the checksum is incorrect, then it is most likely a bad dump, the function is primarily used to find bad dumps.
Editing a single byte in the ROM (not the header, of course!) will make the Emulator say: "Bad ROM".

If you really want the ROM to be corrupted, change [00] at 0x81FC to [4F], for example.
In prospect of a level re-inserter, that would help to decrease the full space of the level data used (it would decrease it, because the data is more concentrated. Sometimes a hacker would leave some unused level space, which is quite a waste, thus reducing the actual used bytes of a field of level space is reduced, too), I've made a small list of level data used by the game:

Level Space
Format
From (First byte used for level data) to (last byte used for level data) (number of bytes)

0x006DD4 to 0x0079A6 (3,027 bytes)

0x087462 to 0x0881A2 (3,393 bytes)

0x08CC15 to 0x08FF86 (13,170 bytes)

0x094909 to 0x09819D (14,485 bytes)

0x0A0200 to 0x0A81A4 (32,677 bytes)

0x0A8200 to 0x0B01CF (32,720 bytes)

0x0B0240 to 0x0B81F7 (32,696 bytes)

0x0CE2A2 to 0x0D00B6 (7,701 bytes)

0x110200 to 0x1112DA (4,315 bytes)

Altogether:
144,184 bytes

Hint: I did not count room index number 38, because it is not part of an actual level. If the "level data" is removed, the intro scene will glitch)
Such a re-inserter could work as following:
It overwrites the formerly used level space with the levels you insert. In case a whole set of levels (00 to DD, 38 excluded) is inserted it easily pastes them all over the place. To use space more efficiently, it could be programmed so, that if it is unable to insert level data into the last, let's say 100 bytes of level space at the end of some former level space, it searches for level data, that is as close as possible to <= 100 and inserts them. Then it continues with the next field of former level data. If the space is not large enough to insert all level data, the program says at which level where it stopped because of spacelessness. It could also ask one whether it should insert the data into some field of free space, then. (If one would use all thinkable free space in the ROM for level data, then each level could consist of ~1,263 bytes.)

Also, I think Romi could easily integrate a raw level data editor into Golden Egg, so the levels to edit aren't loaded together with the ROM, but instead a file containing only the raw level data. As an option, Romi could make the program ask for a ROM to take graphics and palettes from.

But then again, I guess if he is really Japanese he already has enough trouble in real life already. I hope nothing has happened and nothing will happen to him (and of course I hope nothing will happen to all the other people in Japan, who suffer from the catastrophe).
I just found a video of a newly discovered YI glitch that allows opening 1-way gates from the wrong side...

It's quite a major break, especially for something so simple. I wonder if anyone knows how to fix this (to disable it in hacks)? (Maybe by making it so eggs don't open 1-way gates at all?)

–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City
I did the same thing once using a ghost shy guy. You can also use koopa shells. Maybe a better solution would be to enlarge the collision rectangle, so Yoshi can't get too close from the closed side. This way, he could be prevented from throwing an egg "into the other side".
Look how close Yoshi can come to the other side!

Increasing the collision rectangle by 4 or 5 scanlines should solve the problem.

Good thing. Now that it has been discovered by the YI Hacking "Society" we can (hopefully) do something about it.
Change ROM 0x06A167 from 0x30 to 0x80 to prevent enemies/eggs from opening the oneway blockers.

Editing the collision rects also effects other sprites.

A custom sprite like S8E from SMW would work perfectly in this situation.

--------------------
Working on Super Mario World 2 - Yoshis Island Boss Rush
Other projects on hold.
@tehaxor69:
That fix is not good, since it makes, that eggs can always go through the blockers, even from the closed side. This is a big problem in case a ?-Cloud is behind the blocker.
I still think editing the colrect would be the best way to fix that thing, even if that also affects other Sprites. The only thing that should be changed, is, that Yoshi can't get so close to the other side of the blocker, that he's able to throw an egg/spit an enemy to open it.

Also, I don't know anything about Sprite 8E in SMW... What effect does it have?
Originally posted by Yoshis Fan
Also, I don't know anything about Sprite 8E in SMW... What effect does it have?

It's 4 tiles high, and whenever you touch it, you get moved to the right side of it. So when you want to walk through it from from the right side, it just doesn't let you pass it, like a wall.

--------------------
.
Though a sprite like that would make puzzles like the one in the cave portion of the original Secret 6 (using a Chomp Rock to hold open a gate so you can backtrack later) impossible...

–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City
@tehaxor69:
So, could you find out how to enlarge the collision rectangle? I think that would probably be the best solution.

Also, could you find how to change Yoshi's initial number of lives?
Edit: Found it myself using the offset from the save patch earlier. Yoshi's starting life count is at xB9B33 ($179933).

–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City
Okay, the very final question about this subject, will this checksum work properly when you upload an IPS. file? in other words, will people be able to play this despite having an incorrect checksum. thank you and apologizes for excessive questions about the same topic as I want to be assured that the hack will work without any problems.




--------------------

Mickey8715, Please subscribe and comment!
The ROM will work fine if the checksum is bad.
If you want it fixed, drag/drop your ROM on this tool.

--------------------
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
The ROM will work fine if the checksum is bad.
If you want it fixed, drag/drop your ROM on this tool.
Thanks for the speedy reply, So to wrap it up completely, this IPS. patch works, yeah? yi mini hack

--------------------

Mickey8715, Please subscribe and comment!
The checksum has nothing to do with the thing, whether the game works or not. A checksum is, as the name suggests, a sum to check. The thing to check is whether the bytes within the ROM result in a certain number. Changing one little thing in the ROM will change the checksum, so your Emulator says "bad checksum". A (virtual) machine like an Emulator for example is in no way able to tell you whether the ROM is corrupted or not. It simply follows the instructions given by the ROM's ASM code. The Emulator is unable to find out whether they make sense or not.
To make a long story short: Simply don't give a s*** about the checksum!

Also, your hack turns out to be... well... not too good

I've tested the version you've sent to me (which is the same as you present here, no?)
Here are (quite a lot of!!) things, that bother me:
- Glitched Sprites
- Weird level design
- Monotonous passages (f.e. oversized slopes...)
- High, hardly reachable huge platforms with nothing on them...
- Bad Middle Rings
- Plenty of chances to get stuck
- Weird palette choice
- Bad animation settings
- Wrong Sprite-placement
- Wrong Object-placement
- Bad Warps
- Weird Camera-Scrolling
- Wrong Level-Entrance
- Second level suddenly stops at some point(???)
- Missing walls at the level's borders (especially in a castle there should be some!)
- Unusual spelling of level names
- Conceptlessness? (Linearity of levels, lack of puzzles. The question mark is there for a reason, that means I'm not sure whether it's true or not. If this really is just a Minihack, the first few levels must fulfill the conditions of more advanced levels already and that's what I'm missing. In a full hack (meaning 54 levels or more), it's obvious that the first levels don't have real puzzles and are linear)


And once again, I'm asking myself whether you actually test what you produce there.
Everyone SIMPLY MUST, MUST, MUST notice, that there is something wrong with the passages presented in the following two screenshots, just to make an example.

1st screenie: Who would not notice the Shy Guy's wrong position?
2nd screenie: You need the cloud to proceed, so you must have seen it's glitched!

Assuming you really tested the levels, you simply must have played them blindfolded. I mean, missing a minor cutoffness is no big deal, but this?


Originally posted by Yoshis Fan
The checksum has nothing to do with the thing, whether the game works or not. A checksum is, as the name suggests, a sum to check. The thing to check is whether the bytes within the ROM result in a certain number. Changing one little thing in the ROM will change the checksum, so your Emulator says "bad checksum". A (virtual) machine like an Emulator for example is in no way able to tell you whether the ROM is corrupted or not. It simply follows the instructions given by the ROM's ASM code. The Emulator is unable to find out whether they make sense or not.
To make a long story short: Simply don't give a s*** about the checksum!

Also, your hack turns out to be... well... not too good

I've tested the version you've sent to me (which is the same as you present here, no?)
Here are (quite a lot of!!) things, that bother me:
- Glitched Sprites
- Weird level design
- Monotonous passages (f.e. oversized slopes...)
- High, hardly reachable huge platforms with nothing on them...
- Bad Middle Rings
- Plenty of chances to get stuck
- Weird palette choice
- Bad animation settings
- Wrong Sprite-placement
- Wrong Object-placement
- Bad Warps
- Weird Camera-Scrolling
- Wrong Level-Entrance
- Second level suddenly stops at some point(???)
- Missing walls at the level's borders (especially in a castle there should be some!)
- Unusual spelling of level names
- Conceptlessness? (Linearity of levels, lack of puzzles. The question mark is there for a reason, that means I'm not sure whether it's true or not. If this really is just a Minihack, the first few levels must fulfill the conditions of more advanced levels already and that's what I'm missing. In a full hack (meaning 54 levels or more), it's obvious that the first levels don't have real puzzles and are linear)


And once again, I'm asking myself whether you actually test what you produce there.
Everyone SIMPLY MUST, MUST, MUST notice, that there is something wrong with the passages presented in the following two screenshots, just to make an example.

1st screenie: Who would not notice the Shy Guy's wrong position?
2nd screenie: You need the cloud to proceed, so you must have seen it's glitched!

Assuming you really tested the levels, you simply must have played them blindfolded. I mean, missing a minor cutoffness is no big deal, but this?


Eh...Thanks for the in dept definition of the checksum, I appreciated it, but The IPS. patch I provided was no were near ready for final release and I merely posted it for a test, it was not meant for release yet. Of course I have noticed the glitched cloud sprite and incorrect angle of the shy guy spawning pipe, yes I have seen these and the hack is not even 50% complete. If you are referring to the second level's cave passage that stops abruptly, that is a WIP and is not complete. thank you.

And of course I am going to fix the errors and not leave them in the level.

EDIT: Please note, the levels are currently Unstable and not ready for play When it is I will make a dedicated thread for the hack.

--------------------

Mickey8715, Please subscribe and comment!
But what are you expecting from feedback or comments and whatnot, then, anyways?
I mean posting incomplete levels doesn't seem to make any sense to me. What should we do with them? Commenting them or giving feedback must result in something like my last post. And I guess nobody here is willing to fix the bugs/glitches, him/herself. In case you don't know how to fix certain things, feel free to ask for help.
Yes, I see what you mean but I only posted the IPS. patch so I can see if other people are able to play it as I had a difficulty with IPS. patch's in the past as some users may remember...I sometimes refrain from asking too many questions since I have a reputation for that and I don't want too seem like a "noob".

Basically, I dont want to make levels and then find out they freeze when other people try and play them. and could you please elaborate on the Weird palette choices and the Monotonous passages.

i.e which level, passage?

--------------------

Mickey8715, Please subscribe and comment!
You can easily test IPS patches yourself by just applying them to a clean original Yoshi's Island ROM #w{:s}

Well, monotonous is everything unnecessary long flat ground/sloped ground (the slime ground passage on the first screenshot is an example) as well as repetitive passages (for example pushing Flower Pots from edges again, again and again...).

Weird palette choice I found in the castle. Normally, the used palette is only used for regular ground Tilesets (1, 7, 9, F). For the wooden castle Tilset, palettes 0E, 18 and 1A are recommended.
To fix the one way blocker issue

Change:
SNES 0x0A92CC ROM 0x0514CC from 0x08 to 0x10, Collision size set on load
SNES 0x0D9F3D ROM 0x06A13D from 0x10 to 0x18, Collision size set on open
SNES 0x0D9F94 ROM 0x06A194 from 0x08 to 0x10, Collision size set on close

--------------------
Working on Super Mario World 2 - Yoshis Island Boss Rush
Other projects on hold.
tehaxor69! You're back!
I find that great, I must say, I didn't expect that.
Thank you for the Offsets, I will try this immediately.

*Edit*
Thank you alot! It works, the blockers from now on REALLY block Yoshi.
Pages: « 1 232 33 34 35 36 37 38 39 40 41 42 »
Forum Index - Non-SMW Hacking - Yoshi's Island Hacking - SMW2 Yoshi's Island offsets and helpful info

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy