ID:1319808
 
(See the best response by Jp.)
Ok I give up. I litterally give up. I've been throwing myself at this for litterally two days now and I give up.
I can't do it, I just can't figure out a good way of managing this.


The problem:
My movement system goes on a coordinate based list that's hard coded into the game. There are four "lines" of enemies (It's my Castle remake, if that helps you understand the movement), and thus eight hard coded lists (One for each line, for both X and Y).

In addition to this, there are six additional lists for mobs that are above the size of 32x32.

I know it sounds overcomplicated and stupid but, it works, and it works really well infact.

The problem is that there is an enemy, the Hydra, that when he dies, he spawns four smaller children where he previously was. So the Large hydra (128x128) spawns four Small hydras (64x64), which occupy the same area as the large hydra. And when the small hydra dies, it spawns four Tiny hydras (32x32), which in turn fill the area that was previously occupied by the small hydras.


My god this is hard to explain, but I will press on.


Normally when something is spawned mid-route, I simply take whatever spawned it, take the current position in the list and give the spawned mobs that index. This means that if mob A, was going from point 4 to 5, and spawns mob B, mob B will also go from point 4 to 5.

The Hydra, spawns mobs that are in essence behind it on the track, which isn't normally a problem EXCEPT for if the hydra dies whilst it's actually litterally at one of the coords to switch to the next position in the list. This means that, using my previous system of giving it the same list position... makes my hydras go all whoopde doo off in different directions, because whilst the Small hydra was standing on point 3, and as such was about to move to point 4, the tiny hydra spawned "behind" it, will also want to move to point 4, despite it not actually reaching point 3 yet.



MY GOD THIS IS FREAKING HARD TO EXPLAIN OH MY GOD.

anyone who has played Castle will understand what I'm trying to explain at least 4 million times easier.


If anyone could possibly figure out a way of handling setting what position the mobs should be going towards, without having to hard code if(small hydra was standing on coords X and Y)do stuff, I'd probably offer felatio at this point.
*Plays Castle to try and understand what you mean*

Edit: Yeah, no idea, I may be way off but I'll take a crack at it. When you spawn Tiny Hydras from the Small one, I assume each one spawns on a tile that the Small one was covering? As such can't you just set the ones at the back 2 tiles to [index-1] in the list?

Or am I just way off and should go back to eating my ice-cream?
No, you've understood it, but the problem is that when I say "behind" I don't mean that they are above the first hydra, I mean they aren't at the point which the Hydra is at.

So, to elaborate, if a Hydra is at point 3, heading to point 4, but point 4 is actually ABOVE point 3, which two do I set to have index -1?

This is the problem, it's not that I don't get how to set the index properly, it's just the logic behind which hydras are actually before the point that the dying hydra has already reached that I can't work out.
Best response
Can you spawn the hydras at a point on the list?

So when you split, make a hydra, put it at index - 1, make a hydra, put it at index. How far apart are these points?

Alternately, get_step_towards. I'll consider two hydras for simplicity:

// Let hydra_1 and hydra_2 be the two hydras on the same line

hydra_1.index = index - 1
hydra_2.index = index - 1

var/turf/next_point = get_turf_from_index(index)
if(!(hydra_2 in get_step_towards(hydra_1, next_point))) hydra_1.index ++
if(!(hydra_1 in get_step_towards(hydra_2, next_point))) hydra_2.index ++


Basically, if hydras 1 and 2 are directly next to each other when they spawn, the one that will bump into the other if it steps towards the next index is the one that is 'behind'.
The problem is that you're again assuming that the problematic hydras are always the same two, it's not, it can be any one of the four smaller hydras spawned at any given corner on the map.

Maybe I'm misunderstanding the problem.

You've got several paths, labelled 1 through 4:

1234 4321
1234 4321
1234 4321
1234 4321
1234 4321
1234 4321
123444321
123333321
122222221
111111111


The path is stored as a series of waypoints. An example from path 1:

1       4








2 3


Things have a position, a path, and an index into that path which is their target turf they're walking towards.

