deadeye's Forum Posts

  • If this helps: Latest version of Construct, Windows Vista32, python 2.5.1 installed on my system.

    Thanks

    I'm pretty sure you need Python 2.6.

    Uh... I could be wrong about that . In fact I probably am. I'm not very familiar with how Python works.

  • You could store the path as a string variable for later use.

  • You don't even need an invisible sprite if you don't want to use one. Just add/subtract from a couple of global variables and scroll to those values.

  • This is a great request and all which I'd personally like to see, but shouldn't this really be on the 'Feature requests' board?

    Yes it should... moving thread.

  • Congrats, Linkman

    And welcome to the Brotherhood. We live a life of simple servitude. In order to remain pure in our service to the forum we observe a strict vow of chastity.

    Wait... Ash did mention that part before you signed up, right?

  • You do not have permission to view this post

  • Actually that looks pretty much dead on. I think what your noticing is what you would call an optical illusion.

    That was my first thought too. But after a while of staring at it my eyes went screwy and I couldn't tell what was going on any more

  • Well, you're not really doing it "wrong" per se, but the way you have one object sending commands to another object which sends commands to another object makes a sort of sticky web that's hard to untangle.

    Re-usability is fine the way you describe it... for one-off things like shooting bullets or making explosions. Yeah you can have the objects take care of that themselves because explosions and bullets are just fire-and-forget kinds of things. The problem of dependencies here is that your fade behavior on your CoreSpark is sending out commands when it should be acting more like an explosion or a bullet. It's a just special effect. But since you have the next sequence of events depending on whether or not CoreSpark has faded away, it's suddenly become an important, center-stage player and without it the whole show stops. The Core should be deciding what happens to the CoreSpark, not the other way around. Or better yet, the Core should just create the CoreSpark, and then forget that it even exists, and just go on to do it's own thing. Let both Core and CoreSpark fend for themselves.

    That's the concept of encapsulation. Information is restricted between objects. Each object is doing it's own thing without knowing what the other objects are doing. Your Core doesn't need to know that your CoreSpark is done fading. Therefore, the CoreSpark can safely be removed and there is no adverse effect on the rest of the game.

    There were some other examples of things like this going on in your game logic, but I'm not on my Construct computer right now so I can't recall exactly what they were. And like I said, it's not really "wrong," it's just harder to unravel.

    Anyway, I still haven't really gotten a chance to take more in-depth look into your .cap yet. I'll let you know when I do. My guess though is that it's going to end up being bugged somehow, so in the mean time if you can try paring it down to just the components necessary to recreate the bug then that would be good. That's all I'll be doing anyway, I can't see what else there is to do.

  • Glad to see you're still hard at work on this .

    That's a strange problem, though. At first I thought maybe it was just an optical illusion because they're changing angle so fast, but yeah... it does appear that they are speeding up on tight corners. Weird.

    Good luck on figuring it out.

  • You do not have permission to view this post

  • Well, that is the damnedest thing. It's happening for me every time, not just randomly.

    I can't see what would be causing that. I'm trying to pare down your .cap to just the necessary components, but it's really difficult because you have so many objects that depend on other objects, rather than a master timeline. For instance, I can't delete the CoreSpark (which for all intents and purposes is just a decorative item) because without it's fade behavior, the Core can't set it's speed to escape. You have all these odd dependencies like that littered everywhere which makes it hard to track down what's affecting what.

    You should look into some encapsulation methods to separate each of these components from each other. Your game objects should be taking commands from as singular a source as possible, rather than talking to each other... if you get my meaning.

    Anyway, as near as I can tell something is bugged, I just don't know what. I'll try to trace it down but it's going to be a while until I can get into this further.

  • I guess this means I can't use any built-in behaviors, because they all use timedelta, right? Pretty annoying.

    Well if you don't like timedelta then yeah, I guess so. Hope you don't mind if I still use them.

    Good luck with your game.

  • You do not have permission to view this post

  • Using timedelta isn't all that hard once you get used to it. If your FPS target is 60 then this:

    Sprite: Set X to X + (100*timedelta)
[/code:28zr4w5q]

will move your sprite at a rate of 100px per second to the right, and this:

[code:28zr4w5q]
Sprite: Rotate 180*timedelta
[/code:28zr4w5q]

will turn your sprite around a half turn every second.  Basically timedelta is the time between the last tick and the current tick, which changes from tick to tick because rendering time fluctuates.  Over the course of one second, all the deltas should average out to a total of 1 (1 / 60 = 0.0166... seconds which is the average time between ticks).  So if you're moving something at 100px*timedelta, then in one tick it will move on average about 1.6 pixels.

There's a good amount of info on timedelta on the wiki, you should check it out.

  • I'll try to replicate it in a fresh layout, this one is a little busy and far from finished to put it up (but if there's no other choice can do that too).

    Please do, that sounds very odd. I have no idea what could cause that to happen.