Yann's Forum Posts

  • czar

    Yup good catch.

    Maybe put a link to your solution, if people have the same issue one day (:

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • yonda

    Actually I think round(random(0,3)) is wrong

    random(0,3) will give you numbers from 0 to almost 3

    so you'll get this repartition:

    0----------1----------2----------

    if your round that you'll get 

    0-----|-----1-----|-----2-----|-----
to 0  |   to 1    |    to 2   | to 3    

    So the rounding will introduce a bias toward 1 and 2 and reduce the chance to get 0 or 3.

    floor(random(4)), on the other hand, works because you get this:

    0----------|1----------|2----------|3----------
    to 0   |    to 1   |    to 2   |    to 3

    Hope that makes sense (:

  • Ludum dare, I haz it!

    http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=5046

    <img src="http://www.ludumdare.com/compo/wp-content/compo2/233892/5046-shot0.jpg" border="0">

    \o/

  • —

    hmmmmmmmm

    You mean, catching a trigger event in an infinite while loop?...

    hmmmmmmmm....

    Nah won't work if you work inside another trigger (function/on start of layout)

    So I don't see what you mean by that then (: example?

  • cesarzevil

    I don't mean to talk in place of Ashley but what I think could be a solution is:

    you send your capx to him, he can look at it and test it, and if he admits your game can't be optimize at all without entirely changing the gameplay, maybe, he can refund your license.

    But please don't take my word for it, it's just an idea. The problem with refund, is that he can't really inactivate your license file. So I'm pretty sure it's not something really possible.

    But at least, it would answer one important question: can your game be made to work on today's smartphones.

    Because up until now, except for angry useless provocative talks, nothing really changed. And I'm pretty sure that between a working game and a refund, you would rather prefer a working game.

    We don't really know if your low fps is a result of your inexperience, or really a too demanding design.

    If Ashley doesn't really have time to look at it, I'm pretty sure, you can send your capx to some of the guy here who proposed to help and have more than 2,000 Rep (which means they are pretty active here, so well known, so usually trustworthy and no thieves).

    We usually prefer to work on our own idea (:

    I would gladly propose to help, unfortunately I don't own any smartphone to test anything, so it would make things a bit hard.

    I could still look at it if there are obvious flows, but not much.

    Once again, please try to not get angry over people trying to help (:

  • Jase00

    As far as I know, all "object condition" (meaning, not the system conditions) behaves like this:

    - loop through all instances
[ul]
	[li]if an instance match the condition, add the instance to a picking list[/li]
[/ul]  -> then apply action to this picking list

    So with a pick by UID, C2 was looping through all the instances just to add one to the picking list (also called SOL for Selected Object List I believe)

    Which (unexpectedly for Ashley) worked well the other way around: if you invert the condition, you'll loop through all instances, and add all those which don't have the given UID.

    But in the last release, I think Ash added a way to get an instance via its UID directly.

    Maybe he has an Array with all the instances indexed via their UID, or rather a hashtable (another name for dictionary).

    Anyway, it's a faster way to use this condition since you don't need to loop through all the instances anymore.

    However, if there's no looping anymore and you use the inverted condition, you can't really get hold of all the other objects.

    In my opinion, since it not only breaks the use of [invert] pick by UID but also breaks the untold rule (or hidden contract maybe) of "if you use an object's condition there's a hidden loop going on to build a picking list", I think the old behavior should go back.

    But that doesn't mean he can't keep the optimisation for when you use pick by UID I think.

    He can probably do something like "use the old behavior, except for this tiny little situation where you use picked by UID not inverted" (:

    (although exceptions like this in programming are always kinda sad (: )

  • Jase00

    Can't you add a boolean like attacker.ignored and switch it to true (somehow), and then use attacker: [invert] is ignored instead of attacker: [invert] pick by UID someUID ?

  • JoyfulDreamer

    Yeah that's a valid way, I don't deny it. But the "asynchronousity" of the pathfinder makes it a bit of a pain to implement.

    (I think even the map generation is asynchronous and there's no trigger for that... might have to request that)

    And as far as speed goes, he only does that on start of layout it seems. So.. it should be ok as long as he doesn't have more than maybe 2000 grid cell (since I used recursivity, you might stack overflow)

  • Jase00

    Maybe you could show a sample of the code that is breaking.

    I'm wondering if removing the ability to invert pick by UID is a problem or not.

    In my situation explained above, I could solve the problem with a boolean.

    So it's less "sad" as I thought at first.

    But if you really found a case where the work around is messy, it would be a good argument to convince Ashley of the necessity of it (:

    also, I don't really understand how using Object UID exists is really equivalent to Pick by UID as suggested in the changelog.Pick by UID' is now not invertible (use 'Object UID exists' system condition instead)nless Ash meant it as "now you don't need to use Pick by UID to check if an object's UID exists" But I don't think it was the principal use of this action.

  • Ashley

    It's sad but there's no real equivalent to 

    Sprite: [invert] pick by UID

    anymore.

    I was actually using it a lot for connecting nodes (spliting games, node base system, etc)

    The basic pattern I was using was:

    // create a new edge and save the UID of first node
+ Mouse: on left click on node
   -> System: create object edge at node.X,node.Y
   -> edge: set new to true
   -> edge: set firstNode to node.UID

// a new edge as been created
+ Edge: Is new
   // a close node other than the first Node -> we snap the edge to it
   + node: [invert] pick instance with UID edge.firstNode // so I pick every other
   + node: Pick nearest to (mouse.X, mouse.Y) // amongst every other node, the closest to the mouse
   + distance(mouse.X,mouse.Y,node.X,node.Y) < SNAP_RADIUS
      -> edge: Set angle toward(node.X, node.Y)
      -> edge: set width to distance(self.X,self.Y,node.X,node.Y)
      -> edge: set secondNode to node.UID

   // no close second node -> we follow the mouse
   + else
      -> edge: set secondNode to -1
      -> edge: set angle toward(Mouse.X,Mouse.Y)
      -> edge: set width to distance(self.X,self.Y,Mouse.X,Mouse.Y)
....

    Now, to be able to do the same I'll probably have to foreach through all the node, flag them with a boolean and then pick using this boolean, and to the nearest thing.

    That's kinda sad (:

    Also it seems that [invert] pick by UID does... the same as without inversion

    Test capx

  • Ashley

    There's a nice little trick

    + Foreach Family1:
   + SmallShip pick by UID Family.UID
      -> Fire Small bullet
   + LargeShip pick by UID Family.UID
      -> Fire Large bullet

    What I like to call C2's object type casting :D

  • JoyfulDreamer

    That was my first idea actually, but you have to constantly check that your next random step would still allow you to reach the goal. So you basically have to pathfind for each step.

    Unless you decide to just allo the snake to bit its tail.

    But than how much iteration until you'll really reach the goal?...

    I found that using a maze algo, it creates interesting looking random path and that you always end up with something valid.

  • Excal

    You have a mix of face palm error, object/project settings error and some arithmetical errors

    The face palm error is the fact that the GridTiles layer isn't transparent.

    So you don't see what is created on Layer 0.

    The object settings error is that you don't have the same Cell Size value in your finder in your ObjectDump and in your Gameplay Layouts. It does not necessarily cause the bug, but well... better safe than sorry (:

    The project setting error is that you have a layout width which is not a multiple of 64, so it doesn't look good

    The arithmetical ones are where you position your end point, and is a bit bound to the layout width error and some wrong calculation

    You try to place the end sprite at floor(WIDTH/cellSize)*cellSize which in fact put it out of the layout. The proper formula would be (floor(WIDTH/cellSize)-1)*cellSize

    Also since the origin is at the center of the sprite, you have to offset it to half cellSize.

    So the proper formula would be:

    X = (floor(WIDTH/cellSize) - 0.5) * cellSize

    Y = (floor(WIDTH/cellSize) - 0.5) * cellSize

    Oh and also I think you were generating the maze constantly... soooo

    Excal-RandomPath.capx

  • thehen

    Neat!

    Hmmm are you talking about that one? http://www.scirra.com/forum/plugin-polygon-update-20130423_topic62075_post381179.html#381179

    If you do, I did mentionned in this post that there were a scary error message when you start the preview, but it works anyway.

    The scary message comes from the fact that on start, since your polygon object is empty, it has no collision polygon. And Ash throw an assertion error for that. Because it seems, the physics behavior requires to be initialized with a valid collision polygon when the game start.

    Anyway, as scary as the message looks, assertion are disabled on export, and it doesn't look like it makes the physics behavior bugs.

    Sooooo...

  • You just have to project it back from canvas to the UI layer.

    crossLayerProjection.capx