deadeye's Forum Posts

  • Yep, I have plenty of time-based events that have just 1 condition such as : "If object value is equal to X"... and that seems to be as bad as "always"

    Before you go changing stuff, post an example of what you mean, just to be clear.

  • > I've never heard of that brand.

    >

    Really!?

    Plenty of different versions over here, from the cheap small ones for kids/hobby use, up to more professional models, and they sit alongside the Wacom ones in the stores.

    Maybe Trust aren't in America (although I thought they were American).

    Anyway, I still doubt it's the drivers as Scidave gets the same errors without a tablet connected.

    It could be a popular brand here, I don't know. I've just never heard of it .

    And anyway, what I meant about the errors is that perhaps the Python library just isn't recognizing yout tablet as a tablet, so it's behaving exactly the same way that it would if you didn't have a tablet installed.

  • 1 question : are simple events like: "if object value is equal to X" as bad as always?

    I certainly hope not

    Like I said, you only have to consider time when you are performing time-sensitive things.

    If you need to Always check a value, that's fine. If you need to Always update the scrolling to follow a player, that's cool. If you need to Always point at the the mouse, that's cool too.

    There's plenty of situations where using Always is a good idea, but if you are dealing with time then it's not a good idea.

    If you want to make a timer using Always, then you can do it like so:

    + Always
   -> Subtract 60*TimeDelta from TimerVariable
[/code:34sys8sk]

If your target FPS is 60 then this will subtract 1 every second from your TimerVariable.  TimeDelta is providing a method to measure time in this case.

Or you could do like so:

[code:34sys8sk]
+ Every 1000 MS
    -> Subtract 1 from TimerVariable
[/code:34sys8sk]

And it does pretty much the same thing, only in whole numbers instead of floats.

  • You do not have permission to view this post

  • If that's all you're doing then you could fake it pretty easily. Make some invisible solid objects that cover all of your tunnel areas. When the player presses the "squeeze" key, then change all of the tunnel-cover's collision modes to "None." While your character is overlapping the tunnel, just make sure the proper "squeezed in tunnel" animation is playing.

    Then only turn back on the "Bounding Box" collision mode if the player is not in contact with a tunnel, AND if they're not holding down the "squeeze" key.

  • In fact, I've never found a program that doesn't work with the pressure level feature of this tablet, so I don't know what it could be

    I've never heard of that brand. Maybe it's drivers do something weird and non-standard in order to run the device. It could be that the Python library being used just doesn't support it. I dunno, just a guess.

  • Just to clarify, you use Always when you need to perform an action every tick. This is for behind-the-scenes game logic, for the most part. Ticks happen at different rates on different computers. You don't want any sort of time-sensitive actions happening every tick.

    Any time that time is a variable in your actions, whether it's spawning enemies over time, moving objects (because speed is a calculation of distance and time), or simply counting seconds, you need to use Every X Milliseconds or TimeDelta to ensure that the rate stays constant across all systems.

  • Anywho, I wouldn't touch the "every X milliseconds" condition with a ten foot long clown pole.

    WHAT?

    THEN YOU ARE

    DOING

    IT

    WRONG

    Allow me to inform you of a little thing called framerate independence, forum member Oko. If you use Always, then what happens if you run the game on a very slow or very fast computer? The game will run slower or faster, that's what. People on slow machines will have an easier game, and people on fast machines will have a much harder game, because stuff is spawning at like, twice the speed or more.

    When you use Every X Milliseconds, you GUARANTEE that it will spawn at the same rate on all computers. REMEMBER THIS WELL. SEAR IT INTO YOUR BRAIN WITH A HOT IRON. YOU HAD BETTER START USING EVERY X MILLISECONDS OR I WILL HUNT YOU DOWN AND CRUSH YOU.

    Look up more info about this on the wiki.

  • Please. Please... please post how you did it.

    I am saying please but what I really mean is "for the love of God and all that is holy I will twist off your head and throw it into the sun if you don't"

    So... please?

    Anyway, I'm sure any family picking issue can be solved with lucid's S plugin, since you can do the family picking trick with that too, only without families.

  • Mine's a Wacom Graphire, model CTE-430.

    And as previously mentioned, your test works fine. I do have vanilla Python installed, but no other libraries.

  • Center View on Me is pretty much best for small, simple games or quick experiments. For flexibility though it's always a good idea to code your own camera movement instead, or use linkman's camera plugin.

  • P.S. - Nobody is going to "steal" your stuff. If they wanted to make a Mega Man clone they could just make the events on their own whether they're looking at your .cap or not. And it's not like they're going to steal "your" graphics... they're already stolen from Capcom.

  • Nah, forget it. I'm not just going to guess what your events are doing from a screenshot.

    Reproduce the problem in a smaller .cap and upload that. Otherwise, someone else may be able to help.

  • Your picking conditions are probably incorrect. You should at least be able to get it working with a For Each Object loop.

    Post your .cap so someone can see what's going wrong.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well, this issue is bugging me in a big way, since most of my more accomplished stuff is broken now in post 99.7 versions.

    Such is the way of large projects made with beta builds of Construct. I don't mean to sound harsh, but you can't say you weren't warned, and you can't claim that you weren't aware of the risks. Hopefully you can fix the issue by using a different method.

    And it's not the first time a project was in jeopardy because new features or fixes caused game-breaking results for an individual. The goal though is to make things stable and usable for future generations of Construct users. The good of the many outweighs the good of the few, or the one*. I too have lost work to the inexorable march of progress. Your sacrifice is not in vain, as v1.0 will be all the better for it.

    *Yes, I am a nerd who quotes Star Trek movies with a straight face.