Jump to content
A 2021 backup has been restored. Forums are closed and work in progress. Join our Discord server for more updates! ×
SoaH City Message Board

LarkSS

Members
  • Posts

    2,100
  • Joined

  • Last visited

  • Days Won

    44

Posts posted by LarkSS

  1. For selection purposes, you should have the overlapping condition be first for each event. However due to the nature of what you want done, you'll probably need object iteration to make sure that it works properly (MMF2's selection system is iffy at best). To make this easy, you should use the ForEach extension. Sonic Worlds Delta should have several examples of the ForEach object in action. If you want though, try using the 'Pick "object" at random' condition to cheat; this tends to work but can add latency in event processing due to testing one object per frame.

  2. I've always worked on Delta with the intent of making it a better Sonic engine, given that in the end Worlds started as an engine meant for Sonic games regardless if other people might warp it into other things. I understand people will have their own ideas of what they want to do with the engine which is why we did our best to make sure that objects can just be pushed outside of the frame to make them not spawn or execute their code. Newer builds are also focusing on encapsulating additions properly so removing content is as simple as deleting their containing group and the related objects.

    I suppose starting from a clean build has its advantages, but I also feel it has its share of issues. First of all, Delta is still primarily the core with a few gimmicks and badniks worked in. The additions serve as guidelines that should be followed when coding for a pleasant experience and for efficiency (I still tend to copy/paste existing code and just modify it.) Getting rid of this for a clean build would send new developers blindly forward, and if they don't understand Worlds in the first place then they are bound to code against the Worlds design and end the day wondering why coding is such a pain or why their framerate performance is dropping so significantly. For the developers that do grasp Worlds however and want to do their own thing entirely, stripping the features they don't need out of Delta should be a good learning experience. And no, I don't agree that looking right at the core engine even if it's bare-bones is a good way for beginners to learn. If they are clueless then they should look at existing code, modify, try adding something from scratch, and then try understanding the underlying engine.

  3. General Events > Startup Events > Level Setup

    The value WaterLevel is what you are looking for. I recommend adding 0.5 to this to prevent positioning flickering when using trig to bob the water up and down (Delta does this by default). For example, instead of setting the height to 1600, it would be better at 1600.5.

    And for future reference, you should combine multiple small issues into a single thread instead of making a separate thread for each thing. Multiple threads for minor concerns only clutters up the Worlds forum and makes you seem needy.

  4. In the event editor, if you click on the icon that looks like a chess board with a knight piece, you will be able to see all events related to the camera, start-of-frame actions, and frame changing. This should make it a lot easier to track down the events that change the frame at the end of an act, during game over, etc. Change the frame it jumps to so that it goes wherever you need it to.

    The event that should be of specific interest to you lies within:

    Objects Management > Common Objects > Stage Clear > Score Count - End of Level > End of countdown

  5. @LH: I'm not seeing your reason for posting. You are making assumptions about the engine without even trying it, the reason being on your end and something I will not directly say as it is a topic that is inappropriate to even hint at on the public forum due to the issues SFGHQ had with Clickteam in the past. Not to be a jerk, but praise doesn't even mean anything to me if you're just saying it to say it. If you tried it and you liked what we've done, then sure let us know why you liked it. If you tried it and had issues with the design, then definitely let us know why. But if you can't even run it due to issues on your part, then please refrain from leaving any remarks. And for future reference, Delta's goal has never been to be a 1:1 remake of the classic games and as version 1.3 demonstrates quite vibrantly for those who have dug into the code, flexibility is always top priority.

    I'm going to be working on refining and improving a contribution by Azu that didn't make it into 1.3 due to reasons of time and requiring MORE extensions, it will be one of the bigger aspects of 1.3.2. I won't say what it is (and I hope Lark doesn't spoil the surprise) but I will say that it is something many will find useful...

    In the meantime I'll be fixing more bugs, optimizing (this is a never-ending process), and converting more redundant procedures into FlagAllow variables for easier gimmick writing. I won't be placing any due-dates on D1.3.2, but for the most part don't expect it to come in the next two weeks (I assume most people are happily building in D1.2 or older Worlds builds anyway, but keep in mind if there's something you like in D1.3 chances are it won't take much effort to port).

  6. @LH: Anything in particular that you don't like about the update? Specifically any criticism that doesn't relate to extra content such as the joke title screen. And no, I refuse to support old versions of MMF2 for REASONS. >:[

    By the way, if anyone is curious about the modified ringloss I thought I'd point out that you can easily change the ringloss code in the moving rings group. There are three ringloss methods; Standard, Advanced[Fast] (what Delta 1.3 currently uses), and Advanced[Accurate] (very stable but very intensive). Activate Standard mode if you want it to be how it used to, but it's a very minor performance improvement over the Advanced[Fast] method for a lot less stability. For increased collision precision with lost rings you'll want to activate out-of-view BG collisions in the frame properties, but keep in mind this will greatly reduce performance.

  7. Those are debug counters. The top-right one in particular tracks the framerate. You can make them invisible or flat-out delete them. In Delta 1.3 I set it up so you can easily turn them on and off based on what you need to test, but I'm not sure what version of Worlds you are using.

  8. Double-post for content update.

    A new update is now available!

    -Replace Tails with Sonic 3 sprite (Thanks Kessler and Tech!)

    -Rotate Tails' tails on all slope angles

    -Prevent Tails' tails from direction-flickering when rolling and stopping

    -Reduce swing Yspeed transfer to improve player handling

    -Fix swing instability when standing on its edge

    -Transfer movement speed when landing on a swing

    -Allow movement speed transfer on swings to be easily disabled

    -Disable swing initialization after it has finished processing

    -Disable main swing group if no swings were created

    -Optimize lava by syncing animations manually so it can still deactivate when far away

    -Rotate Tails' tails based on pinball flipper angle

    -Transfer conveyor belt speed when getting pushed off of it

    -Fix landing speed transfer with conveyor belts

    -Remove conveyor belt speed transfer code from Player Actions (no longer needed)

    -Actually use the pinball flipper action/optimize a bit by using it

    -Don't transfer conveyor belt speed if player got hurt/killed/drowned

    -Don't allow the player to receive damage while teleporting

    -Do not spawn mouth bubbles when teleporting

    -Use Sonic 3's super pallet for Tails

    -Fix issue with Ghost Tails being semi-broken (action order matters!)

    -Reduce swing Xspeed transfer when landing (simulates friction/improves player handling)

    Download Sonic Worlds Delta 1.3.1

    Later on Tech should be uploading a more reliable link and Kaosu will get around to updating the first post.

  9. Tech already did that if you checked the build in dropbox. He's referring to Kessler's import not using an accurate color pallet which he noticed while importing the missing run frames. I told him to just recolor the run frames since the point was to only have a matching sprite style for example; most people will just change the sprites for their own purposes. (Thanks by the way Kessler!)

    Edit: You're mistaken anyway. The first column is the normal sprite pallet. The next 5 columns to the right of that are Tails' super pallet changes.

    Edit2: I'm a little confused. I haven't seen Tech on (even though he seems to have been Minecrafting) and as far as I can tell the Tails sprite has accurate Sonic 3 colors. I noticed the run animation had additional frames so I don't know if Tech added that in mistakenly or what. In any case I cleaned it up and will be pushing an update in a bit.

  10. Depends on what you're trying to do. Based on your topic title I'm assuming you want to check when a trainer is facing you to initiate a battle?

    The GBA/DS pokemon games use a tile-based system, where you can only move within a grid. This made it easy to check if one object was facing another as you just trace down a few tiles checking what occupies each tile and stopping iteration if an obstacle such as a rock was encountered. If you are not constrained to a grid in your game however, you'll want to do a rectangle area check. In the example below I'll show how you could handle "seeing" the player when the trainer is specifically looking down (I don't check for obstacles here, and I'm also implying 32x32 tiles and a max range of 5 tiles):

    Dir("Trainer") = 24

    X("Trainer") < X("Player")+16

    X("Trainer") > X("Player")-16

    Y("Trainer") < Y("Player")

    Y("Trainer") > Y("Player")-160

    -
    Request Duel with Player

  11. @Felik: So, you open the mapping screen, press a button, and instant crash? Have you tried selecting different input devices and updating your extensions as I suggested? I can't even recreate this behavior on my 9 year old laptop...

    @sonikku x: I thought about this while prepping D1.3. Since it would require additional sensors to accomplish and I was planning (at the time) to redo the engine, I didn't bother to add it in. However, since D1.4 is going to be the final release I suppose I can get that bit in there. I may add some additional sensors to fix Knuckles' climbing glitches too. Thanks for the reminder!

    @Topic: Just pointing out that even though the main aspects of Delta is worked in-house, it is still Worlds hence a community engine. As you may have noticed I usually do my best to preserve contributions and prioritize optimizing code over redoing it entirely. If you have something you'd like to include into Delta, please don't hesitate to submit it! For example, I would be mighty happy if someone took the time to replace Tails' sprite with the Sonic 3 version. It doesn't affect the engine in any way, but given the sprites used for Sonic and Knuckles it would be a good example to others that you shouldn't mix and match different sprite styles.

    Also here's the changelog we maintained during D1.3 construction (does not fully cover things such as the input manager, ghost system, spindash sound revamp, and many miscellaneous improvements; changes are in ascending order):

    -Fix pushing glitch (pushing animation wouldn't stop if squeezed between two solids)

    -Port Zero's angle-snapping technique

    -Restore control when using InstaShield (yes this is done in Sonic 3)

    -Port Zero's bug-fixed crushing code

    -Port Zero's bug-fixed spike code

    -Prevent a splash from being created when spawning underwater

    -Port Zero's water running method

    -Make a splash when crossing water level even when NOT in the air (classics did this)

    -Rip Sonic 3's water run graphic (kudos to Techokami)

    -Refine corks to not need iteration and to correct repositioning frame lag

    -Split Water post-processing to have pre-process (corrects frame lag in some cases)

    -Add master selection object (encourages object reselection through fixed value)

    -Optimize bubble spawning

    -Fix repositioning frame lag with sinkable objects

    -Add ground sensor solid object remembrance to assist in collision test reduction

    -Many gimmicks recalculate sensor collisions when they just want to move skins; fix this

    -Do not apply bridge forces unless you are actually standing on it

    -Modify gimmicks to utilize object selection/ground sensor remembrance

    -Allow level designers to set the spin tunnel push direction

    -Sync conveyor belt animation speed with its pushing speed

    -Apply an inactive timer to swing poles to prevent regrabbing

    -Dispose of lava objects that are out of the frame/prevent animation desync

    -Add floating point precision to the level timer

    -Update titlecard to demonstrate a scrolling pattern

    -Fix drown not moving down (why was this broken?)

    -Improve drown bubble generation

    -Port Zero's bubble sway

    -Prevent bubbles from spawning while title card is active

    -Reset game timers when restarting level without a checkpoint

    -Implement configurable window scaler

    -Properly disable some gimmicks if not implemented (they weren't disabled correctly)

    -Categorize gimmicks based on when they must be executed

    -Modify ButtonSwitch to use sinkables group (corrects frame lag/reduces image data)

    -Fix normal death not moving down (why was this broken?!)

    -Fix frame lag with sinkable hang bars

    -Don't allow the player to decide the initial boost direction for tunnels

    -Fix a minor animation bug with conveyor belts moving to the left

    -Add fireball shooter aimed to the left

    -Implement Sonic 3's water run graphic and sound (thanks Techokami)

    -Organize debug and make it easy to toggle off (just disable the group)

    -Spruce up teleporters

    -Optimize the breakable walls to use much less collision checks

    -Port Positional Sound System [PSS]

    -Build in-use qualifier list

    -Optimize monitors/re-add bump layer-switching example

    -Create Sound Emitters for PPS

    -Apply PPS to a waterfall

    -Add delay randomizing for emitters

    -Enable shield groups on-demand

    -Prevent falling through layer paths/platforms when spawning from checkpoint

    -Fix score tally skip (can't use player input when it's ignored)

    -Allow multi-input pressed processing

    -Fix underwater bubble shield bounce

    -Prevent bubble shield animation from freezing up

    -Spawn broken monitor sprite with parent's draw order (to prevent layering oddities)

    -Make stage clear move player right using overrided input, not artificial movement

    -Implement ping-pong ring sound panning

    -Don't splash when teleporting into/out of water

    -Port Zero's improved controller mapping

    -Set up additional controller rumble triggers

    -Kill player when time hits 10:00

    -Sync ring/monitor animations to game speed

    -Move external files into containing directory "Data"

    -Set up Kaosu's awesome new mixes

    -Give Delta a title screen...

    -Skip First-Time Check on Game Over as it's not needed

    -Give Character Select a custom fade (including music fade-out)

    -Prevent frame color from displaying on load while using a controller

    -Allow skin rotation to be forced (used to fix sky-sanct. teleporter)

    -Properly reset score tally counters before they appear (Tech fix)

    -Reset Lives/Score on GameOver

    -Modify lightning shield to be a frame-based draworder-switching example (3D effect)

    -Pallet-change life icon when super

    -Prevent speedshoe/invincibility from lingering after Super detransformation

    -Fix spindash death bug (someone forgot to deactivate it in Manage Actions :P)

    -Make boss work again (screw it, we're using Kaosu's :D)

    -Restrict boss damage if boss is flashing

    -Sync time-based boss events to LevelTimer

    -Use camera limits, not camera boundary objects for boss collision

    -Set boss action based on position to camera, not player

    -Clean up/optimize boss

    -Recode Crabmeat for stability/efficiency

    -Prevent buzzbombers from firing while very far away

    -Improve buzzbomber damage (less events/more stability/better instashield handling)

    -Apply PPS to both badniks

    -Center camera after using a teleporter

    -Remove frame-lag with Knuckles' pull-up animation

    -Push camera up during Knuckles' pull-up animation

    -Bounce bullets off of the player's shield

    -Apply PPS to fireball thrower

    -Disable time bonus/ghost recording when getting a TimeOver death

    -Use the special action input for Super transformation

    -Use a count-selection technique to fix some scenarios (such as double ring monitors)

    -Use "Collision" condition to avoid ring collection iteration

    -Add a Climbable modifier for group.0 (currently used on spin tunnels)

    -Add proper group deactivation for a few more "lesser" gimmicks

    -Allow Knuckles to glide out of the screen if SignPost is activated

    -Destroy collapsing bridge segments when out-of-view, not out-of-frame

    -Check core code and do cleanup/optimization where fit

    -Prevent losing roll action when leaving a corkscrew

    -Prevent player from skipping over the nut&bolt gimmick

    -Prevent scenario where player could use Knuckles to glitch past accelerators

    -Lock the player to the center of the nut when using it

    -Prevent player locking on the nut if landing within the lock range

    -Remove frame lag with nut's movement

    -Finally add nut's falling movement when reaching the bottom of the screw

    -Reverse nut's spin direction (it was backwards this whole time!)

    -Enhance multi-monitor destruction support

    -Remove no-shield requirement for Super transformation

    -Fix glitches with Knuckles climbing through platforms (experimental)

    -Adjust shield position when Knuckles is climbing/pulling up

    -Cancel Knuckles' special actions when hitting a bumper

    -Restore common input when hitting bumper (more natural; S3&K does this)

    -Apply a smooth camera shift transition for Knuckles' pull-up action

    -Reset life icon values to avoid display issues (it's a global object)

    -Limit angle range when colliding with platforms

    -Make Knuckles' shield position offsets direction-based (whoops)

    -Allow high angles to hit platforms if moving downward

    -Don't limit camera shift when Knuckles is pulling up (removes most stuttering)

    -Use linear vertical movement for pull-up camera (removes all stuttering)

    -Restore control after Super transformation

    -Allow rolling when landing after hitting a spring

    -Allow Knuckles to spindash when getting up from slide/landing from glide

    -Use a cheap work-around to prevent lost rings from constantly falling into the ground

    -Describe attribute groups (based on suggestion by Tech)

    -Implement varying intensities of ring-loss handling (select via group toggling)

    -Fix ring-loss memory leak (don't spawn on start point as it can have copies!)

    -Optimize level design to properly handle collisions outside of visible view

    -Don't allow special moves after hitting a bumper (encourages pinball physics)

    -Redo nut limitation to prevent rare snapping glitches

    -Replace group.97 with group.Enemies (much more logical)

    -Modify time bonus rules to create a unique Delta standard

    -Preserve Knuckles' glide action on stage clear

    -Implement Family System V3

    -Modify FS to use floating point precision

    -Make a multi-object buzzbomber (sprite by Sparks!)

    -Don't bounce bullets on shields when Super

    -Make attracted rings fall if they are too far away

    -Fix an issue with multiple monitors behind a tree unhiding all at once when bumped

    -Spawn fireballs from fire shooters behind the object, not to back

    -Prevent Tails' tails from angle flickering when landing on the ground (thanks PkR)

    -Optimize the checkpoint (less iteration/collision checks)

    -Fix water run splash positioning (should use WaterLevelApparent for Y position)

    -Fix frame lag with conveyor belt

    -Lower Peel-Out rev sound

    -Allow mid-air actions to be performed after jumping off a hanging bar (Tech change)

    -Fix object selection with multiple nuts

    -Fix snapping issue when a nut hit a sensor too fast and you began turning it again

    -Add a stopper object/have it stop the nut while turning and falling

    -Changing direction should affect nut snatching, but landing should take priority

    -Don't use a shader for the monochrome effect on ghosts

  12. Just tested the engine... Complaints about the incredibly linear level design aside, the improvements don't seem too noteworthy... The biggest difference being that the sprite no longer rotates on small curves, and the boss can actually kill me now because it lands where it should every time.

    I'm not saying I don't like it, because I do... It's just that, from what I'd read leading up to the release, I thought it would be this super awesome end-all be-all dealy-bob...

    I'd just like to remind everyone that Delta is not a fashion show, but a base for you to build from. As Aerosol has mentioned, the biggest changes including restructuring and heavy optimization across the build, including the core player engine itself. If you are running Delta expecting entertainment simply by running it, you are using it wrong.

    For some reason it crushes when I try to redefine keys (yes I've put that dll into system32 folder). I have the latest version of MMF2 and all the extension packs installed. So I can't move sonic around the level

    Can you elaborate on the steps you took to change the controls? Also remember that you must apply changes; the save/load buttons are specifically for profile management (aka storing profiles for later use/trading with others). I'd also recommend updating all extensions that Delta uses. You can get the full list by opening the Data Elements view.

    @All:

    I have decided that Delta 2.0 will no longer exist. Delta 1.4 will be the last build which will include a generic level editor system to eliminate the issues with code and graphics redundancy, as well as enable some advanced features such as level streaming. After this I will be dropping my name from the list of Delta supporters. Keep in mind that even though I will do my best to make the level editor easy to modify, you are expected to adjust it to best match the needs of your game.

    As a little more insight, some of you may already know what D2.0 was intended to be. My plan was to build an MMF2 extension that would calculate Sonic physics but not attach the calculations to a specific object. This would allow it to apply to the player, another player, enemies, gimmicks, rings, etc. The planned level editor would have sent collision vectors to the extension to obtain the most accurate slope physics possible (without using non-linear paths). After much thought on it however, I knew two things. One, most people were primarily interested in the level editor. Two, if I needed to resort to an extension to achieve ease-of-use and speed in MMF2, then MMF2 isn't what I should use for this project. I will still be creating the new engine, but within a different language entirely. It will have no affiliation to Delta or Worlds and as a result it will also lack in-built community features; sorry if this disappoints anyone. (Yes, I am fully aware Mercury is making an engine in Game Maker. The point of my recreation is for my own pleasure, not to outmatch anything he or anyone else may be making/have made.)

  13. One of the few things the sub-app can share are global values and strings, so you'd have to take the values to want to share, stuff them into globals, and then read those same values on the sub-app side. Keep in mind you'll be setting yourself up for headaches by using the sub-app though...

  14. Sure. I've done some personal tests (the difference is notable) but I can whip something up for you guys to see upfront. The second technique I described doesn't need representation though as it's obvious why it's superior. I won't put up any tests however until Delta 1.3 is done, which I'm currently improving non-stop. *sees it's 9AM; decides it's time to sleep*

    Edit:

    Families V3 is now available.

    -Fixed a major iteration bug that would ignore children in specific scenarios.

    -Adjusted for compatibility with Sonic Worlds Delta.

    -New parameters: RotAllow and RotQuality. These can be set per-component.

    -Small optimizations, more comments, and code cleanup.

    I will be including an example of its usage with a badnik in Delta 1.3.

    Edit2:

    Families V3.1 is now available.

    -Added floating point precision for position handling.

    -Logically jumps to the next family on completing a tree (significant optimization).

    -Notes file cleanup. (Make sure you read this!)

  15. Bump for another round of MMF2 optimization tips.

    First up is multi-collision handling. For this we'll point our focus on ring collection. Sometimes you have a situation where the player perfectly collects 2 (or more) rings at exactly the same time. In many engines this causes both rings to be collected but only 1 ring is added to the ring counter. Why does this happen?

    This is because of how MMF2 processes events. When you check if the player overlaps a ring, MMF2 processes this event once. It selects all overlapping rings, sends the destroy command to them, and adds 1 to your ring counter. Just once, so you only get 1 ring. So how do we fix this?

    Until now my logic was to do a quick iteration when you touch a ring to check all rings and one-at-a-time collect any that are overlapping. This works, but I never liked doing it given that there are usually hundreds of rings in one level, so that's not efficient in the slightest. I've found out however that Overlapping vs Collision has a very important difference!

    Overlapping will select all colliding objects, and continue selecting them every frame. Collision will select all colliding objects, but only do it once per collision. This seemed odd, and I found out that it's because it's meant to be used in a specific way; an interrupt event. If you place the Collision condition on TOP of the event, it becomes red signifying that logic will be interrupted when a collision occurs. MMF2 will process the collision for all colliding object pairs one at a time! So use "Collision between Player and Ring", have it as the first condition (it should turn red), and enjoy your now properly working ring collection.

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

    Second topic relates to objects which trigger with several objects at once. For example, if you hit two ring monitors simultaneously, the icons will float up and expire (an internal value hits a certain peak), in which you should get rings from both. However, many of you will know that in most fangame engines both icons disappear but you only obtain 10 rings. How do we fix this without the logic of the Collision event?

    Well the fact that MMF2 destroys all icons is a good thing; this means it is properly selecting everything at once, just processing the event once. This would be fine if we could see how many objects MMF2 has selected. Thanks to the ForEach extension we can! The ForEach's grouping feature allows you to count how many objects exist in the group, and since it adds the selected list of objects into the group for you, you can utilize it like this:

    ProperIconHandling.png

    And that's it! No iteration, no extra events. You throw the selection into a group, use the object count, trash the group. You're done. Now go get yourself a congratulatory soda.

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

    Final topic relates to multi-object object creation. If you have made a badnik before, you may already know where I'm getting to. I'm going to point my finger at Crabmeat for this. He wobbles around, sees you, then fires two bullets like the little jerk he is. But uh-oh, why is it that when two Crabmeats try to fire simultaneously, only one actually fires? Answer: I have no idea. In my experience, shit hits the floor once you try to spawn an object on top of another, given that the event used conditions to select specific objects. Iteration is a quick fix, but come on, that's never a nice thing to do in MMF2. Is there a better way to solve this?

    ForEach's grouping feature comes to the rescue again. Remember, the point of the grouping feature is to iterate through the group. Also remember that the grouping feature will add in the entire object selection automatically. Combine the two and the method is simple; use the group to select your objects and iterate them directly! If you use your trigger event to add the Crabmeats to a private group, iterate the group, and then trash the group, you have successfully made them shoot properly while not iterating through any Crabmeats that didn't need to actually fire at the time. Because of the direct selection, you don't even need extra conditions for the iteration events!

    And that's it for today! The following optimization techniques among other approaches will be featured in Delta 1.3, which is due any day now (given I stop finding new bugs to fix). If anything I've said above doesn't make sense, wait until the release as my examples here are the same situations I applied them to in Delta. :P

  16. @Falk: As much as I know that's mostly a joke post, there is an Fmod extension for MMF2 already. :P I will be porting Zero's positional sound system I wrote into Delta 1.3 due to it being an extensionless technique, but I will leave it up to the developer if they want to use an audio extension instead for advanced features. As far as sound extensions go I'd highly recommend OpenAL.

    @Topic: A little more info on Delta 1.3: Delta 1.3's main features include an input manager, positional sound system, and a ghost recording/playback technique. Sub-features include examples on multi-object badniks, efficient range-limiting techniques, proper water running, and of course bug fixes. I'll be cleaning up the boss example while I'm at it so those new to programming bosses can get an idea on how to avoid issues that the current one has and effectively use condition-based AI. Another week until release maybe, we'll see...

  17. Eh I was more referring to core engine changes, bugs that you may have wanted fixed, etc. I mean in giving you guys Delta I was hoping you'd see the examples and code gimmicks and things like that yourselves. :P For example, one thing that was worked into the build is checkpoint time saving so you can't get bonus points by dying near the end of a level. I'll also be adding in a new function that Zero currently uses which reports what was the last action the player was doing upon landing so you can perform landing collision actions without worrying that you might land before your collision event triggers properly. Things of that nature.

×
×
  • Create New...