Hi Prominent, here are some observations. You are using 2x 'On start layout' triggers. The first one inits the arrays, and the second one picks. The problem I see with this, and this is a recurring issue (of which I always have to find workarounds), is that during the creation of objects, the objects themselves are not registered quickly enough in memory to be referenced.

This happens in many situations, and yours seems to be one of them. If you have a look at this modified capx I've removed the second trigger, and combined the pick condition after the creation. When you preview, you'll see that the 'bug' text is not shown.

shaundraws, quite an interesting problem. I think because you are using a System condition (for every x seconds) it may not take a 'divide by zero' kindly. Perhaps there is a internal state issue causing the condition to break down once it has reached that.

My suggestion is to use your own timer. I've modified a bit of the capx as an example of how I might approach it.

capx

(Using your own math for randomising using the speedmultiplier variable, I've put the value into a variable called 'interval' which is the time that the ongoing timer needs to reach before spawning. The timer simply increments at delta-time per tick, and then resetting back to 0 when interval is reached)

Would be helpful if you could provide a sample capx to demonstrate the problem. This whole trigger business can be quite confusing.

I recommend:

Boids

-or-

LJ Potential

.. for swarming behaviour. Although you need to understand a bit of C2 to implement practically.

I whipped up a sample capx. To damage your unit, click over the blue box. The bars represent Shields, Armour, and Hull, respectively.

capx

I've had a bit of time so I was able to experiment with some stuff relating to this.

Here's a reference capx

Here are some suggestions about how to approach it using the capx as a reference.

Sequencing audio was done using the Audio::Schedule next play expression. The example sounds I've used were very short sounds, but in your case, it is speech. So the important thing is to know how long each speech audio file is so you can schedule it appropriately. In the capx you will see "Schedule next play for Audio.CurrentTime+1". The +1 is 1 second. You should place as many seconds as it will need to play the audio file that you will play after that schedule action.

Just an overview of how to organise the project's logic. It's a bit difficult to explain why something is organised they way it is. But the way I thought best to solve the problem is to figure out the basic functionality that you want from the project.

1.) you want to be able to sequence sounds.

2.) you want to be able to stop _only_ those sequence of sounds on a key press.

3.) you want to play sounds before you switch scenes.

4.) you want to play a background sound that doesn't change.

For #1 you should be able to work out the technique to sequence the sounds. In the capx you'll see under the group "AUDIO FUNCTIONS" that that is how I approached it.

For #2 you should be able to identify those sounds that are 'stoppable' by a user keypress. I've done this by using unique tags, and setting a integer variable to keep track of how many sounds are actually playing. For example, in StartFGAudio, I have 4x sounds playing, and tagged them p1, p2, p3, p4. Then I set a global variable ndxs to 4. This notes that there are 4x sounds playing.

When I decide to stop the sounds, I use a for loop, concatenating 'p'&ndxs, which gives me p1, p2, p3, p4, and I use those strings to stop the audio.

For #3 you want the same thing as #2, but you need a trigger to let you know when a certain audio has ended. In the function StartTransitionAudio, 2x audio is played (this is to simulate your 'footstep' audio). I play this as sequence, with the last audio having a unique tag called "transition_last". This is the tag that I'm going to be looking for in order to transition to the next scene.

In the group AUDIO TRIGGERS, you will see the trigger there. And again, this only happens after the sound has ended. If you tried to do this in the StartAudioTransition function, the scene would have changed before the audio has stopped playing. If you like that behaviour then you can place the GoToScene function there.

For #4, the background sound is played with its own unique tag. As long as you don't stop the audio with this tag, it will keep playing.

Now, lastly, the overall organisation is putting things into their proper context, and I think that's why you had thought of using FSM. The basic idea that you were going for was to put something to a state, like a scene or layout, and have all the things related to that scene appear. That's fine, but the problem is that you still need to control everything else. So the FSM is not really necessary, but a clear indicator of what your state or scene is important.

For me, I thought using a 'scene' global variable to determine my current scene. When I change this scene variable to something else, all the other functions that need context will change as needed. For example, when I call fn.Call("StartFGAudio",scene), the function will know what sound to play, because I told it to play the 'machine gun' audio when the current scene is "secondscene".

But then I prefer to make a more general function called fn.Call("GoToScene",scene), because I can call fn.Call("StartFGAudio",scene) as well as load any other layout that's related to that scene.

Anyway, I hope the capx explains it better than I have written.

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?

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.