TrickyWidget's Forum Posts

  • I'm writing a behavior that needs to adjust its behavior for different plugins. So I need to be able to check which plugin the behavior is attached to. But type.plugin doesn't seem to have any properties that could be used to identify it. I suspect I'm missing something obvious, but I've been all through the docs and can't find anything.

    Does anyone know how to get the plugin id or otherwise identify it?

    Thanks.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • TrickyWidget : It's quite elegant already! I'll wait to see how it evolves, but it will eventually be a nice supplementary tool to c2's arsenal.

    Thank you! It's nice to hear that it's shaping up to be a useful contribution.

  • Yeah, that's it!

    I really like Configure and Configure+ solution.

    Keep it going!

    Just one more thing, If your plugin is called Twixt it should have same name in C2 (for now it shows up as Tween)

    Thanks! Glad I could help.

    The "Tween" name inside C2 is actually on purpose. I wanted a name that was consistent with the rest of the design experience. Texts are called Text and sprites are called Sprite, so similarly I thought tweens should be called Tween.

  • Just posted 0.3, which adds a condition to check the state of the tween.

  • It's quite nice, I like it.

    Easy and simple.

    One thing - could you add an action to set "two values" for target. For something like

    Target X - mouse.X

    Target Y - mouse.Y

    Besides that it's nice simple plugin.

    Thanks!

    I just overhauled the configuration actions. I realized that trying to set the tween properties individually would break things most of the time (oops), so I moved everything into two actions. There's "Configure", which is just like the editor properties. Then there's "Configure+" which allows one to set everything individually and from expressions. I think that's what you were looking for.

    I also re-did the expressions to make them more meaningful.

    Thanks for the feedback!

  • The forum doesn't allow attachments with the c2addon extension.

  • Hey, folks. Here's my first go at the SDK. I needed a tween that could scale sprite fonts, and decided I wanted to take the code a different direction than LiteTween, so I wrote my own.

    Twixt 0.53

    [attachment=0:1fb7oug5][/attachment:1fb7oug5](This is packaged as a c2addon, but this forum doesn't like that extension. Just rename it to Twixt_0.53.c2addon for drag-and-drop install.)

    Twixt is optimized for efficient, linear tweens. Easing is not supported. It can tween position, size, scale, angle, opacity, and Sprite Font scale.

    Note that tweening Texts is a bad idea! WebGL handles non-bitmap fonts in a very inefficient manner. If you need to tween text, make sure it's a Sprite Font. I recommend using Sprite Font Generator and SpriteFont+ to make them as painless as possible.

    Also note that this is a beta preview. Anything may be broken or become broken at any time. Use with caution! (The 1.0 release should be forthcoming in the not-too-distant future.)

    If you find any bugs or have any suggestions, just let me know!

    Thanks.

    Docs

    Most of it should be self-explanatory, but here are some details.

    Scale

    When scaling a sprite, the internal scale system is used as if the SetScale action had been called. When scaling other objects, the basic width and height properties are used and their start values are used as scale factor 1.

    Expressions

    StartA - Start value for position X, size width, scale factor, angle degrees, opacity percent, or font scale.

    StartB - Start value for position Y or size height. Ignored for scale, angle, opacity, and font.

    EndA - End value, as above.

    EndB - End value, as above.

    State

    Start - Tween is stopped at the start position.

    Forward - Tween is running from the start to the end.

    Paused - Tween is paused between the start and end positions.

    Reverse - Tween is running from the end to the start.

    End - Tween is stopped at the end position.

    Changelog

    08/09/2014 - 0.53 - Fixed tweening only Y or height with unchanged X or width

    08/08/2014 - 0.52 - Fixed scale of flipped/mirrored sprites

    08/08/2014 - 0.51 - Fixed scale reverse end detection

    08/08/2014 - 0.5 - Changed debug tweened and state values to their text equivalents (instead of their constant index)

    08/07/2014 - 0.4 - Added "scale" as a property to tween

    08/01/2014 - 0.3 - Added a condition to check the tween state

    07/31/2014 - 0.2 - Revamped configuration actions and expressions

    07/30/2014 - 0.1 - Initial release

  • It is possible to call an action from a behavior. Even call an action/expression/condition from other plugin/behavior.

    Thank you for the response! It was actually that very code that I examined from a previous post that lead me to the code I had.

    It seems my problem was that I was trying to affect the instance in behinstProto.onCreate. I have no idea why that doesn't work, but when I move it down into behinstProto.tick it's now behaving as expected.

    Thanks again!

  • OK, in the docs I found this:

    [quote:1u90lmv3]inst.inst

    In behavior instances only: this is the reference to the object instance your behavior should modify.

    Which sounds like it would apply to what I'm trying to do. So I amend my code to:

    cr.plugins_.Spritefont2.prototype.acts.SetScale.call(this.inst.inst, 0.5);[/code:1u90lmv3]
    But that gives me:
    
    [quote:1u90lmv3]Uncaught TypeError: Cannot read property 'characterScale' of undefined
    
    Still searching...
  • I'm trying to write a behavior that will change the character scale of a sprite font. However, I'm having trouble getting it to work. After digging around in the forum, I came up with this:

    cr.plugins_.Spritefont2.prototype.acts.SetScale.call(this.inst, 0.5);[/code:p5orxfd2]
    That at least doesn't throw any errors, but it also doesn't actually change the scale.
    
    Does anyone know what I'm doing wrong?
    
    Thanks.
  • Not sure I understand. You want to be able to change properties (Size and Position) from a text box?

    Like this:

    [attachment=0:15qx5uax][/attachment:15qx5uax]

    I'm wondering if there's a way to make my behavior's input fancy.

  • Is there a way to do compound properties, like Size and Position are done under Common properties? That is to say, two integer properties that can be set either individually (when expanded) or together in a text?

    Thanks.

  • OK, after talking with the powers that be, it turns out that C2 is smart enough to automatically detect redundant textures and only load them once.

  • Hello again, lunarray . <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    I'm still using LiteTween to great success. Thank you!

    However, I've encountered a bug. When attempting to tween the scale on a sprite font, it gives this error:

    [quote:3s3esi5v]Javascript error!

    TypeError: this.inst.curFrame is undefined

    http://192.168.1.2:50001/lunarray_LiteTween_behavior.js, line 321 (col undefined)

    I'm guessing this might be because scale on sprite fonts is applied only to the text and is independent of the overall size of the instance. So there are two different scales involved.

    For my own use, having one tween value applied to both the text scale and the instance scale would be fine. So far I always want to change both at the same time and at the same scale. However, it would be more robust to have the two different scales available to tween independently. Or if you wanted to go all the way, you could have three scale options for sprite fonts; one for the text, one for the instance, and one that does both. However you see fit. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    Thanks again!

    Example attached.

  • You could link them manually, using instance UID, and abandon containers. Although the manageability would suffer a bit, you wouldn't have to worry about that duplicate texture problem.

    Thanks for the tip! I thought about trying that, but in this case manageability would suffer quite a lot. There's a whole lot of manipulation of these cards, and the container aspect is used heavily throughout them. The total number of sprites is actually pretty low, so I think I'd rather take a hit on redundant textures than lose container functionality.