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.

I have considered adding an ingame level editor to my game. I wonder if it is possible for you to create TMX-exporter to json files. Or maybe it is not good idea and too complicated?

helena, have you considered using Rex's JSON builder (http://c2rexplugins.weebly.com/rex_json_buider.html) in order to construct your JSON strings and then write them back via the AJAX object?

Of course, it is a bit of work, but much more convenient than doing it manually.

If you want to export TMX, you could also try rex_xmlwriter (http://c2rexplugins.weebly.com/rex_xmlwriter.html), but like before, you'd still need to read up on TMX format. But it is quite doable, I think.

Hi randomly

rexrainbow might come in correct me on this, but I've compared your capx with his sample 'pick neighbors.capx' and this is what I found.

-picking neighbours is only possible with 'tiles', ie placed on LZ=0. I tested this by modifying the 'pick neighbors.capx' and populated the LZ=1 (ie as 'chess'; in Rex's Board terminology, anything LZ>0 is Chess and LZ=0 are Tiles), the Chess objects were _not_ picked. So this is consistent with your own capx.

-This makes the labelling 'pick neighbor chess' a bit misleading. It seems to actually mean 'pick neighbor tiles'

-Because of this you are unable to pick any neighbouring chess.

My suggestion is:

-Create the underlying Tiles array.

-Populate your Chess pieces normally.

-On touch with a Chess, query the tile underneath the chess

-Pick the neighbors of the tile

-Pick the chess pieces on top of the those picked tiles

-Generate your predict_kick sprite on those chess pieces

See this modified capx:

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