Post your screenshots thread

[Betaman]

Please can we stop it with the hostility and the unneeded sarcasm and the bickering over engines? Geez, this is reminding me of my first post here except it's not directed at me.

[TailsSena]

Please can we stop it with the hostility and the unneeded sarcasm and the bickering over engines? Geez, this is reminding me of my first post here except it's not directed at me.

Same here. You guys, all Blaze is saying is that he wants to do things himself. The rest is all frizzle and dazzle. So just let him do his own thing, alright?

[DimensionWarped]

Closing Pandora's box doesn't put the stuff that got out of it back in. No one is against Blazefire doing his own thing, but the way he is essentially shit-talking everyone who uses Worlds for whatever purpose is a pretty egregious offense by which I happen to be pretty egregiously offended.

[TailsSena]

@TailsSena: I don't think it'll work. The platform movement won't work well if you try to "overlap" it with a 360º engine. I don't think the Platform Movement object (the extension) will let you, either.

Oh yeah. It works just fine, I just need the angle sensors to "jump" when I do. That's really the ONLY problem I'm having with it. If I have to resort to world movement so be it, but I'd like to see if I can make this work first.

[TailsSena]

Closing Pandora's box doesn't put the stuff that got out of it back in. No one is against Blazefire doing his own thing, but the way he is essentially shit-talking everyone who uses Worlds for whatever purpose is a pretty egregious offense by which I happen to be pretty egregiously offended.

