ScottA's Forum Posts

  • 8 posts

  • I'm really impressed with this plugin. It's basically everything I could have hoped for, I think. I'll be sure to give feedback if I run across anything.

  • Problem Description

    When I create an object, I cannot select or interact with instances of that object created in the same event.

    Attach a Capx

    https://dl.dropboxusercontent.com/u/770 ... p_bug.capx

    Description of Capx

    Demonstrates that objects spawned in the same top-level event are inaccessible via selection. If it worked as expected, three yellow "spawnee" objects would be left, right, and below a central sprite. There are log messages that help demonstrate some of the weirdness. In particular, note that there's something weird going on with the count: the spawnees have a count of 0 at the top of a loop, but increments as I would expect within the loop.

    Steps to Reproduce Bug

    • Create an object in one scope within a top-level event
    • Try to interact with that object in a sibling scope.

    Observed Result

    No interactions with the object seem possible.

    Expected Result

    I expect to be able to select and interact with other objects that have been spawned in the same top-level event. I'm a little baffled that I apparently can't.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)
    • Internet Explorer: (?)

    Operating System and Service Pack

    Windows 7 SP1

    Construct 2 Version ID

    r163

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Made a minor update to this plugin

    Changes in version 1.0.5

    • Error messages now include the name of the namespace.
    • Return value error messages include the value the action was trying to return

    The demo has been updated to demonstrate the new error messages (in preview mode, of course)

  • Ok, looking closer at this, the exact behavior is this: if you anchor the right/bottom edge of an object, its right/bottom edge will maintain a constant distance in pixels from the edge of the layout. Thinking about it, this is consistent with how the top and left edge anchoring works, and therefore expected behavior. I'm not entirely sure what the use case is, but that's probably personal myopia.

    I don't think that my original expectation (that right/bottom edge anchoring maintain the object's proportional dimensions) was unreasonable. However, now that I reflect on it, I probably would have done Dumb Things with such a feature, so perhaps it's for the best.

    Regardless, I don't particularly consider this a bug anymore. It might be the opportunity for a new feature (percentage based width/height toggles on the anchor behavior?), but definitely not a bug.

  • Example:

    dl.dropboxusercontent.com/u/7709131/anchor_crop_bug.capx

    Steps to reproduce:

    1. Set a project's fullscreen mode to crop

    2. Create an object and give it the Anchor behavior

    3. In the object's Anchor options, set Right Edge to Window Right and Bottom Edge to Window Bottom.

    4. Run the project

    Expected result:

    That the right and bottom edges would maintain their relative positions vis-?-vis the window as it appears in the editor.

    Observed result:

    The effected objects are grossly out of proportion. If you don't see it immediately, try changing your window size.

    Impact:

    This makes creating certain UI elements very tricky in crop mode

    Known Browsers affected:

    Chrome, and Firefox

    Operating system & service pack:

    Win7 SP1

    Construct 2 version:

    158.2

    Graphics up to date?

    Yes, and also probably not relevant

  • <font color=red><font size="5">UPDATE 2 - Problem resolved!</font></font>

    Well, it turns out that the bug I thought I had was nothing but a red herring. I'm a bit embarrassed to say that I missed converting a function call to a namespace call in some code I was converting, and erroneously assumed that the plugin was at fault.

    I now am quite sure that the plugin is working as intended!

    I've nonetheless updated the plugin download link to an new version of the plugin. The major change of note is that individual namespace objects now maintain their own function stacks. This will probably prevent weird collisions with nested namespace calls.

    I've also updated the demo to be much more extensive and easier to read. Be sure to clear your browser cache if you've looked at it before.

  • <font color=red><font size="4">IMPORTANT UPDATE (Edit: Problem resolved! See below)</font></font>

    After more testing, it appears that my plugin breaks when used with nested function calls. I'll update the original post accordingly.

    I guess I now know why there was such a song and dance with the func stack.

    Edit: Well, apparently I can't edit the OP because I don't have enough rep to post the hyperlinks that are already there?

  • Namespaces

    Namespaces are virtually identical to the core Function plugin. The only difference is that you can create more than one Namespace object. If you're using a lot of functions, you can break them up into multiple Namespace objects, helping organize your code and prevent name collisions.

    You add, call, and inspect Namespace objects exactly like you would the vanilla Function object.

    Namespaces are independent from one another ? calling a function from namespace A should never trigger a function in namespace B.

    A Very Simple Demo

    Downloads

    namespace.c2addon

    namespace_demo.capx

    Some notes:

    • This plugin is literally the core Function plugin with the singleton tag taken out and the some strings judiciously edited. All credit goes to the fine folk who developed the function plugin for creating such a robust piece of code.
    • Unlike the Function plugin, namespaces aren't singletons. That means that it's technically possible to create and destroy namespace objects, among other things. I wouldn't particularly advise using those features, but, hey, I'm not your boss. The practical upshot is that the Namespace event windows are a bit more cluttered than the vanilla Function object.
  • 8 posts