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

LarkSS last won the day on July 23 2011

LarkSS had the most liked content!

About LarkSS

  • Birthday 03/28/1991

Contact Methods

Profile Information

  • Location
    PosX, PosY
  • Interests
    Various activities that appeal to my liking.
  • Fan Gaming Specialty
    Programming... mainly.
  • Current Project
    MrDriller Rockbox Port

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

LarkSS's Achievements

Newbie

Newbie (1/14)

1

Reputation

  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 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.
  3. 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.
  4. 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.
  5. 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
  6. @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).
  7. @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.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. @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):
  13. 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.)
  14. 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...
×
×
  • Create New...