Brodeur30

What cha gonna do when Hulkamania, NHL 94, and the Fighting Patch Run Wild On You BROTHER!

I'm thrilled to report, that with help from chaos, that these codes can be found and edited successfully in roms with Fighting. Apparantly what happens is that the area that these codes exist get duplicated to another area of the rom, and it's there that you can make successful edits. For example, the First Code, For the Top Net : Top Left quadrant X-position, the 2-byte code FFE8 that is found at 0xA16BA on non-patched roms, can be found at 0x2057F6 in a Fighting patched rom. This is a very important discovery for anyone interested in using these codes on a Fighting Patched Rom.

I haven't applied the Fighting Code to any roms myself but in trying to test these codes on roms that have, I have encountered the issue of not being able to use these codes on those roms. I guess I'm just trying to understand how moving the frame data might limit the use of other codes that utilize this area. But I would stress that in the roms that the Fighting Code has been applied, the data itself in the rom is still present at these addresses only editing it no longer causes the change to occur. If it were simply a matter of finding a new address and adding that new address, then that wouldn't be a problem. I haven't really gone through what you went through with the FIghting Code to fully understand how that works. But if there is a way to use these goal moving codes on roms that the Fighting Code was applied, that would be very good. I don't know if this is something that could be amended with the Fighting Code to retain the use of such codes but something is currently blocking these codes from working on roms with Fighting Enabled. If you have any suggestions on how we might get these codes to work with Fighting it would be important. And I would be intersted to know if you think there are other codes in the rom that might be affected as a result of having Fighting. I wonder if, for example, I made some edits to these goal movement codes to a rom, putting the goal parts in a unique position, and then applied the Fighting Code, if the new arrangement would be retained or if it would revert back to the original placement. Only one way to find out.

I've been doing a lot of testing of these codes, on various roms, and I have come to some conclusion that something in the Fighting code disables the use of these codes. In my experience, it doesn't seem to be the expanded rom or widescreen mode that causes these codes not to work, but rather the addition of the fighting code. However, on roms without Fighting added, these codes work very well and you can do a lot with them. For my purposes, I have made some meaningful edits to the top and bottom goal art, edits that aren't possible any other way. And I have an important update to the original post, to issue some clarity for Bottom Goal codes. As I explained in my previous post from a while back, what happens when you use these codes on the top goal is that when you adjust the quadrants inward, the 4 quadrants converge on themselves, with the top two quardants a layer above the bottom two quadrants. This is interesting and makes a lot of sense given my experience with making goals smaller. If you try to make the goal smaller through these codes, for the top goal in particular, it would require deleting some of the tile pixels for the top part of the top goal, the top two quadrants, namely the bottom edge pixels of the top two quadrants so they don't cover the bottom two quadrants after you move it downward, which would be over the top part of the side posts. Through additional testing of the bottom goal codes, I've discovered is that while the top goal has these 4 quadrants as described, the bottom goal only has 2 quadrants, each whole side. With the Top Goal's bottom left and bottom right quadrant codes, these are essentially each side post part along with its accompanying side netting, able to move independently in any direction, which is below the layer of the top two quadrants. With the bottom goal however, you don't have this quirk that the top goal has, and what I've found is that you can move each side of the bottom goal (entirely) by Adam's First Two Sets of the Bottom Codes Alone. So, for the purposes of adjusting the Bottom Goal, these two sets of codes do everything you need to do for the Bottom Goal : So for the Above Codes from the Original Post for the Bottom Goal ^^^ it's not exatly the Top Left and Top Right Quadrant, these first two sets of codes represent the Entire Left and the Entire Right Side of the Goal that you can move. That means that these codes Below do not appear to do anything to the Bottom Goal, which perhaps is why Adam couldn't verify them : ^^^So, unlike for the Top Goal, there is no Bottom Left or Bottom Right quadrant for the Bottom Goal like there is with the Top Goal, where the side posts and side netting can be moved independent of the top parts of the goal. For the Bottom Goal, all you need is these two sets of codes : 0xA16DB / 0xA16DD These Two move the Whole Left Side of the Bottom Goal Left / Right and Up / Down respectively. 0xA16E3 / 0xA16E5 These Two move the Whole Right Side of the Bottom Goal Left / Right and Up / Down respectively. It's important to look at each default value as a 2-byte code, and adjust from there. For both the Left and RIght Side Y-Position Code, the 2-byte default value is FFE6. The way it works is if you increase the E6, it will move Each Side of Goal Down, and if you decrease the E6, it will move Each Side of the Goal up. So to move the entire Bottom goal up or down a set amount of pixels, you increase or decrease both 0xA16DD and 0xA16E5 to the same value. But, unlike the Top Goal, you can't adjust the top bar's height in relation to the side posts, as it all moves together as one, on each side. To illustrate on a Medium Size Bottom Goal that I'm working on : (with each side Y-Position code as a different value) For all intents and purposes, these are adjustment codes, as they do not appear to affect the collision barriers, which remain at or near the original placement of the goal art. The value is that these codes can make micro adjustments to the goal art's position when the barriers are not aligned to your liking. (for example, if a puck is bouncing off an invisible barrier a pixel or two off the post, you can use these codes to move the goal art so that it will hit of the post where the post actually is) The reason why it's important to look at these codes as 2-bytes instead of 1 byte is beacause of what happens if you increase beyond FF, or beyond FFFF the full code. For example, for the Bottom Goal's Right Side X-Position code 0xA16E3, the default value is FFFF. So to make the right post slightly wider, for example, by 1 pixel lets say, you "increase" the FFFF to 0000. This is exactly what I just did for one of my roms where the bottom goal was slightly narrower than the top goal on the right side. I used these codes to align the top and bottom goal and to make the art more accurate to the barrier code, and to align the bottom goal posts with the top goal's posts which were slightly off. Note that you can't actually do this by just editing the tiles because it mirrors the tiles to each side. With these codes you can make that 1 pixel micro-adjustment to just one side of the goal, which solves the "always a pixel off one way or the other" problem that you'll notice if you pay close attention. Note that when you use the X-Position codes for the Bottom Goal, it moves each entire side of the goal left or right, which changes the alignment at the middle of the goal. So if you make the goal too wide, for example, through these codes, by more than a pixel or so, you'll notice that the two sides of the goal will disconnected at the middle. Here you'll see what happens when you use the X-Position codes to make the goal art wide : See how the bottom one is split at the middle into two parts. You'll see in this one that the goal itself is wider, but it disconnects at the middle. This is what happens when you make it too wide by adjusting the X-Position codes. But in my case I needed it to be slightly wider to get it aligned, both with the top goal's post and with the barrier code, so I may need to go into the tiles to try to re-join it at this wider size through the use of these codes. Meaning, go into the tiles and try to extend the artwork at the middle so this slightly wider goal can be re-joined at the middle. It's something I might have to do, depending on which barriers code I use to ensure accurate art and barrier alignment. More testing is needed as I continue to develop the medium goal and apply it to various roms and these codes are very useful for my purposes. I'm really deep into this stuff so a lot of this stuff might sound complicated, but it really isn't. The main purpose of this post is just to clear up the confusion about how the bottom codes work and that you don't have 4 separate quadrants like the top goal, you only have two, each full side of the goal. I can't stress how valuable these codes to fine-tuning misaligned top and bottom goal art, or to slightly adjust as needed if the barriers are off. Meaning, if when you're playing, you notice that the puck isn't hitting the post where it should, at the correct pixel, you can use these codes to bring the collision into alignment. Now if we can only get these codes to work with Fighting Enabled.

