Daiz's Forum Posts

  • Changes are though that any widescreen game in it would be 1280x720, thus you'd have to downscale them if you do eg. 800x600 or 640x480 video. It'd be a better idea to upscale the 4:3 games to 960x720 with black bars to go with the 1280x720 clips.

  • I also vote for the "exes submitted to an editor" model. It'll ensure much more consistent recording and video quality.

    I also volunteer myself as an editor, since I have lots of experience in the fields of video capturing, video editing, video processing and video compression.

    I also suggest that when people submit their exes/caps they can say what they'd like to be recorded in it if it's not obvious what the thing is demonstrating.

  • newt's solution is probably the best idea. I thought I'd made an Angle Lerp expression, but I wrote it for something else. Might be useful to add to the next build?

    You could add a "Rotate towards angle" function for sprites while you're at it. Right now you have to use a workaround like "Rotate towards position: Sprite.X+Cos(TargetAngle)*10, Sprite.y+Sin(TargetAngle)*10", which isn't really all that intuitive.

  • I sincerely hope your game won't be as terribly boring as that one Nanoha STG out there. I have bad memories from playing it.

  • I guess I'm sorta using a form of FSM for my character animation... I have a single variable called animstate, and then I just run events like "If animation != animstate -> Change animation to animstate" and then I have events like "When animation raiseweapon finished -> set animstate to weaponraised".

    It does make handling animations in the events quite easy.

  • That's a good idea. Reported it to Google & Mozilla.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Figures, anything with "official" in the name that very clearly isn't official is bound to be spyware. I remember seeing that topic earlier but didn't realize this was the same. Good to know anyway, but I think something should be done to make that thing disappear from the web if possible... Though I don't think Conduit whatever will stop with their shady business with just an e-mail, but hey, it'd say it's worth a try.

  • officialscirra.ourtoolbar.com (edit: be careful if you visit - this is malware)

    Ran into this while surfing on the net. Looks like some sort of scam toolbar or something...

  • *Line breaks. Might already exist?

    "Line one" & NewLine & "Line Two"

    In other words, it's already built-in as a system expression in Construct.

  • [quote:3pg0y3m5]Counters can be made with anything by adding and subtracting private variables. It is totally not necessary to have a separate counter object.

    There's one benefit TGF/MMF-style counter object would have compared to the other alternatives though, you could draw the numbers for it yourself, meaning you could have custom graphic -counters made with ease.

    With Construct, to get custom graphic counters, you'd need to use the SpriteFont object, which has its own problems... I guess the best solution would be just to get a more working SpriteFont object, it'd solve this issue and offer more usability in general.

  • [quote:6pkyd7k9]

    + On collision between aSprite and bSprite
       -> Set global('aFoo') to aSprite.Value('life')
       -> Set global('bFoo') to bSprite.Value('life')[/code:6pkyd7k9]
    
    In Zetar's case the code would be like this:
    
    [code:6pkyd7k9]+ On collision between Sprite and Sprite
       -> Set global('aFoo') to Sprite.Value('life')
       -> Set global('bFoo') to Sprite.Value('life')[/code:6pkyd7k9]
    
    The hell are you supposed to specify which one is which in this scenario? I said to use a family because if your object Sprite is the only member of family Blue, you can do it like this:
    
    [code:6pkyd7k9]+ On collision between Blue and Sprite
       -> Set global('aFoo') to Blue.Value('life')
       -> Set global('bFoo') to Sprite.Value('life')[/code:6pkyd7k9]
    
    And it's very easy to to do basically anything, like comparing their values with each other, or doing specific things on the other one, like this for example:
    
    [code:6pkyd7k9]+ On collision between Blue and Sprite
    + Blue('life') < Sprite('life')
       -> Destroy Blue
    Else
       -> Destroy Sprite[/code:6pkyd7k9]
    
    Without the family trick, the code would look like this
    
    [code:6pkyd7k9]+ On collision between Sprite and Sprite
    + Sprite('life') < Sprite('life')
       -> Destroy Sprite
    Else
       -> Destroy Sprite[/code:6pkyd7k9]
    
    ...which I'm fairly sure would not work as intended.
  • Considering all the annoyances involved in colliding one instance of a sprite with another I'd suggest you include your sprite in a family and test for Family on collision with Sprite. This way you can refer easily to whichever colliding instance you want, eg. Family('Life') and Sprite('Life') will each refer to the different colliding instances.

  • I used to work with TGF/MMF/MMF2 before moving on to Construct. I say the change was pretty easy to make, though unlearning some bad click habits might take a few moments here and there.

    Also, Construct's Event sheet editor >>>>>>> MMF's spreadsheets. The code in Construct is billion times more readable and the event editor in general is great, save for few usability issues here and there (why can't I still press Enter as a shortcut for Finish?) but they're pretty minor.

  • I've had quite a lot of nicknames but back in 2004 (I think) this one IRC channel I was hanging out at had this "change your nick to something completely different for a day" and after a bit of pondering I came up with Daiz pretty much out of nowhere. Since it was short and neat I decided to stick with it ever since.

  • Well, for one, you can't change the type of a variable in an entire family from the family manager, nor the initial value. You can only add or delete a variable, which has been a source of frustration for me at least, I've had to change two variables from number to text on every member of the family separately in order to not break the code that deleting the variables would cause, and I can tell you that this is quite a frustrating and time-consuming task to do with lots of objects in the family.