[Updated 06/09/16] 19XXTE 0.11, ROM Hack (Working on Console!)

[Sedda]

removing DL top plat is some peoples's dream

would be pretty cool

 

[Morin0]

That has already been done. I saw a Pokemon Stadium texture that goes over Dream Land (I think) and it doesn't have the middle platform. It's by one of the South American bros.

 

[Respect38]

For Cloudless Yoshi's Island, the blastzones are so close that the characters don't even go into the bubble/magnifying glass before being KO'd. I'd love to increase the side blastzones and remove the top platform, but that's not feasible right now anyways.

Oh, I see what you mean now, but this is actually a problem that could have a temporary [or even preferred, possibly, as it makes no gameplay changes] solution by applying a modification of the Widescreen code [812471F4 3F94] to the mod. Everything stays the same except for the fact that the screen horizontal distance is changed so that the magnifying glass actually does pop up prior to the blast zone, in most cases. [and, if there are still any scenarios where the blast zone still shows up prior to the magnifying glass could be fixed by changing the hex value until a satisfying one is found. Or it could be moved in the other direction if it's too intense...]

Edit: In fact, I'm pretty sure that the code is needlessly intense. 3FA0 [or maybe even higher, but this is probably getting close to the edge] would be better than 3F94.

Edit V2: Of course, 3FA0 is the upper bound of the "recommended" area, and this is the area where the magnifying glass and blast zone begin to nearly overlap consistently. On the other hand 3F60 seems to be a lower bound which provides a more standard blastzone-to-glass distance when compared to Dreamland [and other stages]. It really comes down to what will likely be a compromise between 3F60 [for standardized magnifying glass scenarios] and 3FA0 [for minimal impact on the rest of gameplay]. Perhaps the values surrounding 3F80 aren't *that* bad of a compromise, after all...

Note... that "modification of the Widescreen code" is missing the second line that appears in that code. I'm unsure of the affect of the code from my testing, so, if I could find out the purpose of that line, the "fix SYI" code could be adapted to be even more useful.

Also, another unrelated note, this code and be modified and applied to all stages. Which means that you can make a Mushroom Kingdom without bubbles before the walk-off, you can make a Tutorial Stage that isn't as messed up by the camera issues, as well as modification to MC/FD/BF to give more perspective of the sheer size of the blast zones. Of course, because these require stretching the screen, I assume that this would pull the game off of most screens, so unless the extra line of code for the Widescreen GS code is useful, none of those are practical right now. [as far as I know. Might be worth testing them on console to see if that *is* exactly what happens. Because this would happen on the fix SYI code, but in reverse, figuring out what the other line of code was for is important.] I feel like the Tutorial Stage would become competitively viable if that were the case, but it would come down to a question of how it would affect the meta and whether or not any potential gains [assuming there are gains] are worth having a stage that has offset blast zones.

Edit: I've been playing the Tutorial Stage with a 3FD9 value, which isn't too far off the Widescreen code, but I think just copying the Widescreen code leads to too many situations where you blatantly go off the blast zone within the view of the camera. 3FD9 still sometimes has the problem, but it's a trade-off that has to be made in order to slightly alleviate the problem that the camera on the left side can be.

I kinda stopped thinking about the code for a while (since I didn't pay much attention to smash for a while), but I've started working on it in the past week. It really shouldn't be too hard to write, but I'm lazy and easily distracted by new ideas. Since I know someone's paying attention, maybe I'll stay focused now.

Yeah, that would be sweet. I think it would be amusing, at the least, if the community decided to legalize Metal Mario, because, if SSBWiki is to be trusted, Metal Mario is just Mario with much worse matchups. [however, they claim that Giant Donkey Kong, on the other hand, is consider superior to Donkey Kong.]

For stage hazards, yeah it might be possible, but I feel that in order to have an elegant code, we'd probably want to know more about how the stages are structured in code. And once we start figuring that out, there's a lot more interesting stuff you could do. (Though you might be able to end up with a stage hazard toggle....)

I've heard that there are codes for some of the hazards, but, of course, the problem is having them only situationally be active.

Are you under the impression that I messed with the blastzones? That's not the case. I'm only loading different stages.

No, of course not! I was merely giving my opinion in response to Dark Horse, when he said:

"the spawn points are irrelevant. we can just move to neutral positions at the start. no biggie.

what would be nice to see:

someone make DL without wind or top plat
make the BF stage ledge di-able
increase size of blast zones on 1p yoshis"

Sorry for the misunderstanding.

I'm not going to change any stage that's already legal as this could lead to a division in the community. Instead, I add features that don't interfere with the game being tournament ready.

Yeah, I agree. That's why I mentioned the "two versions of the stage" thing.

 

[Dark Horse]

We didn't see any issues DI'ing the BF ledge...

 

[CAVEM4N]

Okay so I am getting bummed out. I keep trying to load up 19XXTE on Project64 1.6 and Project64KVE and it crashes both of of them every time I go to the start screen. Help T_T THIS IS THE HACK I HAVE BEEN WAITING FOR AND I HAVE BLUEBALLS NOW

edit: Fixed <3

 

[T Brett]

lol this made me chuckle, thanks cavem4n

Help T_T THIS IS THE HACK I HAVE BEEN WAITING FOR AND I HAVE BLUEBALLS NOW

edit: Fixed <3

 

[tehz]

Writing these codes for Melee/Brawl is nothing because you have the ability to write your own functions in empty memory and then just add branches to them. To do the same thing on N64...well you can't (at least I don't think so). I have to just come up with efficient ways to rewrite code in hopes that I can squeeze out one or maybe two more lines.

For example, the debug menu is completely done visually but in order for the toggles to work, I have to write conditional statements in MIPS. Well I can't do that yet. I've been researching as much as I can but I haven't found the light yet. It's kinda hard to give a good ETA on 0.6 because I just don't know when I will. Sorry guys.

Whoops just saw this post, so you've probably already figured out how to do this, but for anyone else: You can still write (and jump) to functions in empty areas of memory. You just have to make sure that those empty areas of memory are (a) in the ROM and (b) are DMA'd over into RAM whenever you want your function to run. If your function is small enough, you can just put it into those empty areas. If not, you can write a small function to DMA your main function from where-ever on ROM into where-ever there's space in RAM. (I haven't had to do this yet, but it should work...!)

 