@AdamCatalyst Yes I am very interested. It would be fun to see what you've come up with. If you've found parameters like z-axis arc, hotspot location, zone thresholds, specific player applicability and if those can be set to "lock in" a specific arc (in the rom?) or could there would be a button mechanism (RAM code?) that could angle the flip pass to a specific player on the fly, then we could really develop this. The other day I thought about the control scheme in NHLPA93 compared to 94 and how in NHLPA93, the A button only Changed Lines it didn't do clearances. Now if we can find the A button code area in NHLPA93 that would have changed in NHL 94 to have the clear puck / flip pass feature added, then we might be able to simply transmit the code from NHL93PA into 94 (similarly on some level to how Fighting was taken from 93 and implemented in 94) to make the A button only being about line changes. In finding the 93 code for the A button, then comparing it to code for the A button in 94 we should be able to find the part of the code that is missing in NHL93 (Clear puck / Flip pass) and put that part of it on a dedicated button. So there's a number of ways to go about this depending on what your goals are. With the kind of parameters you've found it would be interesting to see what you've been able to achieve and if there is anything that you are still trying to learn how to do.

The Goalie A-button "long pass" has a lower trajectory than when skaters press A-button in their own zone to do a clearance. It has more of a line drive to it. In later games and especially in NHL 98 they made modifications to the controls. In NHL 98 for example, instead of a flip pass when you enter the opponents zone, A-button does a deke. Before crossing the blue line it does a clearance in 98 however the clearance height and arch is very different than it is in 94. The changes to the controls, subtle or major, between NHL 94 and the later games provide a blueprint to the kind of controls that we should be able to get into NHL 94 by looking at how the controls changed. Anotherwords finding the same area that controls the A button function in the other NHL Genesis games to see what changed to produce the updated controls. It would be fun to be able to trigger that Deke move from 98 in 94, or the offensive speed burst, both with the puck or without. What fascinates me is the possibility of being able to fine tune the height and arch of A-button clearances / flip passes to our liking, to perhaps make them more like the Goalie A-button "long pass" or more like how they are in other games like 98. For example it would be interesting to have the slightly lower style clearance from 98 in 94 but for when you cross the blue line. (Keeping the standard 94 high arching clearance when in your own zone) There would presumably be certain parameters, separate from the line that would need to be edited to move Line Changes off A to a new button, that would determine what the height and arch of A button clearances / flip passes. Something else I noticed that maybe you've seen before is what can happen if you press A right at the moment when the clearance changes to a flip pass, when you cross the blue line. If you time it just right and press A just as you cross the blue line, it will produce a super high arching clearance / flip pass hybrid of sorts. Try it, it might take you a few attempts get it, but if you press A just when you cross the opponent's blue line, it will do like a super high arching one which is pretty cool. Being able to trigger A button puck tosses of various angles and lengths would be very rewarding and would add a lot to the gameplay depth.

I have had much difficulty with Retro Arch as well. In my case trying to use their code searching / finding system and doing other tasks within the emulator. There is a lot going on in the front end of Retro Arch and isn't the most user friendly of emulators. I would offer a recommendation for you to try the Ares emulator. https://ares-emu.net/ This is what I have been using lately v147. It works very well with Genesis and offers many shaders built in. Notably the Mac version has a good variety of aspect ratios that you can achieve in full screen along with other window / sizing options. Overall I find Ares to be a very well designed emulator and far more user friendly than Retro Arch. Now there are some features that Ares might not have, and it would depend if you need that, but if you're hex editing roms and testing changes one after another it's better to keep your controls consistent. Ares also has a built in memory viewer which is organized in a useful way. On the Mac version I have had some issues actually using the Ares memory viewer as an editor / making changes to bytes but just having it there is very helpful to find codes and see how codes change. Compared to Retro Arch for example there is no memory viewer like there is in Ares and it is not as user friendly. So for a more civilized emulator I highly recommend Ares. And if you use it, please give a review and let me know if there's anything other emulators have that Ares doesn't or does better.