Did you skip the part where he deliberately said the engine was good? Seriously, take a chill pill, all of you. (Betaman, you're fine.)

[GSF]

So then, these sensors... Are they currently "following" your character object? If they do, shouldn't these follow it even when jumping?

Check your events that make the sensor follow the character. Maybe you're using a "state machine system", where the sensors follow the character as long as the state is X (e.g. standing, walking), and you need to add an equivalent for the "jumping" state.

Anything interesting in the sensor following events?

[TailsSena]

So then, these sensors... Are they currently "following" your character object? If they do, shouldn't these follow it even when jumping?

Check your events that make the sensor follow the character. Maybe you're using a "state machine system", where the sensors follow the character as long as the state is X (e.g. standing, walking), and you need to add an equivalent for the "jumping" state.

Anything interesting in the sensor following events?

They move along the ground under him/her. Literally-- THE GROUND. I can't find where they could have the capacity to "jump" I'll look harder, but dmmit, Damizen, if you're making a component for a Sonic fangame, PUT IN JUMPING!

Woo-boy. I think I just made things worse... Sooooooooo, what now?

[DimensionWarped]

Did you skip the part where he deliberately said the engine was good? Seriously, take a chill pill, all of you. (Betaman, you're fine.)

Of course I didn't. But more was said than just that.

And I will chill when I hear proper concessions made. You don't even seem to think that what he was saying was rude and dismissive. Worlds has too many users on here who work too hard on their stuff to basically be told that they are shiftless and lazy for relying on a slightly more complete solution from the get go. And you are a few years too early to be telling people what does and doesn't merit resolving.

[TailsSena]

Of course I didn't. But more was said than just that.

And I will chill when I hear proper concessions made. You don't even seem to think that what he was saying was rude and dismissive. Worlds has too many users on here who work too hard on their stuff to basically be told that they are shiftless and lazy for relying on a slightly more complete solution from the get go. And you are a few years too early to be telling people what does and doesn't merit resolving.

Because I hear things like that all the time. It's called High-school-- aka: the hell most adults would rather not relive. I've learned to pass things off and not let them bother me. Yes, I may be much younger than all of you, but that doesn't mean what I say should be dismissed without a second thought; My words can mean just as much as yours.

[GSF]

Check the events that set the sensor position. It should be "Set Position at X, Y from (some object)".

Try adjusting the Y coordinate in that a bit. In MMF, a lower number is a higher location, so if Y is set to 15 try 5 or less, for example.

But... are angle sensors necessary when jumping? These sensors should always be in the ground, since that's where the floor curves will be at. I don't think they have any use while in a jump state.

[TailsSena]

Check the events that set the sensor position. It should be "Set Position at X, Y from (some object)".

Try adjusting the Y coordinate in that a bit. In MMF, a lower number is a higher location, so if Y is set to 15 try 5 or less, for example.

But... are angle sensors necessary when jumping? These sensors should always be in the ground, since that's where the floor curves will be at. I don't think they have any use while in a jump state.

...Good point. Perhaps I can just destroy them when I jump, then create them again when I land! I'll try it!

[DimensionWarped]

Knowing the angle of the player is useful for starting a jump, but not the actual jump state itself. When you jump from a spectated angle, you expect the jump to be given strength normal to the angle and added to the current velocity vector.

In other words...

when starting the jump, set the ySpeed to the product of the jump strength and the cosine of the angle (0 degrees being to the right) added to the ground speed multiplied by the sine of the angle. The xSpeed should be set in the opposite manner... jump stength * sin of angle + ground speed * cos angle. Aside from that one instant, the angle sensors play no role until landing needs to be detected. That's when you figure out what needs to be done to the player's ground speed upon re-entry.

TailsSena: Look, I'm not dismissing you because of your age. I'm dismissing you because you are saying that the appropriate answer to a bad situation is to ignore it and sweep it under the rug while at the same time lacking all but the most basic level of familiarity with the people you are talking to.

[TailsSena]

But... are angle sensors necessary when jumping? These sensors should always be in the ground, since that's where the floor curves will be at. I don't think they have any use while in a jump state.

Knowing the angle of the player is useful for starting a jump, but not the actual jump state itself. When you jump from a spectated angle, you expect the jump to be given strength normal to the angle and added to the current velocity vector.

@gsoft: Yeah, it works almost flawlessly now, thanks! It just leaves me with a couple degrees of angular error upon landing.

@DimensionWinnie: I'll try to do that, since that's how it works in games like advance and rush/adventure.

Alright, the sensors are deciding it's alright to go through the floor now, and rotate endlessly. Usually landing on spikes causes it... So what if I gave the SENSORS movement under the platform movement object?? I'll see.

[DimensionWarped]

Not just those games. It works like that in almost every Sonic game. That's why if you jump while spindashing up a hill you'll fly way high into the air. Then there's the opposite side of it where you land and get a massive speed boost when landing into the curve.

[TailsSena]

Definately true, but not sure how to impliment that one... Well, I've got an idea, but I'd have to make all this rotation stuff work first... WAAAUUUGHH!!!

AHA! It screws up when I land on anything but the floor...

I think it might be time to screw with Worlds. My ENTIRE enginge so far uses 192 events. Pretty small in the grand scheme of things.

[GSF]

Just one thing: Don't destroy and recreate the sensors. Simply deactivate them (ergo, don't use them). If you use regular "Set position" actions, they shouldn't fall through the floor or rotate endlessly.

When you're jumping and don't need the sensors, simply leave them be. They should resume working correctly after landing.

And just a long shot here, but if landing on spikes makes the sensors fall, maybe when you do so, MMF thinks you're "dead". Remember what happens when Sonic dies? That's right, he falls through the floor, and that may be why the sensors fall. So check out your "collision with spikes" event and see if there's something that might be the cause.

EDIT: Land on anything but the floor? Hm, I think I know why. When you touch the floor (a MMF backdrop object) there are a few things that are done internally, such as resetting status to "oh look, Sonic landed". But these actions aren't being performed when colliding with objects. You should set these objects in a qualifier and then set a "collision with Qualifier X" event to perform said actions. In simple words, look at the events that take action when landing on the floor, and copy them, replacing "floor" with (some object).

You should take a look at how Worlds uses qualifiers, such as "Enemies". They help a lot along the way. Adapt things to your engine.

And here you go: http://sonicunited.org/hsfqmtif/forum/attachment.php?attachmentid=625&d=1200856352

It's the "basic 360 engine" I mentioned earlier. I'm sure it'll come in handy. Check that one first, and then look at Worlds, which improves the way it works.

[Shockey Rai]

C'mon people, This is a Screenshots Thread. Not a Help Thread. (Or a bickering thread for that matter)

[DimensionWarped]

And yet you don't seem to realize the irony of bringing the discussion right back to being off topic. Way to be a winner.

Thread topicality is not a big concern here. We discuss things where they are brought up because that's the obvious and convenient place to discuss them.

[Shockey Rai]

My bad. *facepalm*

[snow toilet]

I just did this random edit to the SonicAdvance End Capsule. Honestly, my best sprites/edits are just me randomly messing around in paint..

[qimg]http://dl.dropbox.com/u/5505419/Temp/New%20End%20Pod%20Difference.PNG[/qimg] It should be obvious for the DO NOT USE. That includes you lurkers who have yet to discover a site goes with this forum.

What do you guys think?

Haha, I'll be the first to comment on this due to all the bickering.

Yes, that looks excellent.

I would like to see an animation of what the capsule will look like when it's busted open.

Not really a fan of the Advance opening of the capsule animation.

[Strife]

I know I don't have anything to show, but I want to admit that every single one of you who posted in this thread gets my kudos. All of the stuff I saw in this thread is absolutely delicious, and is the reason I come here to this forum, to see talented ideas (in Sonic fangaming and some indies) go to great work.

You guys have great minds. xD

I'm sure I speak for more than one person here when I say, thank you.

As for Blazefire's capsule edit - Pretty nice. =D I like how it's a little more ambiguous as to who it belongs to, due to the lack of an Eggman logo.

[BlazefireLP]

Okay, lets get one thing straight. I was not bad mouthing anyone who uses Sonic Worlds and the word "crap" was a general use term of mine. I didn't essentially mean it was what the word represents. It's a slang word for me. Same use age as "Chatting n shit". I am just saying fan-games are becoming less different from eachother from the mass use of something premade. I tend to stay away from it and don't like playing games that even make it obvious they use worlds. I am just sick of the feel of the engine, that was my points guys. Hence why I hardly enjoyed SZR and Sonic Nexus in the Worlds days. Most people on YouTube where ecstatic. Why? Because they didn't know they used a premade engine. Anyone without that knowledge would BE impressed.

I'm sorry if I seemed particularly offensive in the previous post.

AAAAAAnd now back on topic:

@Stife: Thanks strife. Yeah, I tried to shy away from the stupid predictable MUST BELONG TO EGGMAN cliche.

@DNL: Thanks, and when you put your mind to it, you are equally as awesome.

@Tailsena: What exactly are you trying to do again?

@SnowToiler: Thanks, I will most likely change that too. For a hint for what I am thinking will be in them, don't expect cute and fluffy animals.

[DimensionWarped]

"crap" is so not what I was angry about. I'm much more annoyed by this:

"I cannot find myself interested in any fangame that uses SonicWorldsDelta."

Between that and the attitude of superiority you are taking simply for working from an ever so slightly barer skeleton, the whole conversation leaves me thinking that you are two-faced and a hypocrite. Changing a few values and swapping out some sprites doesn't make it your engine and neither does adding stuff to it, and Worlds itself is not at all at fault for people not doing either of those.

[Steven M]

Doesn't matter the engine you use. If it's interesting, people will play it. A generic Sonic fangame made with the Delta Engine will be just as boring as a generic Sonic fangame made with any other series of code.

[TailsSena]

Just one thing: Don't destroy and recreate the sensors. Simply deactivate them (ergo, don't use them). If you use regular "Set position" actions, they shouldn't fall through the floor or rotate endlessly.

