R0J0hound's Forum Posts

  • Here's an example. I think it's cool the planes never collide.

    dropbox.com/scl/fi/yzoz4teghe9etfoa2qml8/flower_path.capx

  • I only use the free version but generally nwjs is not equal to webview2. Namely webview2 hasn’t implemented all the features available in nwjs.

    So basically file a few feature requests for the webview2:

    * be able to hide toolbar

    * fix window.open(url,””,”popup”) to open a new window instead of a new tab.

    Changing the title should be simple in js with:

    window.document.title = “new title”;

    You can also change the title of the popup window with:

    let popup = window.open(url,””,”popup”)

    popup.document.title = “new title”;

    Or you can change it in the html page from the url.

    If that doesn’t work with the webview2 export then file a third issue. Or you can also stay with nwjs.

    Having the two windows interact is up to you. In JavaScript you have access to the popup window to be able to call functions as seen above. And from the popup window you have access to the parent window with window.opener. You can do what you like with that.

  • I’d argue that the web has an inadequate feature set for that. Window.open() can create a separate window but it’ll have to be an entirely different page, it can’t just render parts of the existing project. You’ll probably need to load the same project twice and somehow communicate that the new instance should be a toolbar, or you’d have a specific project per sub window. Also you’re limited with how you can customize the window. It would be dependent on extra features provided by nwjs or webview2 if any. By default the popup window includes a title bar and the url bar and you can’t remove them.

    To communicate between the two you can just utilize some js functions. Basically when you create a window with window.open() it returns the window’s global scope.

    You can transfer things between the two any way you like but you could look into the drag drop api to see if that’s useful.

    developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API

    You won’t be able to do stuff like dragging the toolbar of the window to do that though. The browser just doesn’t provide access to such things. More is theoretically possible in a wrapper such as nwjs but even that doesn’t provide stuff like that. Overall not much is implemented to help with that.

  • Changing the timescale wouldn’t do anything about making it run faster, and ideally you wouldn’t use any waits. Wait 0 is a handwavy way to address a quirk with the picking system related to when stuff is actually destroyed or when created objects are generally pickable. It’s not that it takes time to happen, it’s more that the objects are actually added/removed from the object lists in between top level events (events that aren’t sub events of anything).

    Anyways another benefit of using an array is you avoid all the nuance when dealing with picking.

  • Have you tried not using a behavior and moving the object directly with the polar equation r=a*cos(2*theta)?

    Something like:

    Var theta=0

    Var rot=0

    Every tick

    — sprite: set position to 320,240

    — add 30*dt to theta

    — sprite: move 200*cos(2*theta) pixels at angle theta+rot

    That will move it along the path and it starts on a leaf. You can rotate the whole path with the rot variable.

    You can also change the angle of the sprite to be at the angle its moving by saving the old position before moving and setting the angle to angle(prevX,prevY,x,y) after you move it.

  • What have you tried? There is a rotate action for the sprite object. Run that every tick and it will rotate and change the angle of motion of the bullet behavior. You can just fiddle the number till it’s rotating a satisfactory rate. You can also incorporate dt so it will rotate consistently no matter the frame rate. For example rotating by 100*dt will make it rotate 100 degrees per second

  • I just mean instead of creating all those sprites in grid positions and then picking them later, you could just set values in a 2d array and be able to access grids directly without picking. Its main con is it’s less visual than using sprites.

    Other than that the general logic should be the same. Updating only the parts that change instead of the whole thing is a decent idea to make it perform better.

    I don’t have much input about what may be amiss with your event logic though. It’s kind of a more hands on thing and I presently don’t have a whole lot of time for that.

  • You could do something like:

    Var i=0

    On click

    — Set x to ChooseIndex(i, 20, 50, 300)

    — add 1 to i

  • If that runs at the start of your game you can use get a value from the time, for example "Hello"&int(time/0.2).

    Other than that, you could use an instance variable instead of a static variable.

  • You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

    dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

    That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

  • You're probably on the right track for a way to do that. Basically, drawing to a 2d grid and then looping over it to find the edges.

    Your screenshotted events aren't working because you first pick one point, but you can't pick the second point when the first is already picked. A quick fix would be to add a "pick all point" condition after the finding if the point was blue.

  • What have you tried so far? Generally most would just use the physics behavior for that. Turn off gravity and add a lot of linear damping to the balls so they slow down.

    That would basically be sliding circles and can look good enough and is easy to do.

    More advanced would be to model the balls as actual 3d balls with more elaborate physics. That would be done by either wiring in a general 3d physics library or rolling your own specialized 3d physics.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • So a damped spring works well for getting the position to match but since the target is moving we probably want to match the velocity too.

    If you assume the target is moving at a constant velocity or with a constant acceleration it’s fairly easy to predict where it will be in the future. Ideally you’d take the predicted path and the path of the crosshairs and solve it so that they cross paths at the same time. But I can think of a few reasons why that would be hard to calculate.

    Alternately maybe we could modify the formula a bit. It’s basically -spring*dx/dt-damping*velocity. So the damping is applied to the total velocity. Instead we could damp by the relative velocity. That would let it settle on the path the target is moving instead of lagging behind. So something like this? I haven’t tested it.

    Scope: Add -0.005*(scope.x-target.x)/dt-0.1*(scope.vx-target.vx) to vx

  • You mentioned a rubber band so you could do that with a damped spring. Basically add two variables for xy velocity: vx,vy. Then do the following. You can tune it by changing the 0.005 and 0.1 values. You can use any value from 0 to 1. The first value is the strength of the spring and the second is the amount of damping to apply.

    Compare: dt > 0

    -- add -0.005*(scope.x-target.x)/dt-0.1*vx to vx

    -- add -0.005*(scope.y-target.y)/dt-0.1*vy to vy

    -- scope: set position to (scope.x+vx*dt, scope.y+vy*dt)