deadeye's Forum Posts

  • First you will need to add a Mouse&Keyboard object to your program.

    Since you're making a custom movement for your object, remove any movement plugins you have added to it.

    Then in the Event Sheet Editor, make a new event to check for controls being pressed:

    1. Right click the Event Sheet and select "Insert Event."

    2. Double-click the Mouse&Keyboard icon and select "Control is down." Click Next.

    3. Type the name of the control to check for in between the quotes. (The default key controls are called "Move Left," "Move Right," etc.) Your condition is now set up.

    4. Now click on "+ New Action" next to the condition.

    5. Double-click the sprite you want to move.

    6. Scroll down to "Size and Position" and select the appropriate Set command. For instance, if you want to move left or right, pick "Set X."

    7. A new window appears asking for the new X coordinate. We want to add to the coordinate while the key is being held down, so we need to call the current coordinate. Delete the "0" in the box and double-click your sprite.

    8. Scroll down to Size and Position and select "Get X." Click Finish.

    9. Now you will see the name of your sprite in the New Coordinate box. (You can type this in manually if you want, instead of clicking to pick your sprite.) If the player is pressing right, we want to add to this value. type in "+5" (without the quotes) after spriteName.X. Click finish.

    Your event is done. Now every time you hold down the right arrow, your sprite will continually move five pixels to the right every cycle.

    You can rotate the sprite the same way. Just create a condition, and in the new action choose an option under the sprite's Angle section.

    Hope this helps.

  • When you edit a sprites icon and attempt to place an image point in the image editing window that pops up, you will get an error message, which reads:

    <img src="http://img206.imageshack.us/img206/4810/94103256fa0.png">

    Are you editing the icon or the sprite itself?

    Because trying to put an image point on an icon crashes for me, too. Which makes sense, at least... the icons don't have image points. It's just an icon, not a sprite. The image point and hotspot options shouldn't even be available when you edit an icon.

  • I can't use float values either, and i've tried both in 84 and 85. When i enter 0.5 (or 0,8) It just deletes the decimal.

    That's... really weird.

    Are you able to change the Z to a decimal value at runtime with the event editor?

  • Hot damn, I'm going to check out the animation fixes as soon as I get a chance.

    Thanks, Ash!

  • I whipped up a small demo of how someone might make a platfomer that uses physics instead of manually updating the XY coordinates of sprites.

    You can jump off of platforms and objects with the Z key, and kick objects around with the X key.

    The custom movement was actually pretty easy to make. No need to check if the sprite is intersecting with the ground, and run loops to push him out, because collisions and gravity are automatic with Construct's physics.

    Here's the .cap:

    http://projectbrimstone.googlepages.com/kickit.cap

    It's heavily commented and should be pretty easy to follow.

    Some other notes:

    • Be sure to check out the player and kick sprites to see how the image points and hotspots are set up.
    • The player sprite has two private variables set up, "direction," and "kickTimer," both of which are used to control the kicking action.
    • The Gravity, Mass, and Angular and Linear Dampening for objects have been changed from the default settings to get a more "platformer" feel.
    • There is a minor bug where the objects sometimes stop responding to collisions with the kicking sprite. I believe that this is because I haven't specified which individual object should be colliding. You could probably make a loop during the kick routine to check for collision with specific objects, and that would take care of it, but I'm lazy so who cares.

    Some general tips I picked up while working with the Physics movement:

    • Objects rotate according to their hotspot placement.
    • The bounding box is also set according to the hotspot placement! WTF?!?
    • If you want perfect rotation and collision between objects, make them an odd number of pixels high and wide, so you can set the hotspot directly in the center of the object.
    • Use "Ellipse" for the collision mask on round objects. Duh.

    Comments? Suggestions? Ideas?

  • Well, it's still a bad thing. In MMF2, rearranging your events fixed this bug. Anything for rearranging update priority?

    I don't think so, at lest not yet.

    MMF2 still does the same thing if you use a movement plugin. When I use the Platform Movement Object and set my detectors to it, they lag behind as well, and no amount of rearranging the events fixes that.

    You can work around it in MMF2 by setting a separate player sprite on top of your PMO sprite, and then aligning your detectors to the player sprite. The whole package lags behind the PMO, but at least the detectors are updated correctly in relation to the player sprite.

    With the physics movement though, if you were to make the physics object invisible and set a player sprite on top of it, you'd get wonky looking collisions.

  • AHH! Found bug! In the cap, double clicking the 10 event (set velocity) makes colour settings popup.

    I know, I've been having a problem with that too, I just haven't gotten around to reporting it yet. I should be more on the ball <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

    Whenever that happens, I've been having to just delete the action and write it again from scratch. Alternately, you should be able to "soft click" the numbers themselves to change them right on the event line without having to open the edit action window.

    Edit:

    Doh! Beaten by Ashley.

    Also I think this is a bug : why there's a delay when the detector should be in the player position? I mean, jump, and the detector will work like an elastic.

    The delay is there because the physics engine is updating before running the events, so there's a bit of a lag. Since it's just detecting when you're on the ground, it shouldn't be too much of a problem. If you were using it to, say, detect if you're stomping on an enemy's head, there would definitely be a problem.

  • So for example, positioning an object to the mouse coordinates, so you can make a brick follow the mouse, and move/slow down with the force of the mouse. So you could use the mouse to pick up an object and wack other objects with it.

    I suppose you'd do it by checking where the mouse is, and where the object is, and working out how much force it would need to have moved to that position.

    You could do it manually by setting up some "lastMouseX" and "lastMouseY" variables, then check them against the current mouseX and mouseY. You could calculate speed and direction that way, and translate it to the object you're dragging around. Even if you're "teleporting" it to the mouse coord every frame, if you're manually setting it's x and y velocities then other objects will still react to it in a proper way.

    As a test, I created two objects and added physics movement to them. Then I made this event:

    Always: 