In some cases it would be better to edit the existing buttons and stay within the 3 button framework. Especially in the case of the Fake Shot where it is very natural to use the B button to cancel. It is important to remember that there are only 3 additional buttons X Y and Z. That means the more that we can apply to the standard 3 button controller the better. But if we could move the Line Change switch off of A and on to X for example, that could free the A button up for more advanced actions by holding down the button longer without worrying about bringing up the Line Change switch. I'm not sure I understand what you're saying here. Are you referring to a CPU controlled team or a Human controlled team? I see no difference to the action whether I am on a PK or not. If I tap A behind the opponent's blue line he'll do a clearance. If I tap A in the attacking zone, he'll do a flip pass. What I would like to do is make it so that you can do "clearances" in the attacking zone, and conversely flip passes in your own defensive area. And to see if we can customize the clearance / flip pass length and perhaps tie the length to how long you hold down A. At least inside the attacking zone lets say. Outside we might want to keep the clearance working as it is, but inside the attacking zone we might rather utilize the clearance as the default. So it might be as simple as just "removing the check" for when you enter the attacking zone, so the game still think's your behind the opponent's blue line, which causes the clearance to trigger. Clearances in the attacking zone would be effective because you could launch high arching lobs over the goal from one side to another. Currently you cannot do that, there would surely be a flag that altered the A button action depending on where the player is are on the ice, either beyond the opponent's blue line or not. If that check could be edited we could allow Clearances in the attacking zone, or customize the length of the clearance when used in the attacking zone but still farther than the flip pass. The idea is to make edits similar to what McMarkis did with the Fake Shot but for the A button. I will be taking a closer look at the specific code that would be needed to edit this related to the A button. But I do think some brainstorming is needed as to how we could best design this. Should we make use of the additional buttons, X for example, to try to shift the Line Change function off the A and on to X as a separate button, or should we start just by trying to edit the A button itself? It might be easier to edit the timing of the A button holds and edit what type / length of action occurs in or outside of the attacking zone. It would be very rewarding to make a meaningful improvement in this regard.

After further testing of these codes, particularly the top goal codes, I can confirm that you can take any normal goal art and converge it inward as you described and the upside down U shaped top goal art moves in over the uneditable area. So I want clear up any confusion. As far as what I said earlier, it is true that these codes can be used to align the goal art with the goal line on the ice, but these codes do not appear to affect the barriers as I implied. But more testing is needed to fully confirm this. It has been quite a while since I've been modding NHL 94 so I'm trying to remember everything that I had previously learned. Extensive testing is needed to see how a converged normal goal art through only the codes above interact with a lower barrier code. In some cases, the barriers code may have a different geometry of the scoring area that would require some manual adjustments to the goal art in tile layer pro but that remains to be seen. I'll have to test your latest rom to see what your barrier interaction is like. But for context, the way I did my smaller goal rom was not by using these codes primarily, but by drastically editing the normal goal art to go beyond the normal editable boundary, which caused the side posts to be deleted in the goal art and I made them reappear through rink art of those pixels. That's why when the net is knocked off its moorings in my rom the side posts stay in place and only the top part of the top goal moves. This unique way that I achieved that wasn't exactly the most straight forward way but at the time it was the only way that I knew how. And perhaps by using only the codes above combined with the barrier codes you'll be able to have an more straight forward way of reducing the size of the goal art, but no matter which way you do it, micro fine turning of these codes in combination with the barriers code are crucial to getting the puck to hit the post or if it does go through it misses at the exact pixels that the post art is at rather than becoming a goal. And that means, in practice, to adjust the goal art to the barrier, and that is done by testing, viewing slow mo replay of near misses, when it hits the pits, when it bounces of the back of the net, etc. And in the case of converging the quadrants as you described it would still require manual goal art editing to delete the parts that converged upon itself. Example : As you can see, through your codes you can bring in the normal side posts into the inner area that is normally off limits to editing. As in, you cannot "move" those side posts into that inner area and be that narrow as shown above just by editing the tiles. But through the X-position codes, you can bring the side posts into this area,, which is obviously hugely important and was something that I didn't know about when I made my rom. I discovered these codes but it was after I had already designed it via the other method. Notably, as you can see from the screenshot, when converging, it seems that what happens is that the top goal art shows up "over" the bottom goal art. This means that, after converging, you have to go into the goal art tiles and delete parts of the net so it all aligns up without parts from one quadrant on top of parts from other quadrants. This is a viable method to creating your own custom smaller goal, in a distinctly different way that I initially did it but one that I'm surely going to utilize moving forward. When you get the size you want, then you adjust the barriers code to align with the goal art as best you can which requires trial and error. My overly complicated way of doing itt isn't necessarily the best way to go about this, so if any of what I said was confusing, well I'm trying to work all this out myself and get back up to speed. But your codes are invaluable to making it easy for everyone to make their own smaller goals. Without these codes, it's much harder to do. But with either method it requires manually editing the goal art, and adjusting the shape of the back of the net may also be needed to adjust to the barriers. As you'll find out, it's not just the goal scoring window it's also related to the barrier of the back of the goal and how that interacts with the barriers code. Getting everything aligned can be a challenge and you're well on your way to that now.

