Ah, cool. Thanks. But yea, that's gimmick. There's probably a more efficient way to do it, but I haven't used MMF2 in like, ages.
The one big thing I would fix with it, now that I've had a chance to sit down with the code, is to make the energy path appear in front of Sonic. It's not supposed to be a trail, it's supposed to be generating a tube for Sonic to roll through. Also, I probably won't be directly adding it to Delta (I'm trying to keep gimmicks a bit more... generic?) but this is an excellent example for other people to look over, regardless
Okay, nobody else has mentioned this, but using MMF2, I have been getting this error with all recent versions of Sonic Worlds when I attempt to build them: [REDACTED] (No, this isn't linux, it's just a skin to look like it. This is Windows). Does anyone have any suggestions about this, or know what I'm doing wrong?
I have done that already. I went to Help > Check For Update, and it said "The current version is up-to-date."
Actually, I think I've found the discrepancy thanks to that. In the Dependencies folder, there is a "Data" folder, and an "Extensions" folder. I took the extensions from the "extensions" folder, which have a larger file size, but there is another set that are all smaller in "Data/Runtime." Which extensions are the correct ones to use? The reason I ask is that after copying over the other extensions, I actually can't open the project, due to the fact that it gives me an error like this: [REDACTED] So now, as I get different errors from both, it begs the questions, in Sonic Worlds, which extensions are the RIGHT ones for me? I'm using Multimedia Fusion 2. ...Also, according to Firefox, "Dependancies" should be "Dependencies", but that's a minor thing.
Ah I see where you're doing it wrong. See, there's two versions of an extension file: an edit-time version and a run-time version. You're supposed to directly copy the folders from Dependancies (yes I know that's a typo >_>) into your MMF2 install directory, and not go into them and manually copy over extensions. The smaller ones have to go in Data/Runtime, and the larger ones have to go in Extensions.
Ah, there we go... Sorry about that, I'm not inexperienced with how MMF2 works, but I am unfamiliar with some under-the-hood things that are what ultimately lead to this. I got it all working now though, thank you! ANYWAY, I have a few bugs, mostly minor or easy to fix stuff: Characters cannot turn super by default, even you force the emerald number to 127. The fix is simple: The game checks if the signpost is triggered (Or, more accurately, is NOT), but there is no signpost so the check fails entirely and so does the event. When Sonic is super, Amy's life icon appears and Super Sonic's fades in and out over it. The CNZ barrels seem to behave a bit funny. They move up and down around 1.5x as fast as they should, Monitors do not crush you when falling on you, and bounce on your head repeatedly. The MTZ nut on the screw is the same.. If you run it into a ceiling, it does not crush you. All simple fixes, I just thought I'd bring them forward.
The fix involves altering this to check if the goal type is a sign, then making another check for if the goal type is anything else. This has been fixed in 1.4.3 (comming whenever), here's an image showing how the event should look. Also fixed in 1.4.3, I accidentally overwrote Super Sonic's icon graphics with Amy's. The fix is to add back in those animations after Amy's, then on line 4148, change the action to Set FlashOffset of GUI_Icon to 8. Herp-a-derp derp derp! But they function! Things like movement speeds can be altered by changing their alterable values to whatever you want. Before I had them too loose, now they're too tight... honestly at this point, screw it. :v: Working as intended. Place a crusher object in the ceiling! This is how it works in the Genesis games, too. (it's the block of Eggman icons, just like it is in Sonic 1 and 2 when you use Debug Mode)
Or just set to nut to be in group 8, which would save a little memory. It still works fine. In addition, I have one question - just one. How did you get the music looping properly, trail and error? Right now, I have a starting and ending loop point set, and by pressing M it sets the some to right before the area the loop should happen, and from there, it's experimenting. Is there an easier way?
I usually use some audio program that can show the position of the music, for instance GoldWave. Hmm. Maybe I should make a tutorial on looping music. But in simple terms, you just use that program (Audacity should work too) to find your loop points. Change it so that it just shows seconds and copy the seconds to MMF2.
I understand what you said myself, but a tutorial is always nice. I still have some things to figure out though, right now my loop is seamless in GoldWave but in MMF2 there's a slight stutter.
Okay, I noticed a couple of others things, which were quite jarring to me, so I'll point them out here: Note that I have fixed these myself, they are all easy to fix, but I'm putting these here for you. You cannot break a monitor by jumping into the side. This is inconsistent, at least with Sonic 1 and 2. Don't know about Sonic 3k. The speed shoes and invincibility are much shorter than they should be; They are set to 1,000 frames, when the correct time would be 1,200. I also have a suggestion on something that could speed things up just a little bit, and make things easier for someone working with the kit, too. As all monitors are the same, I have an idea which might consolidate the code a bit, and also save a few CPU cycles. You know how the code for bumping a monitor uses group:Parents, but the code for destroying the monitor handles each case separately? Why not just implement the destroying function within group:Parents itself, where when Sonic should destroy a monitor, it applies the needed Y velocity (Which would be 0-yspeed) and sets a flag in the group:Parents object itself? After that, the code for destroying the actual monitor could just be as easy as simply checking if the monitor object has that flag is set.
Hm, I tried to implement this just now real quick, but it is either too sensitive (just press jump while standing next to a monitor and you'll break it, which is incorrect) or not sensitive enough (collision isn't detected). I'd like to see your version of the fix, please. EDIT: Wait, I got it. This will be fixed in 1.4.3! This has now been fixed for 1.4.3. Funfact: Before, it was waaaaaay too long. :v: Also, that's a good suggestion, but it assumes that qualifiers work well in situations like this. Sadly, they don't. It's something being fixed in Fusion 3.