If you're using Set Size, then this is likely due to the way relative scaling works in C2 (and I guess C3). The most direct way is to store your height in an instance variable, which is initialised at layout load. That way you always have a value reference with which you can use 'Set Scale' which is more reliable.

More than 50% of the plugins I use for my projects are Rex's.

It's always a pity to lose the interest of a 3rd-party dev. A host app may be powerful, but I find that 3rd-party developer initiatives is the factor that makes me stick to an application because they are naturally directed to address real-world workflow problems.

Agreed. I even suggested Scirra giving those 2 Rojo and Rex free subs for C3 because they are so awesome to have in this community. Never had a reply to the suggestion. :-/

Havok

Over many years, I made lots of free tools for a 3d prog called LightWave and got into their beta program (which also featured special discounts) through the urging of a fellow community member .

But I'd like to venture a guess that, given the fact that these developers provide tools for free, discounts don't rank as highly as good and healthy communication between them and the community, and Scirra itself, the developers of the host app.

I'd like to thank rexrainbow for his generosity both in the providing of these tools, and especially his willingness to give his time to answer questions, and provide support freely. I've done this myself for a long time in the 3d/CG world, so I can deeply relate to his passion for his work.

I wish him all the best.

dop2000 At the moment, my walls are 2/3 times larger than FTL's, and either the objects struggle to get through, or they phase through the walls. The pathfinding plugins seemingly don't have an issue with corner cutting either, which is really annoying.

AnD4D as mOOnpunk mentioned, use Rex's Edges as a starting point. But when you do, there is a bit of an issue regarding diagonal movement and edges. Edges only cover the 4 'cardinal' directions (N, S, W, E) not the diagonal ones (ie corners). I've written some research notes about how to overcome this. These notes are assuming you already now how to use SLG movement and how to set the proper movement cost. Not for the faint of heart <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":-)" title="Smile">

https://c2isogame.wordpress.com/2017/04 ... oss-edges/

Also, another separate issue that you may encounter:

https://c2isogame.wordpress.com/2017/04 ... dge-issue/

If anything is unclear, let me know.

Shame there's not a simple plugin/behaviour this late in C2's lifetime.

By any chance are you using Tiled (the tilemap editor) to do your levels? While that would certainly increase your setup complexity, I find that once you set up your TMX reader in C2, you'll find the Board system quite robust.

I will admit that the Rex's Board plugin is complex, but what I like about it is that it's scaleable and predictable. Once set up, it's easy to apply the behaviour to any number of NPCs.

On other hand, if you are only doing pathfinding on a few characters and your maps are generally small, then perhaps you don't need the 'scalability'.

Without seeing the capx, I'm not sure how you're doing the countdown timer. But here are the elements of a countdown timer.

• Start/Stop boolean. This tells whether the countdown timer is counting down.
• Countdown max time. What is the countdown's maximum time. In your case, it's probably 25 seconds.
• Countdown current time. When the countdown timer is at 'Start', current time is subtracted by delta time per tick.
• Finish condition. Every tick, check if current time is <= 0. If True, then put the countdown timer to 'Stop'. Then reset countdown timer's current time = max time. This is the reset. You also put any other action you need on Finish.

I can't speak for others, but you didn't say anything weird.

However, designing an AI is very involved question. In my opinion, before you can think about AI, you have to design your gameplay mechanics because the AI will work based on that.

So the question is not easily answerable because it's too general.

In my opinion, it's better to start from the beginning. If you want to work on NPCs (ie enemies), create a framework for movement first. In your example, that's a top-down orthographic grid-based movement.

• Create obstacles on the grid.
• Create your enemy entities to move on the grid.
• Create a method by which you can instruct an NPC to move to a certain place using grid pathfinding (avoiding or moving around obstacles). This instruction can be pre-defined. It's only to make sure you can tell an NPC to move.
• Create methods which trigger an NPC to move to a specified place. For example, the trigger can be a countdown timer, or it can be based on a keypress, or it can be based on a player moving over a grid square. Also, for example, make the NPC go to a location if its 'health' is low or some other variable condition is met.

Those things are obviously basic and only related to movement. But when you succeed to achieving those basic things, I think you will have just enough exposure the concept of AI and start expanding those things to reflect the gameplay mechanics that you are designing. For example, you can include things like the enemy will consider closed/open doors for movement, or attack the player using ranged weapons if the NPC has any, or if the enemy's health is low, you can make him use some 'healing' item. But that is more advanced and I think you need to concentrate on the very basic stuff first.

