[SOLVED] Delay is now there but Character will not move

Hey —,

Thank you so much for responding. I couldn't get help from anyone better considering the type of game I am making! :D

dropbox.com/s/dmm8nolsu07s9ck/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

Note: You'll need to scroll down to the Cheeky and Clamp Categories to see the events for movement logic. I created my own LoS since the LoS object seemed to be conflicting with the way I wanted it to work (Characters have to be equal on either or axis and clear of all obstacles).

Edit: Sorry the wait was 0.3 not 0.03. My initial information to you was wrong. That's fatigue talking after spending late nights up trying to work all this out haha!

Thank you — for your advice.

I thought I already created movement for him when he is b_SeesCheeky because, for example on event 66, if he sees cheeky but his charbox object is not on the same tile as cheeky's silouette then he should move, so I am a bit confused here. I'll have a look for a conflicting event that might be stopping this from happpening. I was pretty sure I put all of his movement commands in one group.

Sorry about the complicated events. I'm just trying to achieve the following and if I can get this fixed, I'm done with Chomp's movement:

1) Chomp spawns out of cave and moves out of the cave, depending on where the cave is facing (done)

2) Chomp randomly patrols, assisted by a timer (on timer events change his direction to a random direction, making his routine unpredictable)

3) Chases Cheeky when he sees him.

4) If Cheeky goes out of sight during the chase, Chomp will stop at his last seen location - This is why I get Chomp to only 'see' the Silhouette that I have on Cheeky. The Silhouette will follow Cheeky everywhere until Chomp sees and then 'loses sight' of him.

However, the trouble I am having is:

1) Getting Chomp to accurately stop his movement the moment he is in-line with Cheeky on an axis (clear of obstacles) every time as it's only happening sometimes and;

2) When he is chasing and does catch up to the Silhouette, instead of stopping on the same tile as the Silhouette, he exceeds by one tile. This happens almost every time.

It's like Chomp is moving too fast for the game to stop and go "Okay I'm on this tile, I need to do this now." This is why I was hoping to find some way of getting this checked without creating noticeable jerky movement in the game play.

Ya I was expecting simpler tile movement events but you have a lot of events with sub events running every tick, and I can't edit the file as I don't own C3. I just apply the same logic from C2 on projects I can test :D I did notice that event 77 doesn't have a wait though which might cause inconsistencies.

Oh I see. No worries, you seem like you have a lot of experience though, so any advice would be appreciated of course.

I am still searching through my events regarding what you said about b_SeesCheeky = True is stopping movement.

I have also added an else condition in for Clamp Direction, I'll post again with an update soon. I am hoping to overcome my issue this way.

Another idea I had was to use the timer behaviour to initiate movement, that way I might be able to give Construct 3 the chance to consider the position of objects before moving again, but I have not tried this yet.

Edit: I'm a bit inexperienced with the 'wait' system action, I sorta just threw it in there thinking it would allow the game to check other things before coming back to that event again. Am I wrong to do this or do you think a timer would be better?

I have been very careful to ensure that rotating and moving are completely separate and do not happen at the same time. I wanted to provide the effect that the Clamp is changing direction but I did not want it to interfere with the Clamp's movement. Clamps should not be rotating at the same time they are moving, basically. What kind of problems do you believe I may have with the way it is now?

Also, after checking my events, I cannot see where b_SeesCheeky = True was stopping movement. However, I can see there is a problem with him chasing to the right as oppose to chasing downwards. I'm still trying to see how this is not working.

What I might do is start doing the timer idea and then come back to this and see if it's still happening. I get the feeling that it has something to do with the conditions checking the i_Tile_X and i_Tile_Y variables.

I also get the feeling that there is definitely a shorter way to do this but my limited experience is preventing me from working that out.

Okay, I am more stuck than before now. I have put timers in, this has now fixed the delay issue with Chomp (I'm yet to add a similar mechanic for Cheeky), but now Chomp will not move at all when he sees Cheeky:

dropbox.com/s/dmm8nolsu07s9ck/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

All I did was change it so that I was considering Chomp's X and Y. If they are not the same then simulate control in the appropriate direction. It's not doing that, so I am very confused. What am I doing wrong here?

Edit: Definitely an issue with considering the X and Y. The conditions there were wrong before moving the clamp. I have now fixed this problem. I just had to think more about how event conditions work more.

Indeed I could tweak all this to perform better, but I have not got to that stage yet.

Thanks for your help, Plinkie!

i would like to take a look at your isolated movement part of the code if possible.

what my suggestion is if is not possible to be shared, is that you could try instead of using X or Y as prerequisite for line of sight and instead use movement direction +distance from where it should stop.

for example if enemy is moving only in a foward type of patern or clockwise lets say in a square or round pattern, u can say that is "front_movement" if he moves any other direction then is not forward... with that logic in mind, adding additionally a distance to stop from objective point reached.

so enemy is moving_forward

and

distance(enemy.x,enemy.y, player.x,player.y) less or equal with 32 pixels lets say don't know ur grid size but lets assume u have a 32 by 32 grid movement block that means he is on a block adjacent to another meaning he needs to stop at a 32 pixels distance from players XY.

hope it makes sense to you and helps you achieve a new solution.

if it doesn't i could demonstrate it to you on ur tilebased movement i guess.

also the movement should be general for all enemys, not just 1 type of mob... with little tweaks for type of mobs of course but the core movement system should be the same for all enemy (ex distance+movement forward has to be basic rules, what is considered additional ruling based on class is up to you to decide being it speed movement, waiting time etc), otherwise you will cause long run development conflicts.

Try refresh the page using shift+f5 or ctrl+f5 to force clear the website memory cache... i tend to edit a lot of times my posts.

Edit ~5: the problem i see with using x enemy = player x or y is that the enemy if is a large patch of grid movements, then the enemy can be at 10-20 grid spaces distance but on same X or Y and that would might be true for the logic of the system, but it would look glitchy as hell, as won't be near the player at all.

Hey GeorgeZaharia

Thank you for your interest. I understand you wish to have a look.

Please go to this link I have made available: dropbox.com/s/9upzsaiuaorva6p/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

This is my current version after the fix I made. Please check it out.

I have not read your entire post yet because I have to go out. I'll be back and have a proper look at what you're saying.

Hey GeorgeZaharia

Thank you for your interest. I understand you wish to have a look.

Please go to this link I have made available: dropbox.com/s/9upzsaiuaorva6p/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

This is my current version after the fix I made. Please check it out.

I have not read your entire post yet because I have to go out. I'll be back and have a proper look at what you're saying.

Cool, thanks il upload my own version on a personal link, u can remove urs from public view, also, i just noticed this says Solved in title yet the last commentary you posted about being "solved", i sort of skipped it(my bad). il try simplify ur movement if u didn't already i guess and get back to you.

took a quick glimpse at the movement, is a bit overworked but it does what u intended so it should be fine.

but u could just added pathfinding behavior to the Clamp, and go with a logic somewhere like when he has line of sight on player find path to player and make it move towards player along the path every time%speed where speed = anywhere from 0.1 to n which would make him look like is doing tile movement pattern.

> Hey GeorgeZaharia

>

> Thank you for your interest. I understand you wish to have a look.

>

> Please go to this link I have made available: dropbox.com/s/9upzsaiuaorva6p/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

>

> This is my current version after the fix I made. Please check it out.

>

> I have not read your entire post yet because I have to go out. I'll be back and have a proper look at what you're saying.

Cool, thanks il upload my own version on a personal link, u can remove urs from public view, also, i just noticed this says Solved in title yet the last commentary you posted about being "solved", i sort of skipped it(my bad). il try simplify ur movement if u didn't already i guess and get back to you.

took a quick glimpse at the movement, is a bit overworked but it does what u intended so it should be fine.

but u could just added pathfinding behavior to the Clamp, and go with a logic somewhere like when he has line of sight on player find path to player and make it move towards player along the path every time%speed where speed = anywhere from 0.1 to n which would make him look like is doing tile movement pattern.

Hey George. I just read your post. Your initial explanation in your first post seemed a bit unclear to me. Yes I do plan to make this type of movement uniformed across all character objects, and I do feel like I am overworking the tile movement. I'd say this is because of the combination of different AI: Patrol vs Chew vs Chase vs not moving onto Obstacles that I have to consider.

I did consider the pathfinding behaviour a few times. But I kept coming back to the tile movement behaviour since I was not confident that the path finding behaviour would deliver exactly the type of movement I am wanting for my game. However, I would really love to see your suggestions to improve it, regardless what it is, if it's good and it works well with what I am after, I'll implement it and give you credit.

My opportunities for development in getting better at Construct is to stop over-complicating basic functions because often I would put in extra conditions in for an action that is not necessarily required. I try not to do this but sometimes because of how Construct works I have to provide additional work-arounds. For example, you will notice before my clamp moves, his angle snaps to exactly the correct angle. This is because despite my attempts to stop his rotation when he faces a certain way, he will miss the angle he needs to be at or he will be off by a few degrees which ends up causing other bugs. The same thing happens with snapping his axis to exactly the silhouette's. If I don't do that, it might be 0.00000001 pixel off, so the event for chasing Cheeky will not run because it's not the same. I like the idea of checking his position in comparison to the the silhouette in pixels because doing it tile based seems to conflict because the image of the CHARBOX objects are different sizes (which seems to cause a slight misalignment despite the fact that all tile movement behaviours are set to 32x32), rendering checking position in such a game to be inconsistent, so I need a more consistent approach. At my experience level, I found that this was the best thing I could up with. It's also comforting to know that my characters are perfectly travelling and fixing themselves accordingly. However, I honestly believe this is the difference between my personal experience with Construct's engine as opposed to most people on this forum such as yourself. I am always very open and interested to listening to feedback about how I can improve my projects, so if I share something I am working on, do not hesitate to provide your recommendations because I want to learn. =]

— Cool I'm glad that you managed to find a fix there, I wasn't able to mess around with it :)

Thanks! I wish I could private message this but why do you choose Construct 2 and not Construct 3?