LarkSS

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.

I haven't messed with anything beyond DirectPlay years ago (which sucks), but I believe Lacewing was designed to supersede the Moo API. If you are new to using net communication extensions, definitely try figuring out Lacewing first.

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.

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.

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

@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. 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).

@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.

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.

Double-post for content update. A new update is now available! 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.

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.

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

@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):

Thanks for the link Techokami.

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. 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.)

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...

Contrast is exactly why I don't like the blue one. It feels monochrome with so much of the same color on-screen. That purplish screenshot looks pretty nice though.

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. I will be including an example of its usage with a badnik in Delta 1.3. Edit2: Families V3.1 is now available.

This. I feel like a shade just inbetween the two you have shown would work best personally.

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: 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.

Does anyone still have the demo compilation? I mainly want to play Sonic Groove again...

"After three months without Eggman attacks, I believe he has [finally] been stopped."

@Falk: As much as I know that's mostly a joke post, there is an Fmod extension for MMF2 already. 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...

Does anyone interested in playing have to ask to be whitelisted, or is what you are doing right now just for testing purposes?

Yes, Delta 1.2 already has that implemented. It's worth noting that for those who don't know, the air acceleration is doubled to compensate for air drag so you can still move swiftly at lower speeds while jumping.

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. 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.