[ul]
	[li]Sprite: Set velocity to (20,0)[/li]
	[li]Sprite: Set X to mouseX[/li]
	[li]Sprite: Set Y to mouseY[/li]
[/ul][/code:u3qrhsk8]

When I move the mouse around, the sprite sticking to it jitters, because it's trying to "escape," but I can drag it into the other sprites and they'll fly off toward the right as if they were hit naturally.  It even calculates the angles of impact correctly, so they're not just flying straight to the right, but angling up or down depending on where they made contact.

If you were fully calculating the speed and trajectory by doing something like comparing "lastMouseX" with "mouseX," you might be able to avoid the jitter that comes with manually updating the velocity of the object you're dragging.

Alternately, when you click to drag an object, you could make it invisible, then position a "dummy object" that matches it at the mouse's xy coord.  Since it's just a regular sprite with no physics, it wouldn't jitter.  Then when you release the object, discard the dummy and make your original object visible again.

With some clever collision routines you could even check to see if there's an object to impact with between lastMouseX and mouseX, and change the mouse position manually to compensate for it so that you're not intersecting things.  Hell, you might even be able to fake velocity, mass, etc. for the mouse itself by manually updating it's coordinates.  I'll have to play around with it some to see what I can come up with.

    It'd be great to have a platform movement who could go round shoving bricks and such.

    Well, you already can if you do it custom. I made a platform prototype where the player input changes the sprite's velocity and such. You can also "kick" objects around. It wasn't terribly difficult, really. It took longer to comment it than it did to make.

    Here's a .cap:

    http://projectbrimstone.googlepages.com/kickit.cap

    Just one small bug that I can't be bothered with figuring out right now, and that is sometimes the kick collision stops registering. I think it has to do with not defining specifically which object to kick, but I can't be arsed to fix it right now. Even so, it still works pretty well as a proof of concept.

  • There's also the ability to include multiple event sheets on one layout, so if you have a section of events that you need to run on multiple frames, you don't have to copy them repeatedly to different frames.

  • Ah, I see. Well, I was way off. But hey, we both learned something today <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I decided to try using Construct's physics engine to make a fancy screen saver, since a screen saver is basically just an .exe labeled as an .scr. And hey, what do you know... it works.

    Just one problem though, and that's when I install the .scr in my system32 folder and go to select it in my screen properties, the name doesn't show up in the screen saver list properly. Instead, it's labeled as a number. The first time I did it, it showed up as "3." I exported another .exe, making sure to label all my layouts and such properly, thinking that maybe it was just because I left the program title blank in Construct, but then when I checked my screen saver list again it showed up as "4."

    I can select this number and set it as my screen saver, and it works fine, but it was kinda bugging me that it didn't show the actual name.

    Anyway, I opened up the .scr in Resource Hacker to check the string tables and see if it was pulling the 4 from one of them. The only listing in the string table is this:

    STRINGTABLE
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
{
1,    "4"
}
[/code:2wrptwbe]

I guessed that this was where Windows pulls the name of the application from, so I changed the string with ResHack.  Sure enough, it showed up in the screen saver list properly... but changing the table also made my screen saver crash.