When you're jumping and don't need the sensors, simply leave them be. They should resume working correctly after landing.

And just a long shot here, but if landing on spikes makes the sensors fall, maybe when you do so, MMF thinks you're "dead". Remember what happens when Sonic dies? That's right, he falls through the floor, and that may be why the sensors fall. So check out your "collision with spikes" event and see if there's something that might be the cause.

EDIT: Land on anything but the floor? Hm, I think I know why. When you touch the floor (a MMF backdrop object) there are a few things that are done internally, such as resetting status to "oh look, Sonic landed". But these actions aren't being performed when colliding with objects. You should set these objects in a qualifier and then set a "collision with Qualifier X" event to perform said actions. In simple words, look at the events that take action when landing on the floor, and copy them, replacing "floor" with (some object).

You should take a look at how Worlds uses qualifiers, such as "Enemies". They help a lot along the way. Adapt things to your engine.

And here you go: http://sonicunited.org/hsfqmtif/forum/attachment.php?attachmentid=625&d=1200856352

It's the "basic 360 engine" I mentioned earlier. I'm sure it'll come in handy. Check that one first, and then look at Worlds, which improves the way it works.

Sonic doesn't actually die yet. Nor anyone else, since I'm already spamming qualifiers and global values for a character/partner select feature. (Ala Sonic Advance 3) All five use the exact same set of events, although I do plan on specializing them a bit.

Yes, I have "Active overlaps Group.Foreground object: Active overlaps a jump-through platform" and "Active overlaps a backdrop: Active overlaps an obstacle." ...Active being the player detector/movement. Characters are just "skins" like in Worlds.