deadeye's Forum Posts

  • Okay, okay. Sorry, Ashley. It's just... well, I did have this long and detailed explanation on the implementation and benefits of using surrogate collision detectors, outlining the whys and wherefores thereof, and I... um...

    It all boiled down to this one image:

    <img src="http://xs223.xs.to/xs223/08036/wtf118.jpg">

    *sigh* <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I hope it's not Chris's blood...

  • Is this... blood?

  • As my game grows, so does the clutter in the event sheet editor dialogs. I have to sift through dozens of useless Tiled Background objects that I don't need to perform actions on because they're just decorative. I'd like to request a way to exclude them from the dialog so that I just see the objects I'm concerned with. Would it be possible to add a new property to each object's Common properties to take care of this? Something like "Include in events" with the default being a checkmark or a "Yes." Something toggle-able, in case I want to go back later and include that object for event editing.

    Note that I don't want to make them hide in events already created, just the object picker.

  • A tile editor doesn't have the same global use as other tools in Construct. Since many people are making non-tiled games, having a tile editor wouldn't be justified 100% of the time, especially considering the amount of work that would go into it.

    I agree that a "Tile Blitter" object like the one nobuyuki described is a better idea, but there's just one problem... which tile map format would you choose to work with? As soon as you decide on this, you'd have people screaming at your for that or the other.

    Currently in the klik community people who have need of tile editors write their own custom ones for their games. I suppose it would be possible to make a generic one that would work in conjunction with a Tile Blitter object, but it would take a lot of work to get enough features into it to satisfy people using it. Perhaps some enterprising samaritan would be interested in tackling that...?

  • There was a POST here. It's gone now.

  • Yep, I thought that was coming next.

    You will need detectors. Make a plain sprite a few pixels tall, and as wide as your sprite. Set it just underneath your sprite, like so:

    <img src="http://xs223.xs.to/xs223/08036/detector600.png">

    Now make your detector invisible, and update it's position to your player's feet each cycle. That way you have a new condition you can work with:

    "footDetector overlaps groundSprite" and

    "NOT footDetector overlaps groundSprite"

    I'm sure you can see the usefulness of this <img src="{SMILIES_PATH}/icon_wink.gif" alt=":wink:" title="Wink" />

  • Heya, Casho my boy. I feel sorry for ya, kid. Nobody seems to want to help you out. Well, me and Johnny.jpg got yer back.

    Check it, yo:

    <img src="http://xs223.xs.to/xs223/08035/johnnyrunning929.gif">

    How To Run, starring Johnny.jpg:

    http://www.mediafire.com/?bhexmhksmxh

    See Johnny. See Johnny run. Run, Johnny, run! But how does Johnny run? We put the default Platform movement on him, but it's not enough. He just sorta slides back and forth. So we make a new animation for him called "Running" and fill it with some running frames. Check it out in the Animator Bar.

    But there's a problem... he doesn't know how to move his feet when he runs! Johnny's not too bright. We have to tell him when to move his feet, like so:

    <img src="http://xs123.xs.to/xs123/08035/howtorun1158.jpg">

    Event 1 triggers when you have the right key down. It tells Johnny to which angle to face, and to switch to his Running animation. But we don't want any interference from the left control key, so we put in an inverted trigger for "Move Left is down." We also only want Johnny to face the angle and switch to his animation only once when we push right, so we add the System trigger "Trigger once." This keeps him from setting his animation to Running every cycle (which means you would only ever see the first frame of the animation).

    Next, we set it up so that when there are no movement controls pressed, Johnny goes back to standing still:

    <img src="http://xs223.xs.to/xs223/08035/howtorun2129.jpg">

    Easy enough. At this point though, you may be wondering why we're using "Control is down" and "Trigger once" instead of just "On control pressed." Basically, it's because game players are sloppy! They mash the keys around when they're playing, so sometimes both left and right is pressed at the same time. This causes problems, like having poor Johnny go moonwalking around the screen. To compensate for this we put in the inverted controls to keep actions from happening on sloppy key presses, like so:

    RIGHT DOWN, LEFT NOT DOWN - Run right

    LEFT DOWN, RIGHT NOT DOWN - Run left

    RIGHT NOT DOWN, LEFT NOT DOWN - Stop running

    But there's one key combo left that we have to compensate for to refine our controls:

    RIGHT DOWN, LEFT DOWN - Stop running

    But the way the default Platform movement is set up, it's a bit tricky to do this. When you have both keys down, Johnny still wants to run in whatever direction you pressed last. You could conceivably do this:

    <img src="http://xs123.xs.to/xs123/08035/howtorun3763.jpg">

    BUT this leads to problems. The Platform -> Stop action stops all movement, including jumping, and even falling! Yikes! We need something that will make a smooth transition from pressing left and right that won't make Johnny grind to a halt every time the player mashes both control keys. A better way would be like so:

    <img src="http://xs123.xs.to/xs123/08035/howtorun4632.jpg">

    Now, this might seem a little weird at first, but trust me... it works pretty well. We want Johnny to ease to a stop (or into a quick turnaround) with momentum instead of grinding to an immediate halt. So we set the Platform movement to ignore user input when both left and right are pressed. Since this only happens very briefly when someone is playing a game, the transition from right to left movement is pretty seamless.

    So, what's the event right above that for? Well, if you tell Construct to start ignoring user input, then whenever someone presses both keys down Johnny will become unresponsive. We add that event to bring input back each cycle. We're using two events to serve one purpose.

    So, why don't we just set up an Else event right after checking for both keys down, instead of putting the "johnnySprite -> Platform -> Is moving" event in? Well, I tried that and it didn't work, that's why. He slid around like he was on ice when I did it that way. I don't know why. All I know is that this way it works, and the Else event didn't.

    Also, this isn't necessarily the best way to do this. This method of restricting controls could be a little buggy down the line if you wanted to add more complex controls. It's just to give you an idea of how you can customize the default Platform movement to suit your needs. Once you get this down I'm sure you can come up with your own method of doing things.

    Anyway, I hope this helps.

    P.S. -

    Don't steal my tiles, or Johnny will bust your ass.

  • Short answer: Yes, you can rotate it.

    Long answer: If you want to do isometric stuff, the 3D Box isn't going to help you. The 3D Box will always be in perspective relative to the viewport regardless of it's rotation. This means that you can change the yaw of the box to 45 degrees, but you will still be able to see under it if it scrolls towards the top of the screen, or the left side of it if it scrolls to the right side of the screen. Also, the box itself doesn't collide with the faces of the render, but rather a 2D mask created by the back face texture that is always oriented toward the viewport.

    Still, you can rotate the box however you like. In the Event Sheet editor, select one of the following actions:

    New Action -> 3DBox -> Set yaw

    New Action -> 3DBox -> Set pitch

    New Action -> 3DBox -> Set roll

    Each of the settings takes a positive or negative floating-point value in degrees.

    The 3D Box object isn't so much a feature as it is a proof-of-concept. It does have it's uses, but they are rather limited. Mainly it's there just to show that it is possible to integrate 3D into Construct. If I remember correctly, there are plans to eventually add more 3D support for Construct, but not until after v1.0.

  • As for mixing strings and ints... blah blah blah.. You should use explicit string or integer conversion functions to make it work how you want.

    I know, my point on that was that making variables handle multiple types doesn't necessarily make them easier to use. Sure, I don't have to say x% = 12 and x$ = "dog", but the trade-off is I have to keep track of what the type is myself.

    I suppose I could just get into the habit of naming my variables xN and xS to keep from getting a type mismatch.

    As for the array issue, I guess it just seems like saying y = x should be explicitly stating I want to copy array x to array y. Otherwise, I'd just refer to array x. I don't really see any reason why I'd need two different names to refer to the same array, but maybe that will become clear as I continue to work with Python...

  • Okay, there are a few things that are confusing me about Python. Not that I don't understand them, more like "why the hell did they do it that way?"

    For instance:

    >>> x = [5, 4, 3, 2, 1]

    y = x

    > y.sort()

    > x

    [1, 2, 3, 4, 5]

    [/code:m6cjgmng]

    You want y to equal x, and expect it to be it's own variable from there on. but when you sort y (to put it in numerical order) it affects x too because x and y are just two different names for the same friggin variable. They both point to the same list. WTF? To make y separate from x you have to 

    y = x[:]
