faulknermano's Forum Posts

  • In addition to R0J0hound's explanation, it personally helps me to visualise it like a 3-dimensional cube. Even though Depth is not 'used', it still needs a size to be there in order to store Height and Width. A single 'slot' in the array requires a 'location' in the cube, which must have at least 3 dimensions.

    (I think this is because an Array in C2 is intrinsically a 3-dimensional array -- unlike in other programming languages -- so it follows this concept.)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Rex has the answer to life, universe and everything.

  • Denmla, to answer the question of sorting, it can be as simple as using C2's 'Sort Z Order'. The docs state:

    [quote:345z7z4s]Sort Z order

    Sort the Z order of instances of a given object according to an instance variable. This effectively removes all instances from their Z order, sorts them, then inserts the sorted sequence back in to the holes left behind. This means if the instances are spread across a range of layers, they will be sorted in the same Z order locations, maintaining the same order relative to other instances on those layers. Note this action is much faster than using an ordered For each with an action like Send to front/back, so this action should be the preferred way to sort the Z order of large numbers of instances.

    Create a new instance variable -- call it 'sort' -- for all sprites that needs to be sorted. Then set the 'sort' variable's value to the sprites's Y coordinates. Then call 'Sort Z Order'.

    However, if you want to snap to grid, you can make a custom function for this, but a practical solution really depends on how you've already set up your scene.

    My real suggestion, especially if you are thinking of expanding an isometric map, is to use a combination of Tiled and Rex's TMX importer, and Rex's Board plugin and SquareTx plugin (and other Board-related plugins that fit your gameplay).

    The Tiled app (TMX) will enable you to generate an isometric map using logical coordinates (grid coordinates).

    Rex's Board plugin will create a virtual board, so that you can start working in logical coordinates (rather than screen coordinates). The SquareTx plugin will make the Board 'graphical', or project the Board's logical coordinates into screen space. This makes it easier to manage a map, because you'll be only concerned with the logical coordinates, and you let SquareTx handle the projection of the graphics onto the map.

    Rex's TMX Importer will take the TMX info and using SquareTx, places the tile sprites on the Board.

    I could say more about this, but there are so many details. I have to say that making functional isometric grids in C2 is not very simple without these plugins. However, these plugins require you to study them carefully as well, but it's better than writing many functions to achieve the same effect.

  • Not sure if there is an basic C2 way, but I use this:

  • Do you use any effects?

    Personally, I had slowdowns related to the Shadow Light plugin.

  • R0J0hound, that's a great resource and reference. Many thanks for that. It's sometimes difficult to remember the issue I had before because the behaviour seemed inexplicable. So thanks for info.

  • For what it's worth, this bug is actually present in C3 as well. Just tried it. Perhaps we could get the devs attention to C2 if the problem is known to exist in C3.

  • Prominent, I see what you mean. There is a marked inconsistency with how picking is recognised. But also, as you pointed out, is it also an 'or' bug, because if you separate the 'type="yes"' away from the type="no" in different events, you won't fire the 'bug' text.

    On the other hand, if you use the system Pick (like you did with name="one") with "yes" and "no", while using 'or' the 'bug' text doesn't fire.

    Looks like an 'or' conditional issue. Either way there's certainly something amiss.

  • 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.