R0J0hound's Recent Forum Activity

  • Worst case you can use a css injector on your browser to change it.

    I did it here to change the pink to a cyan, but you probably could change more.

    construct.net/en/forum/scirra-website/website-issues-and-feedback-35/less-pink-175696

  • You can load it into the json plugin no problem. Then it’s just a matter of taking the data and creating equivalent construct stuff.

  • Else after a looping event block doesn’t seem too defined to me. Also you are toggling the Boolean instead of just setting to true. I suspect that is part of your issue.

    That said those are just general thoughts. I cannot follow your events and only have a vague idea what they are supposed to be doing.

  • Basically that. I’d have it replicate what’s on screen though. Or just a layout sized area centered on the screen.

  • So the issue is “Sprite: has LOS to sprite” is picking itself? The solution is to use a different object. A family with that sprite is one solution

    Which would look like this: 

    For each sprite
Pick otherSprite by comparison: otherSprite.iid <> sprite.iid
Sprite: has los to otherSprite
— do something

    You can also do the same with another dummy sprite. The idea is you create one per sprite instance. So there is a setup step, and an update step. Well unless you pin them together. 

    Start of layout
— dummy: destroy
— for each sprite
— — create dummy

Every tick
— dummy: set position to sprite

For each sprite
Pick dummy by comparison: dummy.iid <> sprite.iid
— do something

  • Trig functions in construct take degrees instead of radians. To fix your formulas just replace 2pi with 360

  • I get that you’re using unbounded scrolling but if the map is fixed you could just put the whole thing within the layout bounds.

    Since you’re doing it for control you could replicate obstacles on screen to the layout bounds, do pathfinding there and just move the player from that. You just have to deal with the offset from the screen to the layout bounds. Bear in mind pathfinding will be done with only partial knowledge of the map. Guess this is similar to shifting things around to make the on screen stuff be on the layout.

    Third option could be rolling your own pathfinder. The pro of that is more control. The con is more work to make it match what the behavior does.

    One idea could be using Dijkstra's algorithm from the player’s position to the target. Instead of a 2d array of the cells you could do a sparse array with xy pairs as keys for cells. Or you could use astar. The idea is we have more options for how we define the graph of walkable nodes. The behavior uses a 2d grid of cells within the layout bounds. What i mentioned above is a sparse 2d grid of cells with no bounds. Beyond that there’s navmeshes or similar stuff.

    If your obstacles are mostly convex then you can get decent pathfinding with raycasts and wall following.

    Kinda just throwing a bunch of ideas out there.

  • I prefer using multiple events over wait. Seems cleaner to me and keeps the events running in place.

    Honestly when new objects are pickable is one of the ugliest parts of the event system. If you don’t understand it it’s confusing, and annoying when you do since it feels like you’re doing code juggling to work around it.

  • It’s actually sooner than the next tick. What you can do is split that into multiple start of layout conditions.

    So instead of this which doesn’t work since the for each doesn’t have access to the newly created sprites. 

    Start of layout 
— repeat 10 times
— — create sprite at random(100), random(100)
— for each sprite ordered by sprite.y
— — do something

    You can do this which will work. The second start of layout has access to the newly created instances. 

    Start of layout 
repeat 10 times
— create sprite at random(100), random(100)

Start of layout
For each sprite ordered by sprite.y
— do something

    In general any instances you create in an event aren’t pickable until the next “top level” event. A top level event is an event that isn’t a sub event of another event. They can be inside a group though.

    An alternate way that’s popular in the community is to use a wait. It effectively delays events from running until way after the created objects are pickable in general. I say way after since the shortest wait is 0 which seems to delay till the end of the event sheet.

    That would look like this: 

    Start of layout 
— repeat 10 times
— — create sprite at random(100), random(100)
— every tick
— — wait 0 seconds
— — pick all sprite
— — for each sprite ordered by sprite.y
— — — do something

    Which works fine in a simple case like that but it makes it really hard to follow the order events run with heavy use.

  • You probably should have asked this in the Construct 2 section since it uses a C2 only plugin. Anyways, I won't be able to debug/modify your capx but here is an example of the idea I posted above to do box collision response.

    dropbox.com/scl/fi/od9ncndg8fnsioaijjgr4/cloth_verlet2.capx

    It's not really building onto what your other capx does since I made it from scratch. But if you copy the sdf function, and add events 15-16 to yours before you update the velocity variables it should work.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Basically you start with equations for the path the objects would go if the stayed at the same speed.

    Position = start_position + velocity*time

    That can be split into two formulas for x and y motion. And you’d also have one equation for the target and one from the bullet. Then you just solve the equations for the bullet velocity. Or just the bullet angle if you make the speed fixed. It’s just a matter of using algebra to solve it.

  • So you have ten instances of one type and the type has a Boolean you want to set when there’s another instance nearby? I think using the variable name “nearest” is throwing me off, “near” could make more sense if I’m understanding it right.

    A common way to reference other instances of an object type is to add a family and add that object type to it. Here I named the family “other” and the events could look like this: 

    Every tick
— sprite: set near to false

For each Sprite
For each other
Compare: Sprite.uid <> other.uid
Compare: distance(sprite.x, sprite.y, other.x, other.y)<50
— sprite: set near to true

    An alternate way is to use sprite(iid).x to reference other instances. No family needed. 

    Every tick
— sprite: set near to false

For each Sprite
Repeat sprite.count times
Compare: Sprite.uid <> sprite(loopindex).uid
Compare: distance(sprite.x, sprite.y, sprite(loopindex).x, sprite(loopindex).y)<50
— sprite: set near to true
R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • 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
  • Forum Wizard Made 5,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
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies