Yann's Forum Posts

  • Noga your formula is overcomplicated

    First using the same angle order as c2 (0 is to the right and then you move clockwise) makes the formula way easier.

    You can sum it up as round(animationFramCount*angle/360) but as you well representated in your image you need to offset the angle a bit so the direction the sprite shows represents the center of the range of angle and not the minimum.

    So it should look like

    ceil(animationFrameCount*angle/360-0.5)

    Then to avoid negative result (for angle from 0 to 180/animationFramCount),

    you just have to offset values and modulo them

    ceil(animationFrameCount*(1+angle/360)-0.5)%animationFrameCount

  • If I remember correctly, multimedia fusion 2 has two kind of "or". An or "logical" and an or "filtered".

    Even with the experience I have with mmf2, cc and c2, I think I really understand this design choice now (well I dropped mmf2 long ago...)

    Anyway, if it's that hard to understand, it's probably not a good choice.

    So, I don't think having a logical and filtered else would be a good idea...

  • Ashley :D yeah I saw my mistake and thought about something else as a solution

    So I reposted it with some changes

  • I honestly think that "else" shouldn't mess with picking as most system expression.

    In my opinion, else is missing in c2 for only one algorithmic case: "when my previous condition is false"

    Putting the inverted condition as an else doesn't work if the action of the previous condition makes the next one true (like Ashley's toggling example)

    In short, I side with Geo in the idea of keeping the else logical only.

    Also in Ashley's case 2 things can be easily handled by just inverting condition

    +Sprite: X < 320
  -> Sprite: set opacity to 33
+Sprite: X >= 320 
  -> Sprite: set opacity to 100

    There's really no need for an else here

    If we keep telling users that "most system conditions do not pick any instances: they are either true or false." It will be the same rule applied to "else"

    The only system expression that should modify picking should be those in the "Pick instances" category and the for each loop. Because they are pretty self explanatory.

    Unless someone find a good situation where inverting picking is really that usefull and can't be handled by just inverting events... I don't think it's worth it.

    hmm let see a case were inverting a condition doesn't work

    +Sprite: X < 320
  -> set X to 400
+Sprite: X >= 320
  -> set X to 100

    Obviously all sprite will go to X = 100

    we need an else here

    +Sprite: X < 320
  -> set X to 400
+Else
  -> set X to 100

    Indeed if this else is a logical one, and there's even just one sprite at X < 320 the others won't go to X=100 as the else won't be executed

    One of the work around could be to loop through objects

    +Foreach sprite:
  +Sprite: X < 320
    -> set X to 400
  +Else
    -> set X to 100

    Which makes me thing that we also need to loop some other different case where we use system expression on instances, like distances or angle checks

    +Foreach sprite
  // check for sprite too far from the center of the view
  System: distance(scrollX,scrollY,Sprite.X,Sprite.Y) > 100
    -> do things

    So it's not far from it actually.

    However, if I'm not wrong about how event works, condition "inside objects" works does a kind of hidden loops.

    Like 

    +Sprite: Y > LayoutHeight
  -> Sprite:destroy

    Which leads me to this idea: maybe we could have a system else for logical purpose and an instance "inverse picking"

    Then the aformentionned problem would be reduced to

    +Sprite: X < 320
  -> set X to 400
+Sprite:invert picking
  -> set X to 100

    (of course you'd have to have a link system between two events...)

    ... This way you keep the two ideas, as well has clarity =)

    Annnnd I side with Arima on that one, didn't read his posts but we had the same ideas (:

  • if I understand correctly you have 2 components :

    • shooting direction
    • wind force

    if it's correct, I think you should do something like

    on Shot
  -> Ball apply impulse  shotStrength   at angle angle(ball.x,ball.y,directionOfShoot.x,directionOfShoot.y)

    and for the wind

    Every ticks
  -> Ball apply force windStrength at angle windAngle

    shotStrength, windStrength and windAngle are values you have to figure out.

  • what is the "directionOfShoot" object ?

    you need to put an angle, if you want to get an angle from coordinates you need two points. the "from" point and the "to" point

    then to get the angle the formula is angle(from.x,from.y,to.x,to.y)

    Here you're just putting an x and y coordinate separated by a coma, that's not something c2 understands

  • Apply Physics force 4 at Angle (Arr.angle) at image point 0

  • toward(arr.X,arr.Y)

  • set myText to replace(myText,newline,"")

    works fine

    Also in scripting language the linebreak is \n not /n

    But yeah that doesn work with c2

  • you make a physical object cross hundreds of pixels in one tick. I still wonder why it's not even worth than just that.

    I would probably save velocity and torque in variable on collision and reapply them after transfert (with maybe some some orientation changes if your portals have differents angles)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hmmm I'm divided about this idea. It sure is interesting to increase the tut volume and maybe the average quality of them. But the issue here is the judging criteria.

    The previous contests about making a game had a simple judging criteria : make a fun game within the limitation of the rules (mainly using C2, a theme, a required feature, etc)

    For a tutorial contest, the criteria would be : make an interesting tutorial?

    In my opinion, tutorials has two quality components :

    • extrinsic: easy to follow (good flow), easy to understand (quality of explanation).
    • intrinsic: the subject of the tutorial

    We can make tutorials about pretty much anything in C2. But all subject aren't equally interesting.

    Then maybe, if you were to launch a tutorial contest, there should be some categories like "c2 concepts" "making a type of game (platformer, rpg, shooter)" "math and programming concepts"

    But then you'd have to multiply prizes... etc

    Well just an opinion :D

  • Also up is lower than down on c2 coordinate system.

    Y = 200 is higher than Y = 400 ... Just to say

  • A.count = 0

  • check my old falling leaves capx.

    fallingLeaves.capx