When I was going my AI in my RND project (I have an RND project alongside my actual game project to test concepts), the movement was the most important bit because it was the one that was easily full of bugs. And it was made much harder due to multiple enemies who sometimes could not pathfind correctly amongst other moving enemies.

Hint: if you are still researching grid movement, I suggest using rexrainbow's Board system.

I'm no expert, btw. However, I don't think that unifying the events for generic NPC behaviour improves performance; I think it's better for organisation and debugging purposes (so you fix bugs in only one area instead of each NPC's event area).

It looks like you didn't use Families, which may be more difficult to pick if you intend to have different Sprite objects to represent different NPCs. But this depends on how you intend to organise your NPC graphics.

If you intend to have different Sprite objects for different NPCs, then you would want to create a Family and put those NPC Sprites in there, and use the Family to replace `actor_NPCMask`.

Or, if you intend to use the Animation Folders of `actor_NPCMask`to define separate NPCs (for example, you have an Animation Folders such as 'NPC1_walk', 'NPC2_walk', 'NPC1_idle', 'NPC2_idle', etc), then you don't have to change anything in your event sheet. But of course, you have to maintain `actor_NPCMask` as your main Sprite object that contains all of the graphics of your NPCs that will use this event sheet. There's also the added complication of keeping track of which animation a particular `actor_NPCMask` instance is going to use; you'll probably need to create an instance variable determining the name/identity of a particular `actor_NPCMask` instance and then match the instance variable with the Animation name.

I'd recommend using Rex's moveto behaviour. It will handle acceleration for you. You can use the 'Move to delta X/Y' action to move according to Angle.

Hi, I don't have a specific solution for your question, but I recommend investing time in learning Rex's Board plugins and behaviours. I've used this extensively (although I'm using this for isometric, the principle of the plugin is the same for orthographic) and I found they solve many of the problems you describe.

For example, it is easy to query if a particular 'chess' piece is a neighbour of another (instead of doing your own function). You can also query how many movement tiles away two 'chess' pieces are.

Rex has also implemented pathfinding, too.

However, it takes a bit of patience to learn all the capabilities because the Rex's 'Board' system is composed of several plugins and behaviours. You don't need to use all of the plugins or behaviours, just the ones you think you need. I really recommend giving it a go. If you're stuck with an issue, you can just ask, and perhaps I (or even Rex) could offer some suggestions using the Board system.

(I've always wanted to do a Rex Board tutorial series, but I haven't had enough time. )

'Simpler' can be relative.

What I would 'simplify' in that tutorial is the use of the 'Up', 'Down', 'Left', and 'Right' words and replace them with actual angles. For example, the animation names would be: Walk0, Walk90, Walk-90, Walk180, etc. Then I would use the 8Direction.MovingAngle value directly and construct the animation name:

'Walk' & Player.8Direction.MovingAngle

That way I can avoid all the checks.

Re the original animation trigger issue: I don't think there's an issue with the trigger itself; the trigger is firing ok. The problem, from what I can see, has more to do with the Set Size command. It seems that because your animation have different sizes, it somehow gets screwed up.

I think that, internally, C2 applies a scaling factor when you Set Size by pixels. If Animation2 has 102x103px, and you set the size at 110,110, you set the scaling factor at 1.078.

Then Animation2 finishes, and then goes to Default animation (250x250px original), which then gets scaled to 269px. (250 x 1.078 == 269px).

Then you apply a size of 64,64, and the result is 156px. Why?

Well, I think it's because the 64,64 is applying a scale against the original 110,100 (1.078 scaling). So:

64/110 == 0.5818

And so Default animation new size is 269px:

269 x 0.5818 = 156px

In a word it assumes the new scale, but that doesn't mean it's necessarily the same pixel size. My recommendation is to compute for scale based on your expected Sprite resolution for a particular animation, then use Set Scale instead of the Set Size.

N.B. I'd consider this a bug in Set Size, not Animation Trigger. Who wants to report it?

It looks either a bug or simply an unsupported feature. Two calls to the same Function called at the same time; the picking of the Sprite works for one of the calls, but not the other. <shrug>

Thanks. Yeah, when I saw the method working, it seemed like the the greatest thing since sliced bread.