USC

Oh, Sonic's movement is just like a 360 engine, where he's stuck inside a bowl with really high edges. There are plenty of tutorials on the main site for how to achieve that. As for the Sonic 3 stages, you might try setting up a flat mini-map off-screen, with a player dot that moves on-scale with Sonic (IE: Sonic's facing forward for five seconds, move the player dot one pixel). Then, use the player dot's distance from the orbs to calculate where they should appear on the real screen.

Sonic 2's special states are fairly easy to do, as long as you realize that it's the background that's moving and not Sonic. It's all a lot of trickery really. Make the background be an active object that changes directions based on what you tell it to do (IE: When counter == 1, have the background go into the 'facing right' animation; when counter == 2, have it do the 'going up' animation, etc). You can use the counter to make a layout for the zone. Then, based what the counter is, create rings at certain points and have them increase in size as they get close to Sonic/the screen; Sonic can only collect them when they're close enough (IE: When they're a certain size). Hope that gives you some ideas.

Check the distance and what direction Sonic's facing. So, if the enemy's X position is greater than Sonic's and he's facing right, go for it.

Nah, he can totally feel our positive energy reaching out to him. Happy Birthday.

I'm not sure if you could *directly* do that, but with some planning of how you use colors, you could replace a range of colors [EG: When variable = 1, set rgb(255, x, x) to rgb(255, 0, 0)]. It'd take a lot of mapping out of colors though. There might be some information online about converting from millions of colors to indexed/256 colors that would be helpful in creating an algorithm.

Random thought, but where is the command for drawing the background situated in the code? If you have it draw first, and then the foreground/other objects are drawn over it, that might solve the problem.

First off, the squares on the edges shouldn't be perfect squares anymore at those perspectives, they should be trapezoids. Not as extreme as that, but it gives you an idea.

Ah, that's true, sorry. Well, looking over your code you're creating a chain-link object at 0,0, giving it an index, then repositioning it. Do something similar with the pulleybar...but do it step by step (ie: have the code that creates the pulleybar at 0,0, then run it and see if it works properly. If it does, add the ID part, see if it still works, and so on and so forth).

If you have the number of chainlinks creates stored as a variable, you could do something like... (after all chains have been created...) *Create PulleyBar at MainPiece X, MainPiece Y + ((ChainLink Y + gapBetweenThem) * NumberOfChainLinksVariable) That should put the pulleyBar centered, and down below the last chainlink ('gapBetweenThem' is taking into account the space between each link). Edit: You didn't post the methods you're using for the pulleybar, but try adding a counter that shows how many pulleybar objects there are in the level; this'll show whether they're being created at all, or just repositioned incorrectly.

Depends on what you're planning. If you don't mind all the pulley's having the exact same amount of chain-links in-between them, just create them at a certain distance away from the latch at start-up, like so... *Start of level -->Create ChainLink at Latch Y - 10; -->Create ChainLink at Latch Y - 30; -->Create ChainLink at Latch Y - 50; -->Create ChainLink at Latch Y - 70; (etc) If you want varying lengths, then create a couple of Latch objects and put them all in the same group. Assign the actual pulley code to the group (IE: Where the code refers to the Latch object, have it use Group.Items instead), and make a couple of versions of that start-up code I used. Again, it's not a glamorous way of doing things, but it works.

Well, like I said there's the low-tech way, which just involves checking if the chain is in the area of the latch or top sensor. //Ascending *Latch's Alternate Value A == 1 *ChainLink's X is greater than Latch's Left X *ChainLink's X is less than Latch's Right X (Optionally bound it by the Y axis too) -->Set ChainLink's Y position to -1 //Descending *Latch's Alternate Value A == 0 *ChainLink's X is greater than Latch's Left X *ChainLink's X is less than Latch's Right X (Optionally bound it by the Y axis too) -->Set ChainLink's Y position to 1 //Stopped *Latch's Alternate Value A == 2 *ChainLink's X is greater than Latch's Left X *ChainLink's X is less than Latch's Right X (Optionally bound it by the Y axis too) -->Set ChainLink's Y position to 0

