R0J0hound's Recent Forum Activity

  • You could run the contents of the editbox as JavaScript using the browser object's execjs action. That is the simplest but the feedback would basically just be a return value. I suppose you could add some functions that call c2 functions to provide more feedback. But arbitrarily running js is an issue since absolutely any js can be run, which can be an issue.

    You can look at the browser and function objects in the manual to see what I talk about above.

    A more advanced thing you could do is make your own parser that reads the editbox a character at a time to do your own coding language. This gives much more control or what can and can't be done by the user. This can be as complex or as simple as you like. Probably not easy if it's not something you've done before.

    I've done some expression parsers before that you can find on the forum, but reading outside sources may be more useful.

    I guess it depends on what you actually want the code to do specifically and look like specifically.

  • I got it working here. I set a global from one instance and was able to access it from another. Not sure if I can do anything too useful yet beyond that.

    Uou can only run js you include in your edittime or common.js. It's basically just plain js and anything the editor provides.

  • Either of those could be a spot to put a global value, but you may be better off making your own global variable. I think the edittime.js is put inside a closure so vars there aren't global as you say.

    I fount this snippet online as a way to get the global namespace.

    var global=Function("return this")();

    After getting that you can add a global variable with:

    global.myvar=1337;

    Then using something like:

    alert(myvar);

    Should work in any other edittime.js after that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • No, it's pretty limited. Instances can only access themselves.

    Here's all I've found to be available at edittime:

    I suppose you could make a global js variable and store references there. I think I've tried it one time, but I forget why it didn't work out.

  • Here's my current test for the adjusting of the normal for bouncing:

    https://dl.dropboxusercontent.com/u/542 ... oTest.capx

    You can drag everything around, and the red line is the visual normal and the blue line is the the corrected normal.

    The issue as you describe is when the angle the balls travel are perpendicular to the blue normal. Which would mean it's there is no perpendicular motion to reflect so it doesn't bounce.

    Mid typing this I re-uploaded the file with an idea that seems to work. It takes both the surface angle and the angle of the ball and doubles the y component before calculating the bounce. Then it halves the y component of the resulting angle.

    So if you end up using the normal from the ray caster plugin just add or subtract 90 (it doesn't affect the math) from that the get the surface angle.

  • Just halve to y component to do it:

    angle(0,0,cos(ang_surface), sin(ang_surface)/2)

  • That good it worked. The surface angle in my formula is 90 degrees from the normal angle so that explains why you needed that tweak.

  • The wait shouldn't be needed in this case. Wait is only needed when you create a physics object with events and you want to add joints to it. Why? because the behavior needs a tick to update the positions in the physics world. It's a quirk and when I made the chipmunk behavior you don't have to worry about such things.

    Anyways with your capx you just need to disable collisions between your physics objects. The collision polygon means they are overlapping so they will move out of each other and the joints will try pulling them into each other so it turns into a fight.

  • You could use anglelerp(350, 20, 0.5) to take into account wraparound.

    If you're using 2:1 (width to height) isometric then here's a way to get it to bounce correctly:

    1. first if you use the bounce action with events you can get the the before and after angles which then can be used to calculate the surface angle. A simple formula to calculate the bounce is "angle_out = 2*surface_angle - angle_in", which can be manipulated to "surface_angle = (angle_in + angle_out)/2".

    2. That angle is the visual angle. To get the iso angle you take the angle and convert it to x and y components with trig. x=cos(angle), y=sin(angle). If we double the y then use the angle() expression on that it should give us the corrected surface angle. Basically "new_angle = angle(0, 0, cos(old_angle), 2*sin(new_angle))".

    As an example looking at the image in the op, the bottom left edges of the diamonds are at 45 and 26.2 degrees. Then using the formula above we can convert 26.2 to 45.

    3. Once we have the corrected surface angle we can calculate the bounce angle again with "angle_out = 2*surface_angle - angle_in". Completed pseudo example below:

    number ang_in=0
    number ang_out=0
    number ang_surface=0
    
    on ball collides with wall
    --- set ang_in to ball.angle
    --- ball: bounce off wall
    --- set ang_out to ball.angle
    --- set ang_surface to (ang_in+ang_out)/2
    ---set ang_surface to angle(0,0,cos(ang_surface), sin(ang_surface)*2)
    --- ball: set angle to 2*ang_surface-ang_in[/code:2hbesvcv]
    
    One caveat is the result isn't quite perfect because the bullet behavior seems to calculate an approximate surface angle.  In my test it calculates the bottom left edge as 27.5 degrees instead of 26.5.  As a side note it should be 26.5 because atan(y/x) or antan(1/2) is approximately 26.5.  Anyways to get more precise surface angles we need to find the angle ourselves.
  • Fervir

    Effects don't work for this plugin. You can try the Paster plugin instead which was made with more webgl support.

  • I'm not sure a list of supported resolutions is relevant since full screen just scales up the game to cover the entire screen. Aka it doesn't change the actual display resolution, at least I don't think it does.

    Here's the api provided by nwjs which you probably can access from the browser object.

    http://docs.nwjs.io/en/latest/

    I didn't notice anything to get a list of resolutions there.

    If you really want a list of supported resolutions you could make a nwjs addon that calls winapi functions to get that info. I think there was a construct classic example that used some Python to do that, although the actual c code to do it should be pretty easy to find online.

  • No, you'd need an exe export so you can add additional code to do stuff beyond what browsers allow JavaScript to do.

    It's unlikely someone will get this working though.