[Cyjorg]

Whoops just saw this post, so you've probably already figured out how to do this, but for anyone else: You can still write (and jump) to functions in empty areas of memory. You just have to make sure that those empty areas of memory are (a) in the ROM and (b) are DMA'd over into RAM whenever you want your function to run. If your function is small enough, you can just put it into those empty areas. If not, you can write a small function to DMA your main function from where-ever on ROM into where-ever there's space in RAM. (I haven't had to do this yet, but it should work...!)

This changes everything (insert gif)

 

[Cyjorg]

Note... that "modification of the Widescreen code" is missing the second line that appears in that code. I'm unsure of the affect of the code from my testing, so, if I could find out the purpose of that line, the "fix SYI" code could be adapted to be even more useful.

You're right. I'm missing one of the codes. I didn't notice a change so I didn't include it. Have you been playing with both codes on and if so does that fix the bubbles?

I've heard that there are codes for some of the hazards, but, of course, the problem is having them only situationally be active.

Yeah, I agree. That's why I mentioned the "two versions of the stage" thing.

This still adds division. However, after seeing tehz post above, a debug menu flame has been reignite. Long story short, MAYBE.

make the BF stage ledge di-able

Shears and Dark Horse claim this problem doesn't exist. I don't even full understand the problem to begin with. Someone knowledgeable explain.

increase size of blast zones on 1p yoshis"

someone make DL without wind or top plat

I guess I can add studying stage formats to my list of things to do. @NOKAUBURE has a code that modifies stages already. I'd just have to implement it.

