R0J0hound's Forum Posts

  • Making an expression parser would be useful to do that. It's basically what you're describing. First step is to break the text up into tokens (numbers, operators and names). For speed you could make a regex to do that. Then with the tokens you'd make a parser.

    Here's a rough outline of the grammar the parser could use. 

    script: name assignOp exp
exp: atom [op atom]*
atom: number | name
number: digit+[.digit+]
op: "+" | "-" | "*" | "/"
name: letter+["." | letter]*

    I've made a few parsers in constuct in the past with various levels of complexity. I think you can get away with making it simpler if you cut out most error checking and order of operations perhaps. I'll try to wip something up with just a dictionary in c2 and that should be able to be translated to C3 and json if it works out.

  • I'd start from scratch. First off it uses the triangle3d plugin, which is older. The rojo3d plugin is better.

    Th 2d one transforms some points with two rotations, then projects them to to the screen. for the 3d you'd need to rotate by the same two rotations. Should be simpler with rojo3d, but i don't have time to create an example at the moment.

  • No raycasting or collision detection was added.

    A raycast could be done by finding the intersection between a ray and a triangle. Well, all the triangles (or less if a spatial partition is utilized) and just keep the closest. You just need the triangles of the mesh to be transformed to world space for each object. Currently that is done on the gpu, so it would have to be done on the cpu.

    In some cases you can do something simpler. Say you just have a heightmap you can query the z at some xy with an array or something. Like say you have the mesh made up in blender you can render the zbuffer from above and load that image to query zheight from pixels. Only 255 levels so it may be a bit coarse.

    Another idea is if you are just using primitive shapes you can do a raycast with signed distance fields (SDF). I made a simple C3 example of this somewhere. It could be useful in some cases.

    If you just need the position of a point on a mesh, you can position another object relative to a different one and you can get the transformed position from expressions. It's probably not what you're after though.

  • I say it's a valid complaint. Things shouldn't just silently disappear.

    In Construct 2 it alerted you when moving a variable to a different scope and it caused things to be removed. And moving a global variable to a group does change it's scope.

    However I tested it in Construct 3 r323 and it doesn't alert you. Sounds like a bug to me since it used to notify you in Construct 2. I guess it's always been that way in Construct 3 since I tested as far back as r100 and it still didn't notify you. It's probably just something they overlooked. I think there is a stickied topic on how they prefer to receive bug reports.

  • I put other. I always start with one sheet, then use functions, groups or other sheets to organize later.

  • The hardware changing explains most of it. It went from everything having indexed palettes to full 24bit color.

    So now it’s usually faked with a shader. Replacing a color at a time is the most flexible albeit slowest way.

    Effects in construct only can utilize a subset of what can be done with shaders.

    The fastest way could be to to only make an images with red 0-255 and use an array uniform with the palette and just use the red as a lookup. It’s a bit tedious to create the art that way, and besides it’s not really feasible to modify the construct renderer to do that.

    Another way to fake it is by just duplicating sprites to have different colors. Yet another is make the sprites out of multiple parts and change the color of those as needed.

  • In general I'd recommend using the paster object instead of canvas for performance reasons. That said I have no solution for this. What happens when loading a texture from an url is the texture is set to some temporary texture until it's loaded. Hence the flicker.

    Any fix would have to be internal, but I'm not working on this anymore. I simply don't have time to fix things if I accidentally break it. But what would need to change is either keeping the current texture until the new one was loaded or making the copy from sprite action support other types beyond sprites. The plugin wasn't really made with other object types in mind.

  • Using anglelerp() instead of lerp() probably will help. Sounds like the issue is when crossing the 0 seam, like going from 0 to say 359. With lerp it takes the long way around but anglelerp will use the shortest angle.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here's an updated way to do the connections. Basically a separate edge sprite that stores the two connected object uids. The example works with one sprite type but you can use a family of sprites instead.

    dropbox.com/s/lsazeyasqrsa2g6/lines_between_sprites3.capx

    The scripting idea is interesting but you probably want to nail down how you want it to work precisely before implementing it.

    Simplest to me would be similar to how construct's events work. Maybe something like: 

    if object:condition then object:action
if door:opened then door:close

    Or maybe this? This may be better suited for visual scripting. The flow would be top down/left right. You'd have three building blocks. 

    * "object:condition" which only continues if true
* "else" which runs if the connected condition is false.
* "object:action" which does something.
    door:closed -> player:hasKey -> door:open
    event:clicked
|
v
door:unlocked-> else -> playSound:doorRattle
|
v
door:opened -> door:close -> playSound:slam
|
v
else -> door:open -> playSound:creak

    Anyways, just some thoughts. I suppose the conditions could be made more distinguishable somehow. The ideas can be extended but I think simple is key. To run it you can either have it trace down the list and do stuff a step at a time or build some other intermediate form. Again, I think simpler is better because it reduces the need to check for invalid linkages. As is you should only need to check to make sure you didn't create any loops with the links.

  • Not sure. It’s an issue with the physics behavior. It jumps because it can take a frame to update the collision shape or something.

    In the past doing things like making the objects immovable for a frame helped. You’ll just have to fiddle with it.

  • Here are two other examples. On discord there were some other examples using other ways too.

    dropbox.com/s/i7vrebn55xor8p5/mesh_slice.c3p

    dropbox.com/s/cra289zoqzdfiui/tiledbg_slice.c3p

  • Sorry, I don't have that behavior installed and those are too many events to sort though. The idea was to get you started but likely you'll need to extend it or fix it. What you're basically doing is making a platform behavior.

    Here's another more complete example in 2d. It's still rough, but should help show some ideas with how to implement it. Or how not to, it could be too rough. In general I don't think I'll be perfecting it so hopefully it's helpful in some way.

    dropbox.com/s/9kiu6a4gm896qkq/rough_event_base_platform.capx

  • Events are a bit quirky. Here's a slight variation.

    dropbox.com/s/vivuxtpf99f5o5r/red_around_green.capx

    Also from my knowledge of how picking works your events shouldn't be working, and didn't test as working in C2. If picking logic is changing in C3 then my examples will start not working as intended.

  • The rough logic is to keep track of what block the player is standing on, then when that block is moved you’d move the player the same amount.

    As a simple rough example in 2d you could do this: 

    Player overlaps platform at offset 0,1
— set platform.x to platform.x+1
— set player.x to player.x+1

    There are probably more precise ways to get what the player is standing on. That and you can move the platforms in more deluxe ways. For that you may just want to keep track of the offset the player is from the platform.

  • You either set it up to only create the sprites if the space is free or remove the duplicates after.

    One way is to use an array to keep track of occupied spaces. 

    start of layout
— set array size to 1000,1000,1
— for each island
— — array set at island.x/16, island.y/16 to 1
— for each island
— — array at island.x/16+1, island.y/16 = 0
— — — create wall at island.x+16, island.y
— — — set array at wall.x/16, wall.y/16 to 1
… same for other directions

    You could also use a tile map instead of the sprites for similar results. Probably could end up simpler.

    Another idea is to clean up the duplicates after. 

    start of layout
For each island
— create wall at island.x+16, island.y
— …other directions

Start of layout
Wall overlaps island
— destroy wall

Start of layout
Repeat wall.count times
Wall: x=wall(loopindex).x
Wall: y=wall(loopindex).y
Repeat wall.pickedCount-1 times
Pick random wall instance
— destroy wall

    At least those are two methods. Another could be to store xy pairs of created walls in a dictionary and check if a location is listed before creating.