dfyb's Forum Posts

  • happening on XP, too

    edit: wish i knew what i did to get it working that one time... but i've tried dragging these things every way i can think of.

  • Hmm, maybe this is a Vista bug. If you change the order of the layouts and it starts on the wrong layout, does it still do it when you save and reload the .cap? If so, can you send me one of these .caps that runs layouts in a different order to the way the project bar shows them?

    well i can, but whenever i load the .cap, it returns to the original layout order -- it's as if i never changed the order.

    *change layout/event order around

    *save

    *close (edit: to specify - i closed the layout using the x under the top bar)

    *open

    and this is what i see

    <img src="http://upload.dfyb.net/uploaded/order_bug.png">

  • > i've been dragging up and i've found that my change doesn't stick. i can drag the second layout up to the top and it acts as intended -- it's listed first (though it still loads the engine layout when testing it). but if i save and restart construct, it's back to its original order. i've also tried adjusting the order of the event sheets, but they seem to have no effect. i'm on a vista machine right now -- i'll test at home later today to see if i get the same problem.

    >

    Strange. If you do it with a new .cap does it do the same thing?

    not all the time. i made two new .caps trying to troubleshoot this. one had same problem, but another actually worked -- unfortunately, i don't know what caused this disparity. pretty sure i always dragged layouts upward though, rather than dragging the first layout down.

    i'll be home soon, and i can see if my XP machine performs any differently.

  • i've been dragging up and i've found that my change doesn't stick. i can drag the second layout up to the top and it acts as intended -- it's listed first (though it still loads the engine layout when testing it). but if i save and restart construct, it's back to its original order. i've also tried adjusting the order of the event sheets, but they seem to have no effect. i'm on a vista machine right now -- i'll test at home later today to see if i get the same problem.

  • > if i drag a different layout above the engine layout in the project menu on the right... it doesn't change which layout loads first (this was the first thing i tried).

    >

    It does, I just tried it - a horizontal line appears where the layout can be dropped. All you need is a blank layout as the first layout which jumps to the layout you want.

    yeah i tried it, too. i even started a new file to test it. in the project menu to the right, i can drag another layout above, sure -- i see that horizontal line and all... but it doesn't actually have an effect on which loads first when i test the application (no matter what, the original layout created with the .cap will load first).

    edit: i seemed to get it working on a new file... still not working with original. i'll play around with it more.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The first layout isn't your engine if you add a new layout at the start!

    i guess i'm a bit confused as to what you mean by this...

    if i drag a different layout above the engine layout in the project menu on the right... it doesn't change which layout loads first (this was the first thing i tried). i can't seem to change order in the event sheet editor -- just add/delete.

  • Layout 1 always loads first. If you want to change it, insert a layout at the start of the application, and have an event like "Start of layout - go to layout 3".

    i had tried that, but because the first layout happens to be my engine (and is adopted by other layouts), it ended up getting itself into a loop of changing layouts where the application wouldn't even pop up and i had to close it via task manager.

    in a future version, could it be possible to specify which layout is called first (in project properties)?

  • seems like a simple problem, but i'm not finding any luck. i guess i could rearrange which event sheets are used by each layout... but that seems like an obtuse solution.

  • That's actually a point of the gameplay - it's creating a rhythmic experience. At least, I hope it is

    Does it feel cool, drumming your fingers on the keyboard? That's what I'm going for.

    ah, yeah i wasn't considering the whole rythm thing. but right now it doesn't demand precise (or necessarily rythmic) key presses because you only need to press it before the line. have you considered requiring to press the button while the square is overlapping a line?

    edit: regardless, i think you should wait until you get sound working before fine tuning the gameplay -- have you tried the xaudio2 beta? it should work with vista

  • pretty cool, but i wish that the color didn't reset after going through a line... if there's 3 yellow lines, i just want to press s once.

  • Thanks for the help Dfyb, Mind if I use that (or modified version of) code in my own game?

    you can definitely use it -- if i release a .cap, it's free game

  • version 2 of mouselook -- now you can assign something like shoot to a mouse click without trouble (i demonstrate this with a muzzle flash).

    couple of things though --

    i'd like the devs to add condition "compare mouseX" -- to get around this, i set a global variable to mouseX and compared that, but it seems like that should be unnecessary.

    the only way i found to find the edge of the window was to use the window object, and i found that it included the border of the window.. which made things a tad more complicated. i wish it was easier to just find the edge of the gameplay area.

    it's not perfect -- you can break it if you move the mouse extremely fast, but i'm not sure it's possible to fix that -- even great retail games like counter-strike suffer from this

    edit: also, when i set mouseY to the same value every tick, it seems to cause some problems when moving the mouse right.

    updated it with a more complicated way to restrict the mouseY that doesn't give you choppy movement at slow speeds. re-upped the choppy version with a comment. slowly move the mouse right to see the difference.

  • Wow... with strafing and mouse aim... that's like a real FPS! Amazing stuff! Have... ten bonus points...

    You could keep the mouse inside the window by wrapping it when it gets to the edge of the window - not the edge of the screen.

    yeah i was trying to see how that'd be possible...

    edit: ah, the window object seems to be my golden ticket. will have new .cap when i finish

  • Making it full screen like, I dunno... every other FPS game on the market... would fix the problem of the mouse focus.

    ~Sol

    well of course, but that's not really a solution to the problem -- merely a way to avoid the problem.

  • got mouse aiming working (along x axis).

    edit: i might be able to improve on this so that mouse clicks would be useful in windowed mode.