faulknermano's Forum Posts

  • I've looked into the capx briefly and from what I could make out, the units are firing because they have LOS on the enemy (or vice-versa the friendly) even though that's not the their _current_ target.

    I've screen cap'd a modification

    What I did was:

    -get rid of the Foreach in the Tank1Turret (I was wondering if this was necessary?)

    -I picked Enemy1Base by querying the Tank1Turret.Turret,TargetUID.

    -Then query if Tank1Turret has LOS on that particular TargetUID.

    I test it and seemed to work. capx

    (Note that I only modified the friendly turrets, not the enemy.

  • The width and height are representations of x and y as they are depicted as table data, not as a visual representation.

    Imho, 'width' would have been clearer if they were something like 'size_x', or 'len_x'.

  • I get this all the time. If you are using only one layout, I would suggest focusing (ie clicking) on the layout window first before hitting F5. Usually, when this is done, every F5 press will result in a preview even though you've been focused on the event sheet.

    Also note that there are 2 other ways of running a preview. If you go the Projects Bar, you will see the top most folder: RMB and choose Run project (or alternatively Debug project).

    Lastly, in the Ribbon on the main GUI panel, there is a Home tab > Run layout button there as well.

  • The lack of better sprite support in C2 was one of the roadblocks that made me stop using it, despite liking everything else (the lack of a scene graph with true hierarchies, essential for complex projects, was the other factor... but that's off topic).

    To me, the main problems with sprites in Construct are:

    - Reimporting updated sprites is really essential, not just a bonus feature. A way to re-import the frames without losing all the work put into colliders, animations, etc, would be great.

    - Defining the animations by loading all frames, then deleting the ones you don't want is super cumbersome from a UI design perspective. What if you delete unused frames for the first animation, then create a second? Import it all again and delete the ones you don't want again? What if you have a sprite with dozens of actions? You should be able to import the frames only once.

    Bottom line is, you should be able to decouple a sprite from its bitmaps (animations, in this case, would be essentially lists of frame numbers plus attributes like loop, frame rate, etc.) , and simply load any spritesheet you want "into" a sprite.

    Cheers.

    This would mean animations are globally accessible to the project and not tied to sprites; sprites simply inherit them.

    ...

    A workaround which might be possible and would be very useful is a runtime action on sprites to inherit animations from another sprite type and add it to its own animation list.

    These issues reflect my own concerns. I wrote an external 'C2 sprite manager' to mass apply settings onto the caproj in an effort to bypass the UI limitation of not being able to change settings on multiple selections/animation.

    More recently I'm developing a workflow by using (and modifying) Rex's AnimationLoader plugin in order to dynamically load sprites and collision data at runtime. I might actually fuse those two functionalities together in the near future.

    The hack/trick I've been using for these two workflows is the use of a simple text files alongside the images to define animation data, and in the latter case, collision data, which is created in Photoshop by using paths, and written out by a .jsx which I wrote, too.

    The only snag here is that the frame length per animation must be pre-defined as it cannot grow/contract during runtime.

    [quote:3q9qiqmq]

    Decoupling a sprite from its frames is very useful. It makes the program a bit less beginner friendly unfortunately, which I don't think Ashley wants.

    Perhaps. What do I know of making user-friendly software? For over 5 years, I wrote this plugin once for LW to manage render passes, but the best I could do was get LW users scratching their heads.

    However, I do believe that if the guts of the application is flexible and open enough, the gui/skin/front-end can be simple enough for anyone, yet accessible enough for anyone who wants to get deeper. This is also why I feel rather disappointed at the lack (of news) of an Editor SDK in C3. It would have made all the difference for me, and given the kind of 3rd-party development I see going on around here, it would have made a lot of difference to all users. Perhaps it may still be around the corner. Who knows?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Adventure Creator for Unity, and those kinds of things, are toolkits. As such, they usually involve both run-time and editor scripts. Run-time scripts can be found in C2, but editor scripts, a crucial part of any toolkit, are not available in C2. So what you'll find, if you find anything at all, are C2 templates to give you a framework for creating things. In your case, you might want to look for adventure game templates. However, because they're not toolkits, and unless they're quite elaborate, you might come upon a dead-end, where the template doesn't do everything you'd hope it would. You would need to add things of your own.

    If C3 had an editor SDK, it could potentially open the door to a lot of different things, including tools such as Adventure Creator, among other things.

    You could potentially ask someone to develop something bespoke for you: there is a classified section in the forums.

    I'm creating an adventure game, too, but in isometric style. I started doing this game in standard adventure game format but for many reasons I moved into isometric viewpoint. The beauty about doing things in C2 is the fact that despite its advertised ease, programmatic control can be quite granular. That's why I like it; it's a good balance between ease and control, but it won't give you an adventure game framework.. not by a long shot: you'd have to make it yourself.

  • digitalsoapbox

    I see the issue. The ObjectRefGID is the raw value, but in order to extract the frame ID, the plugin also needs the 'firstgid' parameter from the Tileset because the frame number is relative to the tileset being used. IE: frameNumber=TilesetFirstGID-ObjectRefGID.

    As the plugin currently stands I think rexrainbow might need to add the retrieval of the Tileset's 'firstgid' parameter in order to extrapolate the frame number. Sorry for getting your hopes up, but hopefully, Rex will pipe up.

    In the meantime, Bjorn, the Tiled developer (am I right in assuming you are using Tiled), doesn't recommend using Tile IDs to reference tiles in a tileset because they are 'volatile'. I had to agree with him because I found out in my situation, I could not reset certain tiles to start at 0 within Tiled. For example, in one of my tilesets, the first tile's id is 3, and there are some the skipped a number. And so referencing them in C2 was yielding incorrect frames even though the tile ordering was identical.

    The only practical solution for me was to apply a custom property to each individual tile assigning them a frame number. I think this a much better solution as it is predictable. Also, it is also possible to parse the TMX externally that will procedurally make the correspondence between the TMX tileset and the animation frames in C2.

    Lastly, I have modified Rex's code specifically for this 'Image Object Tile ID' requirement, but I have not requested Rex to 'pull' my modifications as I think it's better for Rex to maintain his plugins. If Rex allows me to post modifications to his code then I'll do that here.

    But again, I personally have abandoned the idea of using Tile IDs for frame numbers mainly because they're not dependable.

  • digitalsoapbox

    Rex PM'd me about a TMX Importer V2 update but it seems he had forgotten to update this thread.

    Here's a direct quote from rexrainbow

    Please update tmx related plugins.

    Add new expression:ObjectRefGID to get reference gid of an object, and extend expression:TilesetName( gid ) to get tileset name of a specific tile (gid).

    ex : TMXImporterV2.TilesetName( TMXImporterV2.ObjectRefGID )

    Hereis a sample capx.

    The 'gid' is what you're looking for. It's basically the 'frame number' of the Object, as it were.

    I also believe that Rex updated only the one in his main site, not the Github one, last I checked.

  • But you dont refine the picklist. So to which of all the picked sprites should Sprite.X refer to ?

    ...

    The browser log has the same problem. All sprites are picked, which sprite should it log ?

    Hi —, thanks for replying and clearing this up.

    In regards to the SOL/picklist, my expected behaviour was that the trigger is sent to all sprites, but each sprite, on their own, will process the trigger individually. So, for triggers like Event # 6, I instinctively read that the Sprite object is the one that was triggered, and thus that is the picked Sprite for that trigger.

    [quote:1e25l9ve]

    The for each in event 2 and 4 are not needed. The Sprites are not picked. That makes them un-referenced, and that is the same as a 'pick all'. They get no personal values, so you can set the instance variable 'trigger' for all in one action, without the 'for each' loop.

    Yes, now that I know that the trigger is not contextualised for each instance that makes sense. However, the main reason for looping through instances was to (hopefully) trigger individual Sprites.

    So what I'm learning from this is: 'Trigger once while true' doesn't pick the Sprites based on the moment of trigger (ie pick each Sprite which had been triggered indvidually). It's basically a 'pick all with a given set variable', so that I have to explicitly to a pick condition inside the trigger.

    Thanks for very much for your time to open the scene up and examine. Much appreciated.

    (Note that I had experimented a bit more with other solutions, and I did come to use Rex's FSM to use as an individualised trigger. Rex's FSM is actually the kind of behaviour that I expected, because while you can send triggers to all instances, each instance processes the trigger on its own; it's automatically in its own context. But I think I will revise my events to use C2's trigger method as it saves me from doubling up on events.)

  • Problem Description

    When trying to send a trigger to using variable change and 'Trigger once while true' method, I am unable to use actions to set variables, or use other plugins (eg Browser) to do other things within that trigger.

    Attach a Capx

    https://www.dropbox.com/s/06yqofly0lm9z ... .capx?dl=0

    Description of Capx

    The capx creates 3 circle Sprites (2 frames of animation). It creates a 'name' instance variable, and they are named 'a', 'b', and 'c'.

    It also creates 2 box sprites which are 'touch triggers'. The left box sprite is trigger1, and the right is trigger2.

    A Browser object is also used to debug, and this makes the bug more obvious.

    These two triggers try to do the same thing: it switches the sprite's animation to frame 1. However, trigger1 won't work because of the method it tries to use, while trigger2 works, but is only done so for demonstration purposes, as it is not possible to achieve a certain behaviour using only the methods used in trigger2.

    Steps to Reproduce Bug

    • Load the capx
    • Open up a Console to see the messages from the Browser object.
    • Click on the right green box (trigger2) first. Notice the change of the two blue circles to frame 1. This trigger also tries to display the name of the sprite via Browser console. However, the console only displays the first Sprite's name.
    • Restart the capx.
    • This time click on the left blue box (trigger1). Nothing happens. What trigger1 is trying to do is use System actions to and expressions to query the Sprite.X, and set the animation frame based on it. But this isn't happening.

    Observed Result

    System actions and commands, including the Browser object (and based on my main project, other plugins as well), don't seem to be evaluated correctly in the 'trigger context'. As the Browser console seems to point out, the evaluation of triggers seem to occur in a different timeframe that not all sprites are being registered as being triggered.

    Expected Result

    I expect that each sprite evaluates system expressions (even calls to functions) in the same way as normal triggers do.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)

    Operating System and Service Pack

    Windows 7 Pro SP1

    Construct 2 Version ID

    Release 241

  • jomo and rexrainbow, thanks for this. Expressing it as a curve makes perfect sense; never thought of that.

    Re C2SpriteManager: thanks for you words. It works ok, though I sorted out a critical bug over the weekend.

  • What Prominent is trying to explain is how to use a single image as a basis from which C3 is to derive multiple frames. To work with a single spritesheet (image) is the very point. Placing it in the animation (film strip) window nullifies the main idea because the film strip shows discrete frames, and whole point is to have a full spritesheet to work from.

    In my view, in this system that prominent is suggesting, the film strip could be the means of viewing the animation frames as defined by the 'spritesheet editor'. But yes, the window to edit the spritesheet may look different (ie different spritesheet-centric functions) for the user to immediately see the context of the edit.

    I think each Animation could have a property that controls which image and context its sourcing from: single frames, spritesheet. If single frames, then a list of image frames is populated, and we are working in the same way we do in C2.

    If we use the spritesheet as a source, then that's a different data, where we are sourcing a 'spritesheet object', whereby a single image is used, and then bounding boxes defined which extract the pixel information, then generates a list of images based on the extraction.

  • The C2 JS SDK will only deal with run-time stuff. Editor is closed off. However, as far as C2 is concerned, one avenue is through writing back to the caproj file (not capx) via an external application.

    For example, I wrote a Python app that manages Sprite object data (eg duration, hotspot/imagepoints, animation settings, etc) by reading and writing the xml caproj. But doesn't mean you do everything. In my limited experience, the first stumbling block is the 'sid' parameter, which I believe is used to unique identify your object in scene. This makes creation of objects in the caproj not generally recommended, but perhaps it's safe to back-reference it.

    I've been happily hacking file formats -- some of which undocumented -- for 15 years now, and it's pretty fun, but only if it works.

  • Creating for tutorial videos for so many plugins would be quite a challenge!

    FWIW, I am documenting, for my own reference, development of an isometric game, which extensively uses Rex's plugins insofar as the use of Board-related stuff (eg SLG, InstanceGroup), and TMX reading is concerned.

    jomo, one of the most opaque plugins I've played around was rex_ljpotential. I don't have a particular use for it right now, but I'll be appreciative of some definitive explanations of how a, b, n, and m relate to each other in practical terms.

  • I see a lot of posts like these, and I'm left to wonder: is the issue the subscription model - which I know a lot of people aren't fans of - or the value proposition of C3 with a subscription model?

    There were those who pointed out that the nature of subscription/rental will prevent access to your work when the rent expires (ie stop paying). I have 2 different povs on this.

    For example, I use Adobe CC for professional work (visual effects). But my work is essentially my studio's product for client's product. If any work is being held hostage by the rental scheme, it's not 'mine', as it were, but the studios and the clients. If they want to pay the ransom fee to alter the product after its first delivery, they're free to do it. It's the cost of doing business with Adobe. And the main thing is, at this point, it's not about the technicalities of file formats or back-compatibility; it's all about flow of money to the studio and to Adobe. As long as the studio has that flow, they're good. You can add to this that there's a certain volatility in working with 'media' projects, so that projects are done at a speed generally faster than development (in games, or other code projects).

    The implications of a rental model involve _effective_ ownership: I can always claim IP but without a way to use it, that's a farce. And to me, the technicalities are just as important, if not more, than the monetary implications associated with subscription/rental. One forum poster asked: what's to stop rental prices from going up once subscribed? Then consider the fact that your choices are lop-sided: don't pay, and never be able to work on your project again, or pay up. That no-choice is the crux of my issue: it's not the price, per se, but it's that fact you don't have a choice once you start subscribing.

    There are many ways to approach licensing and making money with a product as good as C2. I agree that a one-time payment was too generous for the kind of updates they were rolling out. I myself did the same thing for a LW plugin I wrote, and got major burns, so I get it.

    But, why stop at one licencing method? I find a maintenance plan a more friendly way especially since C2's tradition has been regular updates. For example: Pay a yearly maintenance, get updates. If you stop paying, you don't get upgrades but can use the last version you paid for. If you want to take up the maintenance again, it can be taken up again for the full price or some other price you deem fair.

  • > I read the blog this afternoon about the "sprite and animations" editor in C3 and got very excited about it. We cannot deny the fact that there are many improvements over C2.

    > ...

    >

    The "new" animation editor is nice and all, but I would never use a built-in graphics editor that is as limited as the one on show. As a matter of fact, I have never used the built-in graphics editor of Construct before, except for things like collision shapes, origins and animation frames.

    I'd like to add that manipulating C2-related data is my primary reason for the using the editor; indeed, things like, collision shapes, and image points, things that can't be done otherwise (except through caproj editing). Unfortunately, there are workflow issues with C2 in regards to applying functions over a number of frames. For example, I'd like to 'Guess collision shape' over the whole animation sequence. Or perhaps I'd like to set a particular image point based on a unique pixel value based of another sequence, or perhaps through an ascii file. I don't believe there is a way to do this currently.

    But from my pov, if C3 doesn't do specific things out-of-the-box, it's really ok with me. But my big question, the one I've been anticipating since I was aware of C3 is this 'editor SDK'. So far, the only hint to an 'SDK' (or 'SDK' like idea) is being able to change CSS to theme C3. But my expectation of an 'editor SDK' is certainly much higher, and will allow hooks into editor functions. If this were the case, as I hope it would be, then it opens up the editor to so much potential functionality that the current featured capabilities being written about will pale in comparison.