R0J0hound's Recent Forum Activity

  • A quick possible fix could be to scale down the acceleration a bit until it’s not adding energy to the swing.

    A likely difference between textbook physics and game physics is game physics is what you call discreet. Aka stuff is done in steps instead of continuously, which depending on the integration method can add or remove energy from the system over time.

    Anyways, I can’t spot offhand what’s amiss with your method.

    Here’s on strategy to do pendulum motion. Basically just let the player move as normal with gravity and whatnot, but once the distance is greater than the rope length it will correct the velocity and position of the player. The velocity correction is done by canceling the part of the velocity going away from the anchor, and the position correction moves it back toward the anchor till it’s at exactly the rope length. 

    vars dist, ang, relvel
Set dist to distance(anchor.x, anchor.y, player.x, player.y)
Set ang to angle(anchor.x, anchor.y, player.x, player.y)

Compare: dist>rope.length
— set relvel to player.vx*cos(ang)+player.vy*sin(ang)
— player: set vx to self.vx-relvel*cos(ang)
— player: set vy to self.vy-relvel*sin(ang)
— player: move rope.length-dist pixels at angle ang

    Just an idea at least. That rope will have a hard length limit to it.

    Instead of just canceling any velocity that would make the rope longer, you could do the acceleration idea with a spring, but I’m not sure it would come out to what you had.

  • One idea could be to move the thrown objects manually vertically then horizontally. Doing that allows you to have logic where if the block starts on the ground it will stick to the ground including slopes.

    A first iteration of that logic to make the thrown block stick to slopes when moving horizontally would be something like this: 

    Every tick
— block: move down

Block: overlaps ground?
— block: move up out of ground
— block: move horizontally
— block: overlaps ground?
— — block: move up out of ground
— else
— — block: move down till just above ground
Else
— block: move horizontally.

    The moving up out of the ground, or moving down till just above the ground is a sub problem that probably could be solved with a loop with overlap checks and moving a bit each step.

    Now I call that a first iteration of the logic since depending on the map you don’t want all the ground to be thought of as a slope. You’d likely want to be able to handle walls, ledges and ceilings too. But that’s mostly just busywork.

    Just an idea at least that you could explore.

  • Well with your current setup after you move things around in your array, you’d want to loop over the array, pick the objects by uid and update the position from the array.

    If that doesn’t make sense then maybe you want to move and wrap those objects around in another way?

    One possible way works if those five instances are the only instances of that object type and you places them in the editor from left to right.

    You’d then add an instance variable “oldx” to the object type and you’d swap the positions of all the instances to the one on the right (or rightmost with leftmost) with: 

    On key pressed
— sprite: set oldx to self.x
— sprite: set x to sprite(self.iid+1).oldx

    To move left instead you’d replace the +1 with -1.

    Or you could do something else entirely.

  • Events start with all the instances picked, so yes count will equal pickedcount before you use a condition to pick less instances.

  • Use cursor.pickedcount instead.

  • What users? What api? What database?

    Unless you make a game that requires a login and requires their email in the registering process you won’t get emails of people.

    Considering your post isn’t spam you haven’t written a complete thought.

  • It’s working here as well. So might not be an issue with the server.

    If you still error out with a different device on the same network then maybe try a different network as a test. Your phone is an easy test for this. You can load c3 on WiFi vs cell data. If it fails on WiFi but not on cell you could try resetting your router maybe.

    Looking back at your pc, you know it’s probably not a browser or browser addon issue since you tried multiple browsers. I’m guessing it’s probably not another software affecting it unless someone else installed something. You could check through the installed software if you really wanted to, to see if anything stands out.

    Searching online for that 400 error sometimes it’s suggested to clear the dns cache on your operating system in case part of the cache got corrupted somehow. That has something to do with the operating system caching website names or something like that. Anyways, on windows you can do this by running this command on a command prompt: 

    ipconfig /flushdns

    You can lookup the articles in question if you need some credibility to do that. You might get the same effect by resetting your network adapter, or maybe just resetting your pc.

    Anyways, just some ideas to help narrow down where the failure is coming from.

    Edit:

    Good informative link on the dns cache clearing

    pcmag.com/how-to/how-to-flush-your-dns-cache

  • You could also use the mouse.x(layer) expression to get the mouse position off a specific layer.

  • I’m pretty sure construct comes with a normal map effect you could try to use. Or just try that third party effect.

    The only other way to do effects is to make your own effect addon. There’s a tool to help with that you could try that there was a recent post about.

  • It's a quirk or feature depending how you look at it with how created objects aren't generally pickable right away or how destroyed objects aren't destroyed right away.

    The logic behind it is under the hood the event system maintains four lists of instances of the objects. 

    sprite.all = []
sprite.picked = []
sprite.new = []
sprite.deathrow = []

    At the start of an unnested event picked is set to all the instances. Conditions after that will filter the picked instance list.

    When you create an instance the picked list will be set to only the new instance and that instance will also be added to the new list.

    When destroying an object it will be added to deathrow, but it won't actually be removed yet.

    So eventually the event engine has to do some bookeeping and update the all list by adding new instance to it and removing deathrow instances form it. Generally that occurs after each unnested event. However, trigger events that were called from another event don't follow that since they can be considered running in place where they were called.

    To illustrate that here is a simple example. 

    On click
-- create sprite
-- call function
-- sprite destroy

on function
-- create sprite

    Ok, now here is very verbose view of what is going on with those lists following those rules. Lets assume you started with one instance of sprite: A. 

    # all=[A] picked=[A] new=[] deathrow=[]
On click
# all=[A] picked=[A] new=[] deathrow=[]
-- create sprite
# all=[A] picked=[B] new=[B] deathrow=[]
-- call function
# all=[A] picked=[B] new=[B, C] deathrow=[]
-- sprite destroy
# all=[A] picked=[B] new=[B, C] deathrow=[B]
## bookeeping is done here
# all=[A, C] picked=[A, C] new=[] deathrow=[]

on function
# all=[A] picked=[A] new=[B] deathrow=[]
-- create sprite
# all=[A] picked=[C] new=[B, C] deathrow=[]

    You encountered another quirk of picking when you used the sprite.count expression in one of your examples. Basically, if there are no picked instances of an object all it's expressions will return 0. So you had the following in your example. Since you stated with no instances there will be no picked instances in the function so the expression is 0. 

    On click
-- create sprite
-- call function

on function
-- set text to sprite.count

    or verbosely: 

    # all=[] picked=[] new=[] deathrow=[]
On click
# all=[] picked=[] new=[] deathrow=[]
-- create sprite
# all=[] picked=[A] new=[A] deathrow=[]
-- call function
# all=[] picked=[A] new=[A] deathrow=[]
## bookeeping is done here
# all=[A] picked=[A] new=[] deathrow=[]

on function
# all=[] picked=[] new=[A] deathrow=[]
-- set text to sprite.count
# all=[] picked=[] new=[A] deathrow=[]

    There may be better ways to convey how that works, but generally I've found most don't really grasp it.

    As to the wait 0 solution that has it's own side effects. The main one is it delays the stuff after it from running till the end of the event sheet, which may or may not be a problem if you are relying on things to run in a specific order.

    Another way around the picking could be "pick by uid" like dop suggested, but I've found that mostly only useful in simple cases.

    What generally try to do to avoid the create/destroy shenanigans is to create objects in one event and do the picking stuff in the next, but that largely depends on what you're doing.

    It's not really useful with nested events but for simpler ones like above I duplicate the event and split the events between them. 

    On click
-- create sprite
-- call function

on click
-- sprite destroy

on function
-- create sprite
    On click
-- create sprite

on click
-- call function

on function
-- set text to sprite.count

    Finally a third way is to deal with the picking system as little as possible and deal with lists of objects in a more traditional programming fashion. That's many's motivation to use js for example.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I thought the unofficial discord is basically the official one. All an official discord would change is maybe moderation by Scirra staff instead of community members?

    Anyways, I suspect the reason they never made an official one is simply because they never made one, and there’s no point of making an official one now since the unofficial one is well established and an effective hub in all the ways you noted.

  • 3d is ambitious, especially for 8 year olds.

    Anyways, here are a few ideas to help debug it.

    Since it seems to have to do with loading chunks as you move around, you could just make the camera have a top view to help see what’s going on.

    If it’s leaving gaps moving one way then maybe it’s overlapping the other way.

    When creating the chunks are you creating them relative to the player or to fixed chunk locations? A collision will occur after some overlap which can get worse with lag. Maybe that’s something to consider.

    If nothing obvious stands out I’d consider redoing the chunk system from scratch. You can prototype it fast in a fresh project in 2d if you like. That would be much easier to debug and identify shortcomings. You could even do it in 1d, like a side view platformer to get the chunk idea working with minimal effort. I personally find that designing something on paper first makes it way more robust than doing it all in code as you go along.