...

I'm very excited to continue working on this project but I'm a busy guy. I'm a CS major taking 18 credit hours and I'm in a frat. Time isn't something I have an infinite amount of. So while progress will be made, I can't promise super fast results.

 

[Shears]

You're right. I'm missing one of the codes. I didn't notice a change so I didn't include it. Have you been playing with both codes on and if so does that fix the bubbles?



This still adds division. However, after seeing tehz post above, a debug menu flame has been reignite. Long story short, MAYBE.



Shears and Dark Horse claim this problem doesn't exist. I don't even full understand the problem to begin with. Someone knowledgeable explain.




I guess I can add studying stage formats to my list of things to do. @NOKAUBURE has a code that modifies stages already. I'd just have to implement it.

...

I'm very excited to continue working on this project but I'm a busy guy. I'm a CS major taking 18 credit hours and I'm in a frat. Time isn't something I have an infinite amount of. So while progress will be made, I can't promise super fast results.

BF is fine, we played a tournament on in last week and when people ledge DIed, they just bounced up normally, and sometimes better, than on DL. The only "problem" with it is that its much easier to end up below it when trying to recover. Not a big issue really.

 

[tehz]

Good to see I could motivate you jorgasms. Now, if only I had made that post in summer when you had free time haha.

Here are my two hypothetical resources for DMAs:
DMA Registers
Example Function for SSB (!) [This must've been @novakain hehe; initial function is wrong but zionkitty points out things]

Now, back to day-dreaming about how to replace one of the buttons on the SSS with a "Page 2" button.

 

[Respect38]

You're right. I'm missing one of the codes. I didn't notice a change so I didn't include it. Have you been playing with both codes on and if so does that fix the bubbles?

The first line of the Widescreen Code affects the width of the screen, and that is sufficient to fix the issue on SYI, and enough to help the problems on the Tutorial Stage to the point where it would be competitively viable.

There might be a code that affects the height of the screen, but it certainly isn't the second line of the Widescreen Code [unless I'm doing something wrong] and the only affect it would really have would be to make the aspect ratio of the game return to normal [if we change the width of the screen, we need to change the height of the screen by the same amount, but I don't have a code to change the height. I'm sure one exists, though, but I don't know how to search for it to make a Gameshark code out of it]

That said, would it be possible to go ahead and add the Tutorial Stage to 19XX? Since the fix code can be applied via Gameshark, they'd be able to play it at Xanadu immediately even if you didn't change it, just because of the fact that they could apply the Gameshark code to the stage and it wouldn't be that bad.

This still adds division. However, after seeing tehz post above, a debug menu flame has been reignite. Long story short, MAYBE.

How does it? I don't think you're misunderstanding me, but how does giving the community either option (+wind or -wind) and letting them discuss among themselves which version to use in tournaments cause a division for the mod?

Shears and Dark Horse claim this problem doesn't exist. I don't even full understand the problem to begin with. Someone knowledgeable explain.

I guess I can add studying stage formats to my list of things to do. @NOKAUBURE has a code that modifies stages already. I'd just have to implement it.

My statement was in particular, to the request to expand SYI's blast zones. Since there is a solution to this that can be applied via Gameshark codes, this isn't much of a problem--although it would be nice to have a code to change the height of the screen so it doesn't end up unevenly streched. You don't actually have to change SYI's blast zones.

Edit: Although, if anyone has access to 19XX on consoles [in a similar setup to Xanadu] it would be awesome if they could test the codes to see how much they throw off a competitive player.

 

[KnitePhox]

you can already remove the top plat of dreamland with gs

widescreen makes stage and character proportions weird on console iirc

 

[Cyjorg]

so the widescreen code works as it should. I just checked the addresses Respect38

 

[Respect38]

so the widescreen code works as it should. I just checked the addresses Respect38

If you could tell what "as it should" means, that'd be nice. Does the other line of the code actually impact how much the screen stretches vertically? It never did work on my emulator, but for some reason now the entire code is broken for me, so I guess that's just a problem on my side.

Nevertheless, using the first line of the widescreen code [with a different hex value] should work fine as a quick fix to SYI, but for some reason the game crashes for me when I try to play Metal Cavern with both the fix SYI code and fix Tutorial Stage code active, so until someone can confirm this happening on console, adding the Tutorial Stage isn't a priority, although I still feel like it should have priority over Sector Z.

 

[Cyjorg]

If you could tell what "as it should" means, that'd be nice. Does the other line of the code actually impact how much the screen stretches vertically? It never did work on my emulator, but for some reason now the entire code is broken for me, so I guess that's just a problem on my side.

Nevertheless, using the first line of the widescreen code [with a different hex value] should work fine as a quick fix to SYI, but for some reason the game crashes for me when I try to play Metal Cavern with both the fix SYI code and fix Tutorial Stage code active, so until someone can confirm this happening on console, adding the Tutorial Stage isn't a priority, although I still feel like it should have priority over Sector Z.

As it should means the aspect ratio is correct for widescreen.

The code changes a 32 bit float. It's literally 1 number. For example 3f800000 = 1. The first code writes the first 4 numbers and the second writes the rest. You don't see much change with the second code because the values are far less significant.

I didn't do the math but I'm going to assume Danny_SsB did for the aspect ratio.

The gameshark codes your using are only supposed to be activated when you're playing that stage. You can't have multiple activated at the same time.

I'm not adding the tutorial stage. It has issues that you've pointed out and it's not a great stage to begin with.

 

[Respect38]

As it should means the aspect ratio is correct for widescreen.

The code changes a 32 bit float. It's literally 1 number. For example 3f800000 = 1. The first code writes the first 4 numbers and the second writes the rest. You don't see much change with the second code because the values are far less significant.

I didn't do the math but I'm going to assume Danny_SsB did for the aspect ratio.

Thanks. That explains a lot. So the code changes both the height and width then--I should have noticed that. Silly me.

The gameshark codes your using are only supposed to be activated when you're playing that stage. You can't have multiple activated at the same time

I was starting to think that this wasn't the case, considering that Danny_SsB's explanation was:

"Graphics errors or the game will freeze may occur"

Which seems like an issue that would have a solution, since, as I've stated, I only had an issue trying to access Metal Cavern. Whatever is causing the freeze has to be something Metal Cavern specific, and I wouldn't be surprised if it was something that wasn't manageable.

I'm not adding the tutorial stage. It has issues that you've pointed out and it's not a great stage to begin with.

It has issues, sure, but those issues are things that, at the worst, make it slightly competitively jank. However, this is a Tournament Edition of 19XX. Its competition is Sector Z. Sector Z is worst than competitively jank, it's competitively unviable. While I could envision a ruleset where the Tutorial Stage was a element in creating a more healthy meta, Sector Z simply cannot, because its issues will be hard to overcome. Perhaps you could work with it to make it better, but the amount of effort you have to go through to make tournaments consider adding Sector Z is way more than the work you'd have to do for the Tutorial Stage. For a TE of a mod, why would we give priority to a universally banned stage over a stage that could possibly be a counterpick at worst, and a neutral if the community gave it a chance?

Also... if there's ever a permanent fix for the camera on SYI, it would likely be applicable here as well, and we could completely do away with the camera issue. Would we still oppose the stage then, since your issue with it seems to be a dislike for the stage's mechanics?

 

[Madao]

will we be able to remove the hazards completely [wind, tornado, acid, POW block, piranhas, arwings, and Pokémon] or, otherwise, would it be possible to minimize the damage and knockback they do by messing with their associated values?

Yes stage hazards should be easy to remove. For example, here's a code that disables DreamLand wind 81105C02 0000 . This could easily be patched into a ROM. Although it may need more testing before being used on console. I say that because sometimes, code might be used for more than one thing. Now that we can decompress and recompress it back, editing damage is possible as well, for stage hazards.

For Cloudless Yoshi's Island, the blastzones are so close that the characters don't even go into the bubble/magnifying glass before being KO'd. I'd love to increase the side blastzones and remove the top platform, but that's not feasible right now anyways.

Blastzones should be easy to patch, unless the data is used for other things too. One example of a variable that seems to be shared is the hitstun formula multiplier. Changing that number seems to make the game buggy. I think according to @Danny_SsB there was a variable near the location of blastzones that had to do with the camera thing. I'll have to check it out. Anyway, I'm pretty sure I collected and posted all the spawn coordinates, besides maybe stages like FD in VS mode. As for removing top platform, we need to learn more about stage data, maybe experiment with the existing stage codes to figure out more.

 

[Obskore]

i have an idea.
would it be possible to scrap/replace the ugly Beta Dreamland stages (use their slots for something useful) in favor of new or altered stages? like the suggested no-top-platform Dreamland with no wind and single player Yoshi's

 

[Grahamaglam]

i have an idea.
would it be possible to scrap/replace the ugly Beta Dreamland stages (use their slots for something useful) in favor of new or altered stages? like the suggested no-top-platform Dreamland with no wind and single player Yoshi's

I will fight you if you say another bad thing about Kirby Beta Stage 2.

 

[tehz]

Blastzones should be easy to patch, unless the data is used for other things too. One example of a variable that seems to be shared is the hitstun formula multiplier. Changing that number seems to make the game buggy. I think according to @Danny_SsB there was a variable near the location of blastzones that had to do with the camera thing. I'll have to check it out. Anyway, I'm pretty sure I collected and posted all the spawn coordinates, besides maybe stages like FD in VS mode. As for removing top platform, we need to learn more about stage data, maybe experiment with the existing stage codes to figure out more.

I've been reading over the Melee Stage Documentation (since I'd think that 64 and melee probably share a fair amount of internal structures etc. due to the quick turnaround time between the two games), and camera lines are literally the next thing in the stage object tree after blastzones, so it'd make a lot of sense that those two values would be close together in 64.

As far as patching goes, it'd probably be really easy, but I'd imagine that those values would be in the compressed parts of the rom. I know that guy perfect found where in the ROM the player spawn points on FD are, so if I wasn't so lazy, I could just look up where those values fall in the filelist and if that file (which would presumably be the "FD Stage File") is compressed. Then, I'd guess I'd want to start looking into documenting that file, although it might not be a good idea due to FD not being a "finished" stage. idk.

Edit: Did you ever finish your File Re-Packer?

 

[Madao]

I've been reading over the Melee Stage Documentation (since I'd think that 64 and melee probably share a fair amount of internal structures etc. due to the quick turnaround time between the two games), and camera lines are literally the next thing in the stage object tree after blastzones, so it'd make a lot of sense that those two values would be close together in 64.

As far as patching goes, it'd probably be really easy, but I'd imagine that those values would be in the compressed parts of the rom. I know that guy perfect found where in the ROM the player spawn points on FD are, so if I wasn't so lazy, I could just look up where those values fall in the filelist and if that file (which would presumably be the "FD Stage File") is compressed. Then, I'd guess I'd want to start looking into documenting that file, although it might not be a good idea due to FD not being a "finished" stage. idk.

Edit: Did you ever finish your File Re-Packer?

Nice, maybe I should look at Melee Stage Documentation.

For patching, all you have to do is decompress ROM, find the location of the data you want to change, edit it & save, compress the data again, then use a file inserter or manually paste it in. Thankfully, compression isn't a big issue anymore. I haven't yet ran into a case where the new size is bigger than original, but I haven't done too much editing. I'd like to leave these kind of tasks to people who say they would like to help but don't know how. These tasks are generally easy to do, but just take work to do. In this case, the hardest part is just finding where the data is. If no one is able to find where the spawn coordinates are located in the ROM, I can look for it next week.

Zoinkity made a file inserter, so thanks to him, we have that covered.

I really think it would be nice to start documenting the files! I'll try seeing if there's an existing wiki with documentation.

 

[THE_MAAFIA]

How to play stage is great, just needs blast zones fixed. And I like what your doing, not changing characters/stages because it would divide community, this mod should be an add on of stuff to the original. I was actually gonna do something similar to this, but I was very inexperienced, I hope you continue this and do wonders btw my friend fray some how changed the coding for fox to shoot links boomerangs (the amount of boomerangs fox can shoot is too funny) and he also changed fox's laser to blue, if you give us your Skype we can add you in and see if we can help

 

[Cyjorg]

How to play stage is great, just needs blast zones fixed. And I like what your doing, not changing characters/stages because it would divide community, this mod should be an add on of stuff to the original. I was actually gonna do something similar to this, but I was very inexperienced, I hope you continue this and do wonders btw my friend fray some how changed the coding for fox to shoot links boomerangs (the amount of boomerangs fox can shoot is too funny) and he also changed fox's laser to blue, if you give us your Skype we can add you in and see if we can help