That's the idea. What is your reaction to the topic in which a Fake Shot was implemented, and that whole engine? The strategy was to take an unused section of the rom and implement code into that area. That area is then accessed by a small edit to the button press which takes it to this separate code. Have you tested the Fake Shot and what do you think?

In your great goalie button mod, you said "Plans for the use of the (X) and (Z) buttons for line changes and a pseudo fake shot button were scrapped when I stopped doing updates." Since you were working on a fake shot have you tested out the Fake Shot in here : Your use of 1 the 3 extra unused buttons (X, Y, and Z) for the quick GK switch differs from how he did his Fake Shot which is by Holding C and pressing B which cancels the Shot. But it doesn't work like Ice Hockey on NES for example when you can hold the shot windup for as long as you want then release. I just wonder how your pseudo fake shot button might have differed as its own button compared to how McMarkis did it. I can appreciate the difficulty of trying to code Line changes on the X button or a Fake Shot on the Z button. With McMarkis doing the Fake Shot with C (hold) + B, which is very natural and effective, it frees up more possible functions to the X, Y and Z button or other unused buttons. The way in which I was going about it was by finding the A button timing instructions in the RAM and trying to edit them in real-time to see changes in the timing. But with this new code injection engine in that topic with an example of a control scheme change, this makes it more doable than ever to make further changes. It would seem to me that it would take your process of adding the goalie switch function to 1 of unused buttons combined with the what McMarkis was able to do with the Fake Shot with the B and C buttons. If we can enhance the controls that already exist and add new buttons I think we'd have a much more durable control scheme. I don't know how feasible it would be to implement a A button holding mechanism that adjusted the length of the flip pass/clearance based on how long you held it. And on top of that we could use B button to cancel this windup in the same way that it works with the Fake Shot.

Thank you for this! I managed to patch a few roms with the Fake Shot and I'm so impressed. Complete with a sound effect when you do the fake, just brilliant. It's interesting how you coded the Fake Shot to work and how it compares to doing a similar B button cancel to the A button. The difference being you don't transition to a pass when pressing B with your Fake Shot. It's encouraging to see how you've managed to implement this Fake Shot, and your system of adding Menu options is fabulous. This is really well designed and makes it a lot easier to make and apply advanced rom patches. I would be very interested to hear more about what inspired you to create this patching engine and specifically to implement a Fake Shot. Well done, it is very rewarding to do Fake Shots in-game, and I would be very interested to make other kinds of adjustments to the control scheme.

Try this : when with the puck, hold down the B button without pressing any D-pad direction. You'll notice that you can hold the B button for as long as you like with your player gliding along the ice or standing in place, and when you're ready to pass, you can either release the B button or with the B button held, you press a D-pad direction to do a quick directional pass. So it's not a mod you're missing, it's part of the control scheme, just not something players typically utilize. That's the idea, a dedicated line change button moved to an unused button like X would be nice, however that might be harder to implement than what I'm suggesting. At this point I'm merely looking for a way to trigger an A button clearance / flip pass whilst the B button is being held down, while in that windup with the button held. On a related note, when taking a shot, it would be nice to be able to do a shot cancel. These are the kind of hacks that I'm looking into. I am very interested in moving the Line Change Menu to another button, and freeing up the A button to be only about A button clearances / flip passes. Anything we can do in this regard that enhances the controls would be welcomed. And what about when you're in the attacking zone and can only do a short flip pass. What if you wanted to do a longer "flip pass" in the attacking zone. It could be a very effective move. The moment you cross that blue line the A button pass function changes to a short flip and you can barely hold down the button before the Change Lines screen comes up. This means you essentially have to pre-aim your flip passes with a direction held down before hitting the button, which is similar to the normal way of doing B button passes. (have a direction held, then press the B button to pass, rather than holding the B button but no direction held, then pressing a d-pad direction to pass it) With A button the same choice is there but within a very small window of up to a quarter second before automatic release. And the fact that you can cancel an A button hold/windup briefly by holding B with the A button held down suggests that there is a "cancel" code built in that we might be able to study and turn into something more powerful. What I'm outlining here might seem difficult, but I'm fairly confident that I can come up with something that makes the A button function more like the B button. I'm not sure exactly what I'll come up with but I'm working on it.

