Language…
9 users online: Capeman, DanMario24YT, Easy Difficulty, Jordan, Kusrry,  MarioFanGamer, name_6969, playagmes169, TheOrangeToad - Guests: 90 - Bots: 236
Users: 66,536 (2,385 active)
Latest user: linkypants

Posts by MarioFanGamer

MarioFanGamer's Profile → Posts

  • Pages:
  • 1
  • 2
  • 309
  • 310
  • 311
  • 312
  • 313
(restricted)
I... wouldn't count on that, though, in part because the problem is still there and emulator problems are treated seriously here on SMWC, there is a minimum effort to support SNES9x and BSNES, the two main emulators.

So the question is, which emulator did you use before and which one do you use now?
Keep in that mind that when I ask about a certain emulator, I specifically think about the cores. Emulators like SNES9x, BSNES and Mesen are true emulators whereas others like Bizhawk and Retroarchs are frontends and use the aforementioned emulators to process the game (they do tell you which core is active, though, like Bizhawk allows you to find the currently running core under "Emulation").
Originally posted by RussianMan
It's just a bouncy boi, minding his own bu-OH MY GOD HE EXPLODED:

It's actually quite fitting when you consider that Bob-Ombs share lots of code with Goombas and both also come with .

[
Originally posted by RussianMan
It's never too late to mix seemingly unmixable elements of plant and fire:

I can see it work as a good obstacle if the delay between coming out and shooting fire is reduced.
I already have tested UAT2.0, though I've never seriously used it (in part because 1.6 is the moderation standard, in part because I don't really hack) up until our Q-Jam entry where the multiple codes per entry / GlobalLevelASM became very practical, only causing some confusion with stuff like case-sensitive hook labels and reimplementation of GlobalASM. Speaking of GlobalASM...

Originally posted by MM102
One thing I will say though is there should probably be a note in global code to say this feature is partially deprecated.
Or better yet, maybe rename 'global code' to 'game start' or something similar seeing as thats all the file is intended for now.

This came up when I and Runic_Rain worked with UAT2.0 where it took a while before we understood that GlobalGamemodeASM is basically GlobalASM minus game initialisation and that in turn caused some headaches initially. So I'm behind that suggestion also.
There are some solutions: One method is to use a p-switch block (alternative) which is as simple as it is, the other is to use a P-Switch disassembl and modify it such that it prevents the player for carrying one. If you use the latter method, make sure you delete lines 188-201 in the code as they handle the carryable interaction.
(restricted)
Even though you're very much annoyed by this, I fourth this since someone mentioned a that CDM16 allows me to replicate some of the conditional objects one can create with ObjecTool but one also can't forget that this doesn't encompass everything and aren't edge cases either (most notably, item memory which just can't handle with CDM16). The biggest issue IME is the priority between overlapping objects because these do require an object having a specific size, else you'd have to hack around them to be placed the way one intends.
Reading your OP again, it surely is weird that there is only SFX but no music playing. Not that this doesn't make it any better because we take emulators accuracy seriously, especially if you switched to an older, more inaccurate emulator (which is why I asked for a before and, not one of them) but it also makes me doubt it's the emulator alone which caused this.
In that case, you have to add in a check whether Ganon is teleporing (/cptobvious off). The best solution appears to check for $C2 and whether it's four (and eight for the death cutscene, for that matter). Keep in mind that $C2 is also used to check whether an attack has been initialised by setting the high bit. That code should do it:
The problem isn't the code, it's how you inserted it. For starters, it's normal that a sprite can get displayed as an X because it doesn't come with any display information (modern sprites tend to come with them, though, but this one has been last updated over five years ago). Instead, if you have a shelless Koopa with no information, it simply means you've borked the installation. There are following cases what has happened:
  • You lack a list.txt. Solution: Create it yourself.
  • You didn't put the sprite into list.txt. Solution: Put the sprite and the number you want to insert into the list
  • You've entered the wrong number for the sprite inside list.txt and when you placed the sprite. Solution: Check if the sprite number is the same in the list and (either by howering over the sprite and check the number for "Custom Sprite Command" and clicking the sprite with a right click)
  • PIXI reads the wrong list.txt. Solution: By default, the list is located where the ROM is located so if you use PIXI as it is (no command line), check if the list.txt at the ROM's folder is where it is. Otherwise, check for the list you've specified the path instead.
  • You didn't actually run PIXI or it aborted the installation. Solution: Run PIXI again and make sure you don't dismiss the error.
  • You used the wrong ROM. Solution: Make sure the ROM you've applied PIXI is the same one where you edit the level.


Lastly, a two-tile falling platform is included in this pack but first focus on inserting the disassembly.
It definitively looks like you did the overall correct thing so that the platform doesn't appear in correctly is weird unless it's indeed the wrong ROM you modified. You can test this out if you add in a proper display for the sprite inside the CFG (though make sure you save it as a JSON first and loaded in said JSON due to bugs) and create the sprite graphics yourself which should add in a proper display for Lunar Magic. Alternatively, insert a modern custom sprite which typically come with a JSON and correct display informations (you can insert it to a different number for completion).
If the new sprite looks still bad in Lunar Magic even after reloading the ROM, it simply means PIXI changed the wrong ROM or that PIXI loaded from the wrong list.txt but if it's bad in-game only, I'm out of ideas.
It simply means you didn't enable sprite bouyancy at #lm{sprhead} which is usually disabled to save on processing power in levels where water doesn't play a role.
You also have to insert the projectiles (tutorial) and specify the numbers at !Projectile within the ASM file.
There are two solutions: You either create tiles which merge water with the slopes together (it requires some knowledge in ExAnimations, though, thanks for the surface tiles) which is what Vanilla Dome 2 does (also note that there are underwater slope tiles and they should be used a reference) or change the level mode to 02 and put the water onto layer 2. Do note that the latter has a chance to increase slow-down thanks to processing the level interaction twice (though if you don't plan on using layer 2 foregrounds, you can disable layer 2 interaction with sprites — same buoyancy menu — which only allows them to interact with layer 2 water) alongside preventing you from using a layer 2 background as it's used in the foreground now.
Ah, right, I forgot that it also shrinks down the level length (since the original level data is split in half, for each layer). In any case, there isn't any other (easy) solution other then create foreground tiles with water in the background.
First off: The garbled ROM title is mostly caused by a quirk of Lunar Magic (which only accepts headered ROMs) and that of Asar (which determines whether the ROM has a header or not by the extension). The tl;dr is that Lunar Magic adds a header to your ROM if it doesn't have already but keeps the ROM name including extension the same. Changing the extension from .sfc to .smc fixes that.

The header error refers to the header and header only. It is entirely unrelated to the if block just below which contains all the defines. You don't even have to remove it either because it's a warning message i.e. Asar will function just fine.
(On that matter, I'm surprised the header still exists in the file so whoever updated it made a bad job upgrading it to modern standards.)
That's the default behaviour, it's just that Mario immediately regrabs the sprite without much effect outside of Springboards which still block you when you carry them. Do you mean that Mario can't immediately regrab the carried sprite then?
Update: It got worse. Now when I try to add two lists, I can't submit anything anymore! Basically, when I try to add a second list, the submit button only works when I add only one entry (albeit with an error message that the option needs a default value) but should I add a second one, the submit button doesn't work anymore, not even displaying an error message.

For context, the first list has eight options (palette), the second list is supposed to have two options (GFX page).

Browser: Firefox 124.0.1
I've decided to do some (non-anonymous) fanjudging so if you want my opinions, you can get them here.
  • Pages:
  • 1
  • 2
  • 309
  • 310
  • 311
  • 312
  • 313