My Skype is also jorgasms

 

[Indefa]

I understand like %30 of all the technical talk that happens in this thread but %100 of it makes me happy seeing the potential of this rom.

 

[Dark Horse]

when someone says "oh, that's already a gameshark code," does that mean it would be an easy thing to bake into the 19xx rom?

 

[Cyjorg]

when someone says "oh, that's already a gameshark code," does that mean it would be an easy thing to bake into the 19xx rom?

Depends on the gameshark code. Most of the time, I can easily implement one.

 

[Dark Horse]

Depends on the gameshark code. Most of the time, I can easily implement one.

I only ask that because apparently no-wind and no-plat DL are GS codes

 

[Kart8Smash4]

Well, I got the injection working. The issue was the rom that I was using.
The widescreen worked in Wii64, but the injection is not widescreen. Anyone else run into that?
Also: Am I the only one that prefers C stick smashing for Smash64?
One more thing: Are any of the people working on 19XXTE also working on Reality64?

 

[Cyjorg]

Well, I got the injection working. The issue was the rom that I was using.
The widescreen worked in Wii64, but the injection is not widescreen. Anyone else run into that?
Also: Am I the only one that prefers C stick smashing for Smash64?
One more thing: Are any of the people working on 19XXTE also working on Reality64?

Please do not talk about illegally obtaining roms in this thread.

 

[Kart8Smash4]

Please do not talk about illegally obtaining roms in this thread.

I didn't. Personally, I own three copies of Smash64, and I'm willing to bet all three that at least ninety percent of people looking into the rom also own it.

 

[Capos]

I didn't. Personally, I own three copies of Smash64, and I'm willing to bet all three that at least ninety percent of people looking into the rom also own it.

How many of them are you willing to bet that you don't fully understand how copyright law works?

 

[kamagitheboilerman]

Any chance for a Mac version? Or suggestions on how to run the .bat file on a Mac? Thanks in advance.

 

[Shears]

We need Kirby Beta 2 on here for our low tier night in 2 weeks.

 

[dahuterschuter]

This is so wonderful.

 

[THE_MAAFIA]

Bring back the "No contest" screen, sucks without it

 

[CowlScatman]

I cant get this to start using Project 64. When i choose a character it wont do anything afterwards so i cant select the stage.

 

[MarthZ]

I don't think there's really a reliable way to play this on a wii. I use wii 64 for normal smash 64 and it lags up some and has some graphical glitches.

 

[KnitePhox]

We need Kirby Beta 2 on here for our low tier night in 2 weeks.

i dunno if its the same on a modded rom, but kirby beta 2 freezes the game on console as soon as any player loses a stock with gameshark

 

[Shears]

Well we haven't been able to get the gameshark on the EverDrive to work anyway. If anyone knows how to use the EverDrive gameshark please let me know.