I know this has been discussed in other topics but the problem persists and I think it's important to have a topic about this so that something can be done about it. The issue is multi-layered, it's primarily how's how fast the goalies are, how even if you lower a goalie's speed to the lowest value, they don't slow down very much, and this affects how easily Goalies can knock down skaters. The main issue that I'm trying to address is the all too common breakaway-skate-into-goalie-fall-down before getting the shot off sequence. Or when a Goalie chases the puck behind the net and as a skater you are trying to get to the puck but the goalie is there, you know if you run into the Goalie collecting it you will instantly fall down. This problems holds back a gameplay element of going hard towards the puck when the goalie is there. Instead we have been conditioned to slow down and not touch the goalie because he's so dangerous. Going hard towards the puck, even if the Goalie is there trying to collect it, is missing, and if I run into him, so be it, I want to fight the Goalie for the puck or at least stay upright while trying. I don't necessarily have to knock the Goalie down as he's collecting it or if he's possessing it, though that would be very satisfying, but even if we could create a skater barrier from the Goalie so easily knocking us down is no longer commonplace, it would really add some realism and depth to the gameplay. As a skater you pretty much have to avoid the Goalie at all costs. It would be so much more fun to run into be able to run into him and not be flattened every time, whether or not interference might be called. Now some might say that the overpowered goalies are part of the charm of NHL 94 and there's something to be said there, but I'm looking for ways in which we can stay upright when interacting with the goalie, or even to bump into the goalie, like on a breakaway, maybe sometimes you lose the puck but stay upright, maybe sometimes you get wobbled while the goal ie unaffected, this I've seen before, it can happen organically but it's very hard to reproduce it, or maybe you bump into the Goalie and the Goalie loses his balance for a change and you keep the puck and you shoot it by him when he's stunned. I'm looking at this from an animation standpoint to see if we can implement some new animations or a kind of barrier code, for the players, to protect them from the Goalie, or conversely to remove the protection and superpowers that the Goalie has. It would be to lower the Goalie's speed below the lowest attribute limit so he moves even slower. He doesn't need to move as fast as he does to gather the puck in most cases especially with superpowers. And I think part of what causes skaters to go down so easily when they bump the goalie is due to the actual speed that the Goalie moves at. It's like the Goalie speed roster attribute isn't balanced properly. Even at 1 or 0 it's not slow enough. If we could make the goalie speed even slower than the attribute scale minimum, I think it would create more balance when there is a bumping between goalies and skaters. As I indicated, I have seen certain animations between a breakaway skater and a goalie in which the skater gets bumped by the Goalie but does not go down, instaed he sort of does a dance and loses his balance for a moment. It's the same animation that players who lose a Fight do when they stagger towards the penalty box. Those kinds of animations are in there, and can be triggered and it's a matter of getting those animations to occur more often instead of being knocked down so easily. Part of it would relate to certain attributes, weight of the skater, etc, but I've found that these don't make all that much difference to how often they fall when colliding with goalie. I think the biggest issue is the speed that the Goalie is able to move at. If we can reduce that below its normal limits, I think we would have much better and more balanced interaction between goalies and players and more depth to the gameplay.

How has this been going? In what ways are you able to speed things up, or conversely to slow things down? I would be interested to learn what kind of codes you've found and how it relates to the speed of the game. I generally rely on player attribute / ratings to determine game speed but there are codes that affect camera motion that can make the game feel slower or faster. Is what you found camera movement modifications, or other codes that also affect game speed?