oosyrag's Recent Forum Activity

  • No I think he posted the wrong screenshot - you can see it clearly if you head to negative y and negative x coordinates on the noise in the example project he posted.

    I don't think its a bug. Its probably just the way the example project was put together does not handle negative coordinates well, but I haven't examined it enough to see why yet though.

  • Looks like common practice for animating diagonal directions is to set animations based on angle of movement, rather than inputs.

    Edit: Setting an instance variable, and changing the animation only once per tick based on that variable also seems to work, like so: 

    + Keyboard: ↑ is down
-> Sprite: Set anim to "up"

+ Keyboard: ↓ is down
-> Sprite: Set anim to "down"

+ Keyboard: ← is down
-> Sprite: Set anim to "left"

+ Keyboard: → is down
-> Sprite: Set anim to "right"

+ Keyboard: ↑ is down
+ Keyboard: ← is down
-> Sprite: Set anim to "upleft"

+ Keyboard: ↑ is down
+ Keyboard: → is down
-> Sprite: Set anim to "upright"

+ Keyboard: ↓ is down
+ Keyboard: ← is down
-> Sprite: Set anim to "downleft"

+ Keyboard: ↓ is down
+ Keyboard: → is down
-> Sprite: Set anim to "downright"

+ Keyboard: ↑ is down
+ OR Keyboard: ↓ is down
+ OR Keyboard: ← is down
+ OR Keyboard: → is down
-> Sprite: Set animation to Sprite.anim (play from beginning)

+ System: Else
-> Sprite: Set animation to "idle" (play from beginning)

  • I'm actually not sure what's happening here. There's some conflict with your other animation events. If you disable the walk right event it works fine, but I'm not seeing why at first glance... Will check it out some more later, or someone more familiar with animating 8 direction would probably know.

  • It works... Unless you've got a keyboard that can't have s and d pressed at the same time, which is extremely unlikely but not impossible. Is your animation set to looping?

    You're probably going to need to upload your project to see what's wrong with it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Computers don't care if they have to add 10 or 100000000, but if you divide first before adding, that's two things the computer has to do instead of one...

  • I don't think there is a simple solution to this problem, it's a pretty classic issue with pathfinding and collisions.

    A common solution is to disable collisions/solid behavior during movement. That is probably the easiest way out, and also quite effective for most people's purposes.

    Otherwise, you're looking at predicting the future position of each object, and probably also a queue for each position since there can still be conflicts. I don't know how exactly to go about doing this, but there are algorithms out there, specifically the parts regarding leader following and queueing. Those articles are not for tile based movement, but any concept regarding grid coordinates can be applied to tiles as well.

  • CSS will apply to the entire object.

    You probably want BBCode, but I think that's only for the text object. Not sure you have any options for inline styling of a text input object.

  • Looks fine to me, it should work. What is wrong with it? Is your event sheet linked?

  • It works fine. Your logic is just getting tangled. You should separate out what you are trying to do, dont tie the bullet creation loop to your state change/cooldown.

    For example 

    | Global number burst‎ = 5
+ Touch: On any touch start
+ System: Repeat burst times
-> System: Wait LoopIndex×0.1 seconds
-> Player: Spawn Bullet on layer 0 (image point 0) (create hierarchy: False)

    Works perfectly fine.

  • Tween might be suitable.

    Otherwise before tween was a thing I had made it standard practice for similar situations to use an event to catch the overflow, such as when value>target, set value to target. Using the min() expression can do similar if you want to compact your events.

  • Pretty strange. The grid movement target is one cell short of it's next waypoint upon start of layout, but I don't know why either. After aggroing them and resetting to patrol state, it works perfectly fine...

  • Oh I got confused. I guess it's always centered on the viewport rather than the layout. Don't think there is any way around that then.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 38 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies