deadeye's Forum Posts

  • More feedback?!?

    Character doesn't jump while holding down.

    That's because Down+Jump is the control to jump off of a pass-through platform (the lego platforms). If you're standing on a solid platform, you can't jump downward.

    I'm like the ONLY person here who ever surfaces complaint regarding such, but since I use dvorak, x and c are an odd layout. It's not hard to switch back, but something like ctrl and shift would be more universal. However, I am under the impression that userdefined controls are a possibility?

    Perhaps this:

    < arrow is left, ^ is jump, > is right, Ctrl is attack?

    Well, user-defined is out (Construct limitations), but I can always just add more controls. It wouldn't hurt to have five different jump buttons.

    Okay, and I'm getting the random slight vertical shifting of all background graphics when I tap left and right spastically. The pink blocks fall out individually also, displaying their modular construction. Kudos!

    Ahrg, this is terrible news! It doesn't do this at all for me. Everything stays solid as a rock when I spaz it out like that. I have no idea what to do about this. Hopefully it's not too common an occurence.

  • Eh, don't worry about the PM, that's fine.

    But yeah, glad to hear some good news. According to both you and Dopple things seem to run okay speedwise. I was a little worried that I'd have to learn how to use Time Delta or something.

    This is the only thing that worries me:

    Some odd jumpiness with the lego blocks while running laterally, as they seem to... shift up and down like half a pixel, but, might be imagining it.

    This is an issue I was having with Tiled Backgrounds a while back. I filed a bug report on it. The platforms in this are just plain sprites, though, and I don't get the jumpiness.

    Dopple, do you get any jumpiness or jitters on the lego bricks when you run back and forth?

    Opstay on'tday ibgay.

    My piglatin's a little rusty... oh! I see. Tops don't gib. Yeah, I should have mentioned the gibs for the tops aren't in this build. Not to worry, they'll gib like crazy in the final build.

    And thanks for helping out, guys

  • Well that was fast.

    You must be some kind of programming machine. That, uh, programs programming programs.

  • There's no way to do this yet, but I'll see if I can add one for the next build.

    Awesome, thank you!

  • Okay, PM sent.

  • Oops... forgot to mention:

    For controls, if you press X while holding Down on a lego platform, you can jump down through it.

    And as a simple benchmark, on the start menu you should be able to pick a polka-dot when it appears on the right and count "one-one-thousand, two-one-thousand," up to six before it gets to the left edge of the screen.

  • Okay, PM sent.

    Anyone else want to have a go?

  • EDIT:

    I've decided to open this up to anyone who wants to test it out. If you're going to test this out please post a response.

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

    Controls:

    X to jump

    Down & X to jump down off of a lego platform

    C to swing your hammer

    The lego platforms are jump-throughable

    Everybody keep in mind that this is just a test level in an unfinished state, so there's a lot of stuff missing (some sounds, some sprites, the "About" screen, etc.).

    Please let me know if you get any graphics glitches like the ones Vrav mentions in his post:

    Some odd jumpiness with the lego blocks while running laterally, as they seem to... shift up and down like half a pixel, but, might be imagining it....

    Okay, and I'm getting the random slight vertical shifting of all background graphics when I tap left and right spastically. The pink blocks fall out individually also, displaying their modular construction.

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

    Original post:

    Blah blah blah I need a demo tested out.

    Basically what I need is one or two people with fast computers/good graphics cards/newer monitors to give my test level a run and see if it runs at a playable speed. It runs good for me, but I'm worried it may run too fast for most people.

    Any takers?

  • Is there a way to toggle between windowed and fullscreen at runtime?

    I can't seem to find any action that does this. I've checked through the system and Window object actions. Am I missing something, or is there just no way to do it currently?

  • While it might not be terribly helpful to all users, don't be discouraged from posting tutorials like this. We need more stuff like this on the forums.

    After Monday I'll be releasing my current project (my TIGSource competition entry) along with the .cap to anyone who's interested in it. I'll also make a thread going over a few of the tricks I used to make the game (like jump-through platforms and platform AI). It's almost complete, I pretty much just need to do the music and the level editing.

  • If I were to vote it'd be "no" but that's only because I just made a menu like this for my project about a week ago. Only instead of highlighting the menu options with color I used a pointer sprite:

    <img src="http://i28.tinypic.com/2l8aed5.png">

    Basically the same though

    But I won't vote "no" because that would be rude. I'm sure this will be useful to some people.

  • Okay, I had previously posted a thread here where I got a corrupt .cap back in v0.91 that had to do with global variables in events. Now I have another corrupt .cap that behaves the same way (opens to 90% then crashes Construct), only instead of global variables I was working with private variables in events.

    This is what happened leading up to when the crash occured:

    I had an event that was set up like so,

    + Always
[ul]
	[li]Sprite: Set position to object spriteBody (image point 0)[/li]
[/ul][/code:3jbg4zcd]

I added the private text variable "status" to the sprite, and set it's default value to "alive."

I went to the event sheet I was working on to control the sprite and changed the "Always" by double-clicking it and backing up to select the sprite instead of the System object.  Then I changed the event condition to test the variable "status," like so:

[code:3jbg4zcd]
+ Sprite: Value 'status' Equal to "alive"
[ul]
	[li]Sprite: Set position to object spriteBody (image point 0)[/li]
[/ul][/code:3jbg4zcd]

After making the change, I started making a new event:

[code:3jbg4zcd]
+ spriteBody overlaps spriteCollider
[ul]
	[li][/li]
[/ul][/code:3jbg4zcd]

I didn't finish the action in the event because I noticed that the change I made before didn't take.  Instead of showing "Sprite: Value 'status'" it said "Sprite: Value 2."  So I double-clicked the event and re-set it to "status," and it showed up normally.

That's when I noticed that the icon for the sprite wasn't the sprite's icon, but the system icon instead.  I immediately saved a new version and quit Construct.  When I tried opening it again, it crashed.

I think that the corruption came from changing the condition from a system trigger to a sprite trigger rather than just creating a new condition from scratch (hence the sprite icon changing to the System icon).

And that's about as specific as I can get.  Here's the corrupt .cap:

[url=http://www.mediafire.com/?oruo4ojtoly]http://www.mediafire.com/?oruo4ojtoly[/url]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That really sucks. It's weird that some people get all the bugs. I've only had like two corrupt .caps ever, back in .86, and one in .91. Both were fixed, and I didn't really lose any work.

    I never got the family-file bloat bug either. I kinda wish these major bugs were more universal so they were easier to straighten out.

    Great... now I've probably gone and cursed myself.

    Edit:

    WOW

    That could not have been more perfectly timed. I just got a corrupt and un-openable .cap. It wasn't having to do with layout order, though. Guess I'll make a new thread.

  • The problem why eventing in Construct is slow is because you're required to scroll down to get to several actions.

    I think a simpler solution is to replace the list with a tree. All items are collapsed by default, and a single click on an item will expand it. This will pretty much eliminate the need for scrolling, and will make eventing much quicker.

    I don't know about anyone else, but I've done so much event coding in Construct now that I pretty much have the list memorized. When I code events my scroll-wheel finger is on auto-pilot and stops where it needs to. Having a tree that you need to click on would just slow the process down by adding extra clicks.

    Unless Construct could memorize what nodes I have expanded so I don't have to click them every time. That would be okay.

    The one major thing I think would speed up event coding is sorting objects into folders, and having the option to exclude objects or folders of objects from the event lists (for instance, background tiles that don't have any purpose except decoration). But that's on the to-do list I think, so I'll just wait patiently.

  • Wow, that is funky. I didn't get what you were driving at before, but I can see it plain as day now.