[/code:m6cjgmng]

to create a duplicate of the list.  So far Python is fairly intuitive, but there are a few little things like this that go against the grain of it.

Another for-instance: problems arising from non-declarative variable types.  x can equal 12, or x can equal "dog."  Fine.  That makes things easy on the face of it.  I don't have to declare variable types with $ or % or whatever, like in BASIC.  But then you can do weird stuff like this:

[code:m6cjgmng]

    spriteParams = {"x": "45", "y": "80", "active": "yes", "jumping": "no"}

    > if spriteParams["x"] < 50: print spriteParams["x"] + " is less than 50"

    (no result)

    if spriteParams["x"] < "50": print spriteParams["x"] + " is less than 50"

    45 is less than 50

    spriteParams["x"] + "20"

    '4520'

    spriteParams["x"] + 20

    Traceback (most recent call last):

    File "<pyshell#44>", line 1, in <module>

    spriteParams["x"] + 20

    TypeError: cannot concatenate 'str' and 'int' objects

    [/code:m6cjgmng]

    It's just strange, is all.

  • You mean ... the Creations and Help forums HERE aren't enough?

    Hopefully when Construct takes off, no... this forum won't be enough.

    Thanks for the most pointless forum ever <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

    Thanks for the most pointless troll ever.

    Mesothere and SuperV might be jumping the gun a little on making a 3rd party Construct forum, but they're thinking ahead. There are a bunch of different forums and communities for any type of game making software. Each one has it's own particular user base.

    More exposure is always a good thing. If Clickteam only had the CT forums behind them, there wouldn't be nearly as many people making click games. Luckily there's TDC.

    And, unluckily, there's TDC. That's irony for you.

  • Here, look at this:

    http://www.mediafire.com/?e9raxnx8yx1

    Look at it. LOOK AT IT AND LOVE IT AAAAHHHRRGGGG!!!

    Anyway, there are three objects here... a player, a bullet, and the barrier to keep the player from going offscreen.

    We can ignore the barrier.

    Look at the bullet. Check out it's properties. It's set to Bullet Movement. Easy enough, eh?

    Now look at the player. Double-click it. Select Image Points in the Picture Editor. Notice where the "fire" image point is set. Now go back to the layout.

    Select the player again, and look at the Animator Bar tab. Notice that there are two angles for the player, 0 degrees and 180 degrees (right and left). If you select the 180 degrees animation and double-click the frame in the Animator Bar, you will notice that the "fire" Image Point is set up here as well... but it's on the opposite side. This is because we have to compensate for the gravitational field of Jupiter during winter. Or maybe because the player is just facing the other way.

    Now look at the Event Sheet Editor. We have three simple events:

    <img src="http://xs123.xs.to/xs123/08032/shoot493.jpg">

    The first two orient the player when we press a directional key. This is based off the angles set up in the animator bar.

    The third fires a bullet. The bullet spawns at the player's image point "fire." It automatically orients itself based on the player's angle. There is no need to specifically tell it which way to go, it already knows. It's got a doctorate in physics.

    If you study this example, I'll bet you can figure out how to make your player shoot up, as well. I mean shoot in an upward direction, not take heroin. Winners never use drugs.

  • I am intensely amused by the stupidest things...

    >>> lol = 'butt'

    (lol + 's ') * 5

    'butts butts butts butts butts '

    [/code:2ozojgyl]

    I guess it goes back to my earliest programming days:

    10 PRINT "YOU STINK!"
20 GOTO 10
[/code:2ozojgyl]

  • Sweet <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />