Think you need to supply a screenshot of some sort, cant see the link you have posted. And the text alone doesn't really explain or show the problem

No there are no way to work around it unfortunately.

You can just make them as two separate objects, 1 sprite and one tilefont and then you place them where you want them. Then use the "effect" SetColor to change the color of them based on RGB values.

C2 does already use A* as far as I know. The problem is just that its very limited in its implementation, so its more or less only useful for simply finding a path from A to B. The moment you need it to do something more advance it quickly falls apart resulting in weird problems. That's why you can use it to find a path and then you add "Patchwork" to fix the things that fails.

So think its a bit of trade off, whether you want to make your own which would give you a lot of control like setting the G score make sure it can move diagonal passed other units correctly or whether you use C2s pathfinding as basis and correct the things that doesn't work well. What takes the longest time and is the most complicated im not certain off.

But as I see it C2 pathfinding is mainly aimed towards RTS games, where it doesn't have to be all that precise and it doesn't matter to much if units move correctly passed each other, which will give it better performance for such games . But for tilebased games these errors become really obvious and will need to be corrected.

However if you fancy making your own, this is a good page to start I think.

http://www.policyalmanac.org/games/aStarTutorial.htm

I use something similar in my game and ran into a lot of problems with it as well. You can however use the pathfinding in C2, you just have to use it as a non optimized pathfinding tool that will just give you the basic path from A to B. It have quite a few problems with tilemaps, which you will have to correct manually afterwards.

The way I use it in my game is like this:

1. Enemy acquire a target

2. Find the nearest empty tile near the target.

3. Find path to this tile.

4. Store all the nodes which it have found.

5. Since it have problems moving diagonal around other units (Big problem when using tilemaps). I correct the path everytime a unit moves to make up for this.

6. As this doesn't solve all problems and the pathfinding ignore some collisions for some reason. I will in case step 5 doesn't solve it, make it find a path again. Which will make it start from step 1 once again, but from its current position.

But that will eventually get the unit to the target.

So you should be able to do the same in your game as I have in my game. The way you do it is to check the node after the one its currently moving towards. If this node is next to the current one you remove the current node and instead let it move to the next one.

Using your example:

0: 0,2

1: 1,2

2: 2,2

3: 2,1

Lets assume the unit is standing at 0, 2 then you test:

Value of

node(Unit position).X + 1 = node(1).X

and value of

node(Unit position).Y = node(1).Y are true

Since that's the case you know that the unit is moving from left -> right

So now you have to check if the next node again is above or below node(1)

So you do another check:

Value of

node(Unit position).X + 1 = node(2).X

and value of

node(Unit position).Y - 1 = node(2).Y are true

If that's the case you know there are another node above node(1)

And for the bottom:

Value of

node(Unit position).X + 1 = node(2).X

and value of

node(Unit position).Y + 1 = node(2).Y are true

Would be a node below node(1)

Since none of these are true you do nothing an let the unit move along the path.

So now the unit is at (1.2) and then you do it again.

Value of

node(Unit position).X + 1 = node(1).X

and value of

node(Unit position).Y = node(1).Y are true

Again this is true indicating that the unit is still moving from left -> right

So we check to see if there is another node above node(1):

Value of

node(Unit position).X + 1 = node(2).X

and value of

node(Unit position).Y - 1 = node(2).Y are true

Which there are in this case (2,1)

So you remove node(1) from your list, so instead of the unit moving to (2,2) which it would normally do, it will now move from tile(1,2) -> (2,1)

And you make something like that for all directions. Whether that will solve all your problems I doubt and you most likely have to do as I showed in the above approach.

Not 100% sure I understand what you mean, you want a sprite to spawn at a certain tile?

If that's the case you can set the position of the sprite.X to Tilemap.TileToPositionX(TileNumberX) and the same for the Y.

So:

Sprite.X = Tilemap.TileToPositionX(0)

Sprite.Y = Tilemap.TileToPositionY(0)

Would place it in the top left corner.

If you want it to place it at a certain type of tile like grass. You just add a loop that goes through your tilemap and you make a check against the tile that holds the "Grass" one.

What confuse me a little is:

[quote:2u9wx53u]For example create this object at tilemap "Grass" for the "1,5,6,7" tiles at...

Because im not really sure what you refer to, as tile position are a coordinate (0,0) or (2,5) and so on.

Minor update:

Still working on the tactical combat system, which maybe not surprisingly turned out to be a lot more difficult than expected

However its starting to work a bit better after a severe overhaul and a LOT of bug fixes and it is now possible to add different strategies to enemies, based on behaviour values, which will/should allow enemies to switch tactics during fight, and even let same type of enemies prefer doing different things, based on these and the type of items they are equipped with.

Features added:

• Close combat tactic
• Range combat tactic
• System for close combat animation
• Missile animation for range combat
• Automatic switching between range combat and close combat depending on whether an enemy is attacked in close combat.
• Behavioural system for more dynamic strategies
• Individual equipment of enemies so each enemy is randomly equipped
• Simple combat text

Example of range and close combat

However there is still a long way before this part is done. But next step will be to integrate it into the rest of the game so a very simple version of the game can be played.

Not sure that is possible but would be a nice feature

Linking it to another sprite should fix it, I was just wondering how come it weren't possible as it have a collision mesh like any other object. But thanks anyway, I was more interested the reason or what things makes spritefonts "special" that it had been decided that it shouldn't work with this.

Just wondering how come its not possible for spritefont to check vs collisions?

Meaning that if you do Spritefont is overlapping some other object?

It can be checked against by other objects and it do have a collision mesh as well. Any particular reason why it doesn't work?

This is another problem, which I still haven't figured out why happens and is harder to recreate.

In the image the yellow squares shows the actual path of the enemy on tile (4,7) these are based on the nodes that the path finding behavior have found to be valid. As seen it actually think that the tile at (4,4) is a good place to go, even though its blocked. The obstacle map have been regenerated at this point and printing the collision cells the same way as I did in the above example shows that this tile is in fact marked as a collision cell. But doesn't seem to have any effect for when its tries to find a path. The actual goal for the enemy is to reach tile (4,3) left of the character.

So to make it work I had to add my own path finding correction code, that manipulate or fix the path for mistakes like this.

But each time you have to make correctional code like this, it complicates things a lot and you don't really know if this solves all problems that can happen. But as I said I have no clue why it ignore some of the collision cells.

Yes, sounds like a good idea. Maybe in combination with the current method. If the cell is blocked, choose the nearest empty cell (because that would be much faster in many scenarios). If A* can't reach that one then get the nearest reachable cell (cell with the lowest H value from the closed list?).

Yeah exactly. Because it seems that it doesn't really care at all whether the cell it pick as the nearest is actually reachable or not, before deciding whether that's the best alternative, and therefore it doesn't check any other cells surrounding the goal. But just keeps checking the same cell and failing to find path to it.

But whether its the best method I don't know. But it make sense that if it fails to find a path, that the best alternative cells to move to instead would be one nearest to the last nodes on the closed list. Meaning the cells that got it closest to its initial target, before figuring out that it couldn't reach it.