Unless I'm missing something, here's how I think it would work. The pulley object has an Alternate Value that determines whether Sonic's latched onto it or not. When he isn't (Value == 0), have the pulley handle go down until it's a certain distance away from the top (perhaps place a sensor at the point where the chain goes into the ceiling). When Sonic grabs on (Value == 1), have the chain start going up until it's at the top sensor. Obviously, if Sonic jumps off you set the Alternate Value back to 0, and the chain starts descending again. Hope that helps; I haven't played Sonic Adv 3, so let me know if I'm mistaken about how the pulley works. Edit: Oh yeah, I forgot about the chain itself. Have each link be a separate object, and make them follow go up, down, or stop depending on whether the hook Sonic's latched onto is moving or not. Make them be invisible if they're above the top sensor, and visible if they're below it. You could check this either by using IDs, or checking if the chain is inside the area of the top sensor (IE: chainlink X is less than sensor's right X AND chainlink X is greater than sensor's left X).

If you don't mind downloading a demo of MMF, you can get all the levels on the main site. Here's a link to The Machine. Edit: Here's a .png of what I pulled from the .cca file. Hope it helps.

Considering he mentioned he's use to .cca/.gam files, I have a pretty good guess it's a Clickteam product... Anyway SonicFan, here's an idea to get you started. Create a counter/variable called "SilverFly". Then, add conditions to your gravity/jumping/y position code that make them only work when "SilverFly" is set to 0. Now, when you jump and press whatever button you have to make him fly, set "SilverFly" to a value. As long as you hold that button, you should subtract from SilverFly; if you let go have "SilverFly" set to 0. Either way, he should stay up in the air for a certain amount of time until it reaches 0, at which point whatever code you have for gravity should start working again. Of course, there's a lot of fine-tuning you'd need for this to work, but that should get you started. Good luck.

Yeah, it's pretty awesome, although rather short (you can mess with the save file and see a few unfinished zones though).

You grace us with your presence. As for your request, there's a Silver Advanced-style sprite here... http://www.themysticalforestzone.com/Sprite_Archives/Sonic_Others.htm

If I'm understanding you correctly, you want the perspective on that image to change as you go higher or lower in the level, and eventually to go underneath it? I'd suggest making each row of rocks a separate layer, and setting up a system to raise or lower them (IE: The rocks furthest away would reach the horizon first, then the row in front of them, then the row in front of them, and so on as you climb higher in the level). Then, resize the plain water layer accordingly. Hope that gives you some ideas, at least.

No, because Sep stopped paying for Sepwich so everything on it is gone.

@Strife: I like the changes to the house's color in the bottom, but I prefer the old palette for the rocks. Either way, it looks really nice.

Clwe made a game with the grapple hook many years back, and you can get the source for it here. Just off the top of my head though, you could use the line equation to limit the number of links - absolute value of (Player's Y - Claw's Y) / (Player's X - Claw's X). This should be the distance between the Player in the claw...divide that number by the diameter of the chain length object, and that'll tell you how many chain-links should exist at any given time. You could use that number to limit how many are created, or destroy them when the chain starts shortening.

<insert <insert witty statement about your birthday here> here> Happy Birthday!

WayBack Machine copy of the very first SAGE... WayBack Machine copy of the SAGE @ MoogleCavern I also seem to remember someone (Kulock or Blaze, maybe?) having an archive of the first 10 websites, and I might still have the playable SAGE 5 program lying around somewhere. And yeah, all those sites make it pretty easy to share stuff (kinda their reason for existing, after all), so that'd be no problem.

@Overbound, yeah. I haven't heard anything back from PC0 yet so I don't know if he's already found someone to be a code monkey, but I'd be more than happy to work with you and put together a prototype of your ideas at least. I'm usually free around 8-9pm Eastern time, so email me or find me on AIM (ultraUSC).

@LH: I imagine it'd be promotions, arranging guest speakers, stuff like that.