deadeye's Forum Posts

  • I wasn't trying to flame anyone, I'm sorry if it seemed that way.

  • Heres the problem, the link to the forum has "www." while the forum settings itself has no "www.", so the cookie is looking for the address without it, that needs fixing.

    Wha...

    I'm not on http:\\www.scirra.com\phpbb2 right now, it's just plain old http:\\scirra.com\phpbb2.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ah, you know what? I totally missed the 3D part. Just skimmed right over it. Forget I said anything.

    The short story: The 3D Box doesn't have collision detection, at least not the kind you're probably thinking of. Don't use the 3D box as a game object. It's for display only.

    The long story: Okay, fine. You can use it as a game object, as long as you're clever about it. But I don't feel like typing the long story out (again). I've written up the 3D Box description a zillion times already.

    Oh what the hell, I'll dig up a link for you...

    Okay, here you go:

    http://scirra.com/phpBB2/viewtopic.php?p=1406#1406

    Anyway, if you want to do collision stuff with the 3D box, use a regular, invisible sprite as your collider. Perform all your game actions on the sprite instead of the box. Then just put in a "Always: 3DBox: Set position to object colliderSprite (image point 0)." Voil�. It looks just like you're manipulating a 3D Box directly, and nobody's the wiser.

  • For the overlapping:

    The first method to fix overlapping is to not spawn a box if the place it's spawning in is already occupied with a box. You could use an invisible detector object to check for it, so if the detector blips in and finds that there's already a box there, it'll just not spawn another.

    The second way to do it would be to pick one of the overlapped boxes and use a loop to move it 1 pixel away until it's no longer overlapping. You could try something like this: 

    +While 
+spriteBox overlaps spriteBox
-Set spriteBox.X to (spriteBox.X-1)
[/code:9brjfm87]

  • Can't really get anywhere on that one before the familys works perfectly. Haven't tried in a while thogh... do they work yet?

    Uh, I dunno. What problems were you having with families? (Oh, and we should probably take this conversation over to your Abdulah thread... no need to hijack Hitman.)

  • Heh, sorry. Being long-winded is a bad habit of mine

  • I don't think I will develop again without this feature.

    That's a little dramatic, don't you think? Why don't you just take responsibility for your backups? With any game project I have like thirty or forty versions sitting in a folder. I save new versions often just in case something bad does happen. It's best to err on the side of caution, that way when you do lose work (and it will happen) you've only lost a few minutes of work, rather than hours or days.

    You know where the save button is. It's not Construct's fault you don't use it as often as you should.

  • Ah, I see.

    Well, if you really want colliders at the edges of the screen then you would have to have them on a layer that matches the same x,y scroll rate as the layer your player sprites are on. This means that you will have to update your colliders x,y coordinates every cycle to match up with the scrolling screen. This can cause some buggy problems, though... if you manually set the x,y of a solid object like your screen barrier, then it's possible to move it into a position where it intersects with your player sprite. It would take a lot of tricky custom events to compensate for this.

    If you're dead set on having barrier objects then you might do something like giving your barrier Bullet Movement. That way you can tell it to move towards where you need it on the screen rather than set it's x,y manually (it will still "push" solid objects rather than intersect with them). But even this method is getting rather complicated and convoluted for what you want to do.

    The simplest, most efficient method would be to ditch the detectors altogether and use math. If you don't want your sprites to go half-way off the edge of the screen then make your edge collision condition look like this:

    sprite.X Less than (ScrollXRight-numOfPixels)
[/code:2yo1b835]

This will check whether your sprite is inside the visible play area as compared to the right edge of the screen, where numOfPixels is the amount of space you want to leave at the edge.

If you want to check if it's in the play area as compared to the top edge, you'd do like so:

[code:2yo1b835]
sprite.Y Greater than (ScrollYTop+numOfPixels)
[/code:2yo1b835]

You can check your second player's location just as easily using x,y value comparisons, so there's really no need for the barrier objects.

  • Okay, I'm a little confused so let's see if I've got this right... you want to keep something from going offscreen, but you still want scrolling? Correct me if I'm wrong.

    The best way to do it would be to check an object's x,y coordinates with the visible edges of the window. It's a quick value compare, which is much more efficient code-wise than setting up collision boxes. Any time you are able to do something with just math, it's a good idea to just work it out. Checking the edge boundaries is quicker than calculating collisions, and having no collision boxes at the edges means less objects.

  • It used to do that for me as well, I think it was the way I had the forum bookmarked. Now I just bookmark http://scirra.com and select the forum link from the menu and it auto-logs in normally.

  • Solid objects on different layers should collide by default, but for best results the two layers should have the same scrolling rate. If you have different scrolling coefficients on the different layers (like a hud layer set to 0,0 scrolling) then you'll get some funky results. It doesn't seem quite perfected yet. Parallax is best suited for display stuff only though, really. I can't think of a reason why you'd need things on different layers with a different scroll rates to collide.

    If you want non-solid objects on different layers not to trigger overlaps, add an "obj1 is on layer obj2.layer" condition to the collision event.

  • Okay, fine.

  • <img src="http://xs124.xs.to/xs124/08061/wackygopher362.jpg">

    Fixed.

  • Emoticon games are really just an in-joke of Facepunch...

    Ah, I was wondering what was up with all the emoticon stuff.

  • A little running animation for Dr. Chromis:

    <img src="http://xs124.xs.to/xs124/08061/chromis-run647.gif"> <img src="http://xs124.xs.to/xs124/08061/chromis-run_lg121.gif">

    I'm not an expert pixel artist, so crits are welcome...