R0J0hound's Forum Posts

  • So you’re using the array so that its size is:

    (Count, numProperties,1)

    And you access values with:

    Array.at(n,property)

    Where n is the index to the object and property is:

    0 for x

    1 for y

    2 for zindex

    3 for name

    … and so on if you add more properties later on.

    Looks like you already have saving down but here is an example. You can set the array size first and just fill in values but I find it’s easier to increase the size as you add objects, especially if you have multiple types you’re saving. Anyways, “push” or “insert” basically will change the size of the array, but to be super clear about it you can just set a new size like here. 

    On function “save”
— array: set size to (0,4,1)
— for each sprite
— — array: set size to (self.width+1, self.height,1)
— — array: set at (self.width-1, 0) to sprite.x
— — array: set at (self.width-1, 1) to sprite.y
— — array: set at (self.width-1, 2) to sprite.zindex
— — array: set at (self.width-1, 3) to “sprite”

    For loading you’d still do “for each x element” instead of xyz. And you’d use array.at(n,3) to get what the name of the current object is. 

    On function “load”
Array: for each x element
— compare: array.at(array.curx,3) = “sprite”
— — create: sprite at (array.at(array.curx,0), array.at(array.curx,1)

    Now a further improvement so it actually loads the objects in the same zorder as you save it is to rearrange the order of the values to {zindex,x,y,name} and sort it. That would only change the save function. 

    On function “save”
— array: set size to (0,4,1)
— for each sprite
— — array: set size to (self.width+1, self.height,1)
— — array: set at (self.width-1, 0) to sprite.zindex
— — array: set at (self.width-1, 1) to sprite.x
— — array: set at (self.width-1, 2) to sprite.y
— — array: set at (self.width-1, 3) to “sprite”
— array: sort by x

  • Remove the trigger once. It does nothing when under a loop.

  • When creating an object at runtime construct copies the properties of the ‘default’ instance of that type. That instance is the first one placed on the lowest layer in the lowest layout with that instance. That’s why dop suggested having a layout with the default instances. It probably should be the first layout though.

    Another option is to use templates instead. Notice when you create an object you can specify a template. As I recall you can create a template in the editor from a selected instance. Do refer to the manual for specifics.

  • In that video no pathfinding is needed. If you give sprites the physics behavior they will not overlap. Just set gravity to 0 and apply forces to the objects to move them around.

    The pathfinding behavior does two things. It finds a path and moves along it. Anything we do to prevent objects from overlapping will be in conflict with it moving along the path.

    Probably a solution is to take the path and do the movement yourself instead of letting the behavior do it. Aka use the pathfinding behavior to find the path and the physics behavior to move it. Roughly you’d apply a force toward the first node of the path and once the player was close enough to that node you have to change to target the next one.

  • You have to add the sprite to a family so you can pick two instances independently

  • What if you generated a random number from 1 to 4 and if it’s 1 change the first variable, or if it’s 2 the second, and so on.

  • You don’t change it. It’s calculated from the fov so that the 2d layer is unscaled. Consider that property as just informational.

    If you want to move the camera you can with events.

  • You can’t independently scale the xy of a layer in construct.

    I guess drawing everything to a canvas and scaling that could be an option in theory.

    Another idea is having an effect to do it. Might be able to modify the pixelate effect to do it.

    Final idea is to just draw your graphics with double pixels.

  • I’m guessing you mean you’re using lerp like this:

    Set x to lerp(self.x, target.x, 0.01)

    That does slow down as it reaches the target. But to ease as it moves away you’ll have to do something different.

    I believe with the move to behavior you can specify the easing function as you move to a point. That would be the simplest solution.

    You can do the same with some math and a few variables. You’ll need the start and end positions and variable to indicate progress. For example this does an ease in and out.

    Var t=0

    Every tick

    — add dt to t

    — set x to cosp(startx, endx, t)

    Another idea is to use a velocity to control the motion. Could be as simple as adding 100*dt to the velocity to accelerate away. Maybe just switch between lerping accelerating away.

    Yet another idea is to do the easing with a damped spring. You’d need the velocity and two variables k and d which control the spring stiffness and damping. Both are in the range of 0 to 1. Fiddle with the values to control motion. Could be useful when the target constantly moves.

    Compare: dt>0

    — ufo: add -k*(self.x-target.x)/dt-d*self.vx to vx

    — set x to self.x+self.vx*dt

  • You are getting the object type, and that doesn’t have a text property. You need to get the instance from the type to be able to access text I imagine. Refer to the docs, tutorials or examples on how to correctly access an instance.

  • After some digging I found this site that gives a 1 inch square, at least on my phone. 

    https://www.hyperspaces.co.uk/device/

    The code can’t be used without permission it seems but looking at the code shows how it was done.

    Looks like it works by roughly having a list of all devices and their physical screen sizes, and using the values provided by the browser to figure out what device is being used. However in many cases it mostly has to guess.

    It’s probably as laborious to do as it sounds, and will only be good for the devices it knows about.

    Other than that it’s as Ashley says, it’s not possible to get the physical screen size from the browser with JavaScript. Everything I’ve found either says it’s not possible or is wrong.

    The only other idea is if you’re doing an android or iOS export they may be able to access stuff like that. But it just depends on what is exposed to the sdk.

    A setting for the touch controls scale seems like the easiest solution.

  • Jase00

    It wouldn’t corrupt a project. In general plugins can’t corrupt projects. They can only crash the editor or runtime.

    Worst case is if the plugin relies on some undocumented construct feature that changes in a new release. All that means is the plugin dev would need to update the plugin or you’d need to stay on an older construct release in the meantime.

  • If you made the movers slightly smaller it may help. The reasoning behind that if the collision will only be triggered once per the objects overlapping the walls.

    You could also try adding a “for each mover” to the on collision events. The reasoning for that is if the on collision condition picks all the colliding movers in one shot it could possibly need to be handled one by one but I haven’t looked at your events too closely.

    Third thought is the bullet behaviors bounce action may not be robust enough to be super reliable. But that’s just a thought

  • Try opening the browser console and see if typing that function, registerProcess, is defined.

    If it is then it likely has to do with the scope that c3 ran the script you typed. It’s probably mentioned in the manual.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There is a wrap behavior that kind of does that. But it’s imprecise.

    You also do the wrapping with events and make it a bit better. Here for example the screen is 640 pixels wide. It’s the most basic example and you’ll see when the objects jump from one side to the other. 

    Object: x<0
— object set x to self.x+640
Object: x>640
— object set x to self.x-640

    You can solve that by making the position jump further off screen by some margin. A good rule of thumb would be a margin at least as wide as the widest object you’re wrapping around. 

    Object: x<-margin
— object set x to self.x+640+margin*2
Object: x>640+margin
— object set x to self.x-640-margin*2

    Now that’s is the scroll position is to the left of the layout. You could make it relative to the screen if you really need to.

    For doing it with a tiled background you’d just need to have the tiled background’s width to the imageWidth+screenWidth and the events would basically be: 

    tiledbg: x<imagewidth
— tiledbg set x to self.x+imagewidth
tiledbg: x>0
— tiledbg set x to self.x-imagewidth

    Now if you change the x by more than the imagewidth it will take more frames for it to catch up. Adding a while condition above the x compare conditions is a simple fix. There is probably a nice math way to correct it without a loop too