You have one big thing which has its own special path, and when it splits you need to figure out which path to drop the smaller ones into and what their index should be. The problem is that depending on which side of a turn the split is on, the hydra with the lowest y, the lowest x, the highest x or the highest y might be the hydra that's conceptually 'most behind' in the path and so has a lower index.

If all of that is true then I don't see why the solutions I suggested above don't work. Or are you having problems assigning a line to the split hydras, as well as an index? (in which case you check if it's in one of the turfs in the line between the two index points in the path).
I stand corrected you seem to have a firm understanding of the situation, it's probably just me being unable to fathom your fix, could you possibly explain it with a slightly more down syndrome approach?


I'm being 100% serious, I just don't get it :(
Okay, some thoughts here, depending on the situation.

If your checkpoints are as separated as they are in my second ASCII-art picture, then your problems are (1) figuring out what 'path' each split is in, (2) handling the case where the split is across an index point.

If you look at your picture, every turf is in one path from a given set. That is, there are 4 'regular' paths, 2 'double size' paths, and 1 'large' path. That means that you can assign each turf a regular path label and a double-size path label corresponding to which path they're conceptually in. Every number in the first ASCII art diagram is the path label of that turf in that situation. You can assign these in the map editor. Then, the hydra can find out what path it's on by looking at the path label on it's loc (the hydra, of course, knows whether it's big or regular).

Similarly, you can label the turfs with the checkpoint they're on in the path they're on. Imagine taking my second ASCII art picture and writing '1' on every turf up to but not including the 2, 2 on every one up to but not including the 3, and so on. So the hydra can just look at the turf under it to know where it is and therefore where it needs to go.

You could do all this labelling at runtime as the game starts, too. That would save you some map editor work. Something like this entirely untested code:
turf
var
path_index // What the previous indice in the size path is for this turf
path_number // Which path this turf is in

path
var
list/turfs // Sequential list of checkpoint turfs in the path, always a straight line between any two turfs

var/list
paths // list of /path datums, not really relevant what the actual path is.

proc
do_path_numbering()
var/path = 1

for(var/path/p in paths)
var/index = 1
var/turf/old

for (var/turf/t in p)
if (!old)
old = t
continue

label_line(old, t, path, index)
++index

++path

label_line(turf/t1, turf/t2, path, index)
while (t1 != t2)
t1.path_index = index
t1.path_number = path

t1 = get_step_towards(t1, t2)


Is that clearer?

Alternately, if every single turf is a checkpoint (that is, there are no gaps between checkpoints), you can go "Okay, the hydra has split. That means we want a hydra on large path 1 and large path 2, at the index we were at and the index one before it". Grab the turf for path 1, index n, put a hydra there, set it to be going for n+1. Grab the turf for path 1, index n-1, put a hydra there going for n.
No, the problem isn't assigning what line they're on, the problem is where the larger hydra has reached point A, and it dies on that point, smaller Hydras spawned "behind" him (Behind as in, behind on the track) haven't yet reached point A, but their destination is still point B.

I don't know how to solve this.
Yes. That's the path_index bit.
Sigh, yes I understand that but you're missing the point.

There is no logic for deciding which hydras should have their index put back one, that is the entire problem, everything else works fine.
Maybe I am misinterpreting something.

Here's a segment of path, labelled with path_index as in the code above:

1111
2222
3333
4444


There's a big hydra:

1111
2##2
3##3
4444


It splits:

1111
2AB2
3CD3
4444


Hydra A's loc is labelled 2, so its goal is 3. B's loc is labelled 2, its goal is 3. C's loc is labelled 3, its goal is 4. D's loc is labelled 3, its goal is 4.
dude, just put in a check so that the hydra will only die when it's not moving at all.

Make it so that the Hydra won't die when it's taking damge, but that it will die when it stops, and checks its health, then it'll die, spawn the four mini-hydras.

This way you're never creating them mid-movement.
You've missed the point entirely, probably due to my awful explanation skills, but me and Jp are working on it and I think we've almost got a fix in place.