Should Construct be filling this spot on the string table with the app name when it exports an .exe?  Is this a bug, or am I just being fussy?

  • 1) 3D Boxes don't manage collisions. This is annoying, you have to create colliders for everything! There are 2 problems : neither starting the condition from a 3D box nor from the object that must collide with it works :

    When sprite collides with 3dbox = events (nothing happens)

    And, you can't even manage collisions in 3Dbox.

    2) Depth too high by default. The "1" depth we have now should be 5, since we can't use decimal numbers.

    I'm really begging you to add collision support

    I've been working with the 3D Box quite extensively and I'm afraid I can't recreate any of the problems that you're having.

    I made a test .cap to see if I could test for collision between a sprite and a 3D Box. I gave the sprite 8-Dir movement, and added this event (just as you described:

    Condition: On collision between Sprite and 3D Box:

    Action: Sprite2: Set X to Sprite2.X+10

    Every time I collide Sprite with 3D Box, Sprite2 moves ten pixels to the right. Here's the test .cap to see for yourself:

    http://projectbrimstone.googlepages.com/3dCollisionTest.cap

    This is with the 3D Box's "Solid" attribute turned off.

    Now if you turn on Solid, then I can recreate it. Your sprite and the box won't be able to overlap and register a collision, at least with the default movements. It seems like Construct is checking objects against their Solid attribute before checking the event list, so objects with Solid turned on will be pushed apart before the collision condition occurs.

    As for the Depth, I'm really confused. I can enter in decimal values just fine:

    <img src="http://xs321.xs.to/xs321/07465/3dboxdepth.jpg">

    The Depth and Z values for these boxes were entered into the 3D Box Properties without any problem.

    As for collisions with the 3D Box, you have to keep in mind that the box is just a rendered overlay on top of a 2-dimensional bounding box:

    <img src="http://xs321.xs.to/xs321/07465/3dboxbound.jpg">

    The collisions between the box and other objects occur at the bounding box, regardless of it's Z depth. This means that even if it appears "above" or "below" your sprite, it will still collide at the bounding box.

    --------------------

    EDIT:

    As Ashley said, the "bounding box" is actually a mask of the back face, but the idea is still the same. It's a 2D area that stays on the same Z plane as your sprites.

    --------------------

    As for your back face rendering: The faces are one sided. This is the default with just about every 3D program. The faces won't render unless they are facing toward the display. Try changing the yaw of your box to rotate the back face forward and you will see it.

    I've been meaning to ask if Ashley would put a "Render 2 Sided" option in the textures panel, but he's busy with other stuff right now and I've already asked for a crapload of features for this object <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

  • Hey everyone, i was wondering why i do not have this:

    It's not a bug. You have to add the Physics movement type to your sprite under the Movements section of your sprite's Properties panel. Just click "Add" next to New Movement and select Physics from the list.

    <img src="http://xs221.xs.to/xs221/07465/movement.jpg">

    <img src="http://xs221.xs.to/xs221/07465/new.jpg">

    You will see the default Physics settings for your sprite in the properties panel.

    Now when you insert a new event in the Event List Editor you will have access to your sprite's movement values and actions.

    Here's a tip: If you want an event to begin by comparing your sprite's mass, or whatever, don't start off the condition by picking your sprite. For some reason the Get values don't show up in the sprite's condition panel (I believe that is a bug). Instead, double-click the System icon and scroll down to the Values section and select "Compare." You will see a generic compare panel. Under Value 1, delete the zero and then double-click your sprite. Now you will see your physics tab. Select the physics value you want to compare and go from there.

    I've found that the generic Compare under the System events generally works better than trying to call up values directly from your objects, at least until the bug is fixed.

  • not much on this site in terms of actually creating something!

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

    I've been toying around with the idea of making a series of "Mini-Tuts" for beginners that just cover some of the basics like how to use the interface and understanding events and commands and such. It would be beneficial to me as well, since I learn best by teaching. Noobs helping noobs, as it were.

    Another reason to do it is because having some sort of content in the help section would likely draw in more users. Construct is seriously lacking any sort of reference material right now, which is likely keeping at least some new users away.

    And since I support Construct, I feel I should help in some way, other than making suggestions or bug reports. I might not be able to help out with coding, and I might be too poor to donate, but I can write <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • When i mentioned my game running slow, it was when using the game maker program. At most, 3 of my NPC's had at -most- 1000 events running at the same time, and it lagged my system:

    One thing you should know before using Construct: it is very different from Game Maker.

    Instead of defining every action and event on a per-object basis, there is an "even sheet" that is separate from your objects. This means that instead of putting, say, control actions in your player object, you tell the event list to get the input, and then tell the event list how to move your player sprite. And instead of 1000 events per NPC object (for 3000 events total), you would just have to put that 1000 events in your event list one time, and each NPC would use that single list. All higher quality game dev programs use this method, from Construct to Torque to MMF, etc.

    Game Maker by comparison is a clunky, inefficient piece of junk. For instance, the "Your First Game: Catch the Clown" tutorial is almost two and a half megabytes when it's compiled, and that's just for a single sprite that bounces around the screen for you to click on. And when you run that program, GM is so choked up that that single sprite is jittery and blurry.

    I made a platformer demo from scratch in Construct in under a day, which has twenty-seven 3D objects, a player sprite with animation, and a tiled, parallax scrolling background. The .exe it exported is only one megabyte, and... get this... there are only 15 events in the whole program. Eight of those are events that manually make one of the 3D objects do something that it's not designed to do automatically. And it runs as smooth as silk on my crappy-ass computer.

    So yeah, it's fast. And it's efficient. And even though it's just in beta right now, and still has a few buggy problems, it's a damned sight better than GM. I've read that Yoyo Games is re-writing GM from scratch in C++ so version 8.0 should be a bit faster, maybe even "twice as fast." Construct by comparison is already hundreds of times faster.

    Also, Construct will probably be a little confusing at first if you're used to GM. After using it a while, though, I think you'll see how it's more logically organized and ultimately easier to use. GM is just so backwards it boggles my mind.