spacedoubt's Forum Posts

  • yeah, I mean think about it.. as long as the y values are the same, it's just measuring a straight horizontal line.

    Let me get this straight:

    Player in center = object is right edge

    Player is at left edge = object in center

    Player at right edge = object half a screen beyond right edge

    Is that right?

    And you want to use the distance the player is from the edge to set where the object goes?

    I worked on this for a minute, and I just keep looping back around to setting the object.x to player.x + half a screen

    Is there some reason that's not an option?

  • Health - (Damage - Damage * Armor/100)

    must be Damage and Armor and Health.

  • It still sounds kinda like the viewport side is not what you really need to be relative to..

    If it's always the same distance from the player, I'd just attach it that way.

    But you can use distance(viewportright(layer),0,object.x,0) to get just the x distance.

    (add in your Ys for tops/bottoms and what have you)

  • Divide by 100 to get percent. (20/100 = 0.2 AKA 20%)

    multiply result to get percentage (0.2 * 60 = 12 AKA 20% of 60)

    subtract percentage from self (60-12 = 48 AKA 60 dmg - 20% (armor))

    subtract result from health (150 - 48 = 102)

    Health - (Damage - Damage * Armor/100)

    150 - (60 - 60 * 20/100) = 102

  • yes, but is that a problem?

    I feel like I am missing something.. heh. Is the object's position relative to the player or the screen edge?

    It sounds like you're saying it's relative to the player, and when the player is in their typical position (the center) that falls just to the right of the view? When the player goes left of center, does the object go left of the edge?

  • Look in to the 'Timer' behaviour...

    https://www.scirra.com/manual/167/timer

    Give it a shot, if you can't figure it out, let us know!

  • couldn't you just set it to be half the view width + player.x at all times? or did I misunderstand something?

  • I'm not sure it makes a whole lot of difference (I might be wrong). I suppose the less solid objects you have to use, the better.

    These are good reads if you haven't read them already:

    https://www.scirra.com/blog/83/optimisation-dont-waste-your-time

    https://www.scirra.com/manual/134/performance-tips

    EDIT: Also, I think if you'll search the forums you can find some threads discussing reasonable ranges of collision checks..

  • Well, I'd start with the manual:

    Collision checks/sec (e.g. 1144 (~22 / tick)): how many times in the last second the engine had to test for a collision between two objects. Collision checks are invoked by the On collision or Is overlapping sprite conditions, and many behaviors perform additional collision checks automatically. In brackets, the average checks per tick is also shown. For example if there were 600 collision checks in the last second and the framerate is 60 FPS, the estimated checks per tick will be 10. This tells you on average there were about ten collision checks per frame, although the actual value will often vary frame-by-frame.

  • My guess is there's less collision checks because half of the collision box is not on the screen?

    My other guess is that this isn't causing you any problems.. am I right? If not, why worry about it?

  • Try it!

    If you run into any issues, we'll help you fix it!

  • Okay.. so I THINK I can explain your problem, but I don't know the solution off the top of my head.

    In my examples, the pathfinding is not working how you want.

    In your example, the pathfinding IS WORKING how you want.

    However, collisions are not. I've seen people have this problem with bullet behaviour. I'll explain:

    Let's say your solid object is 8 pixels wide. let's say a bullet heads toward that object with a speed of 20 px/tic..

    This can result in the bullet jumping entirely over the solid, so no collision is actually registered.

    I believe something similar is happening to your pathfinders. Maybe when they turn or something, they become close enough to the other side of the solid, that they end up there.

    Honestly, I'm not completely positive on that.. (I could be completely wrong) but seeing as you don't seem to getting much help (rare around here), I figured I'd share my theory.. Hope it helps!

  • Could you not accomplish the same thing with, say, a blank dictionary? Am I missing something?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Are you sure this will not cause any problems?

    I can't think of why it would. Can you?

    Every game here does it that way: http://www.jadecupmaidhands.com/

    I've never ran into any issues.