Now I know I 'm not the only one that sends a com through a teleporter as a halley is flying at my planet so he can live and I know it should be obvious to keep an eye on him as expected but when he decided to walk back through the teleporter because codeing and then dies to the same halley that I wanted to keep him away from...Uber pls.
I am not sure how it happened. Here is just my guess, and it may be wrong. When you sent the commander to enter the teleporter, you also held the shift button. And you right clicked the teleporter multiple times for making sure it would enter the teleporter. Then here comes the problem: Once the commander passed the teleporter, the only way for it to enter the teleporter again is to go back. So the solution is very simple, right clicking the teleporter without holding the shift button. Even if you right clicking the teleporter multiple times, I think it will enter the teleporter once and never come back.
I have other question about the teleporter and path finding. What happen if a player selects a group of land units and right click on the ground of other planet? Will the units find and pass a teleporter to reach the destination? In my experience, they won't make it. But why it happens to g0hstreaper's commander?
This is the only way I can see this happening (barring weird bug). Giving a teleporter a move action sets a rally point, just like a factory. Setting it on itself will cause it to just walk around and go back through.
I made a test to the teleporters. There are four teleporters: A, B, C, and D. A is linked with B, and C is linked with D. I select teleporter B, and give it a move order to the C. After that, I send dox to enter the A. Dox go out from B, and they walk to the C. But they just stay nearby C rather than enter C. I must select teleporter B, and give it a "use" order to the C. Then the units which go out from B will enter the teleporter C. It is quite funny to make a loop. Just select the teleporter D and give it a "use" order to the A. Then all the units go into a loop: A -> B -> C -> D -> A. I think this trick can be used to hide commander on multiple planets And I found out that to use the enemy's teleporter, the correct order is "use" rather than "move".
I think it would be better if teleporters weren't linked at all, but were simply a window into any other teleporter present. This would mean that you could send move orders to a specific location on a planet only, and your units would use any route required to get there. The benefit? You could set up teleporters all around the edges of your base, and one in the centre, and you could order your units around like a magician some jumping in and out of teleporters wherever that would be beneficial. This is a much better solution to the current method which requires you to micro the whole process without any benefit to the experience of playing the game.
I feel it will be very challenging for programmer to make such a path finding. Thus, it won't be implemented.
Of course not! I just read some Q&A or the reply in other threads, one of the most computational expensive cost for server is the path finding. The problem of path finding also causes many other issues such as the broken crater system and the asteroid must destroy entire planet. Since the current path finding is still imperfect, I believe there will no more challenging new features be added into it.
PA uses a vector field pathfinding solution, or 'goal based'. It's sorta like traditional pathfinding but backwards. In regular pathfinding, each unit finds its own path to the goal with one of many algorithms that do the meat of the work. It works great with large maps and just a few units, but starts to seriously slow down with more units, especially if they bump into each other. Vector field or goal based is reversed- the goal 'finds' the shortest path to itself from every single location possible and saves it as a bunch of arrows all over the map. That's a pretty hefty upfront cost, but the key is that it really doesn't matter how many units you have. All the paths are already solved, so the unit just follows whatever arrow its on. As you might see though, bigger maps slow this down because you have to generate more arrows. So linking planets with pathable teleporters massively increases the total size that has to be calculated, not to mention 'folding' the 3d pathing problem up into a bizzare 4d+ Swiss cheese shaped surface that probably has lots of other implications that go waaaay beyond just 'slower'. Is it possible? Yes. Is it practical? Probably not, especially if it was integrated seamlessly into the vector fields. Maybe some higher level logic could go and find teleporters outside of the pathfinding and then set them as goals, but I see that being buggy and slow. @Sorian, I know this has come up in the past, but what would doing this actually entail? I'm trying to wrap my brain around it and it's just giving me a headache.
You know, I think I may have made some progress with the brain wrapping. Obviously, this is all theorycrafting but its at least a plausible framework to include teleporters in pathing. First, we have to make a small change- Teleporters are no longer linked to just one other teleporter- they are on or off, and all teleporters are all linked to each other. Here is how it goes- 1) Issue move order, and generate distance field as normal. 2) Iterate though the list of all active teleporters, and find the teleporter that has the lowest distance scalar. That one is the closest to the goal. 3) Set all other teleporters as 'goals', only instead of being zero distance, they start at the distance from the closest teleporter we found above. 4) Generate vectors, and continue pathfinding as usual. 5) The exit teleporter is the one with the lowest distance scalar, or the one we found in step 2. Now, step 3 is the kicker. Not sure how computationally intensive it would be to update the distance field like that. It might be the equivalent of generating an entirely new distance field, or generating one for each teleporter. That sounds expensive. Maybe there could be a secondary distance field that is only updated when teleporters are built. Each teleporter would represent a goal, and when you issue a move order, instead of number 3, you just add the scalar from step 2 to every distance and then subtract them all from the primary distance field. Or I guess it might be more efficient to skip all of those additions and subtractions and have each unit, instead of simply looking up its distance, also perform the necessary additions and subtractions. It would depend on how and when the vectors are generated, and if there is some pruning method in place that ignores areas of the distance field. Either way, when you issue a move order, especially if the secondary teleporter field is pre-generated, the only extra non-constant time with respect to unit count thing you have to do is iterate through all the teleporters. I cant see that begin a big thing in terms of lag. As for interplanetary teleporters, I think that's actually easier. Just make the secondary teleporter field the primary for the current planet (so the units find the nearest teleporter) and then perform steps 2, 4, and 5 for the destination planet. @Quitch, is there enough access to pathfinding/AI available to do this sort of thing? I cant imagine that there is, but one can hope. That is one thing I miss about modding minecraft. You could literally do anything (And let me tell you, I made that game do things that it was never intended to do). edit- Seriously, I tore holes in the very fabric of minecraft's blocky reality
What will happen if cross or conflict connection between two parallel orders? For example, unit group X wants to go to the teleporter A and get out from teleporter B. But at the same time, unit group Y wants to go to the teleporter A and get out from teleporter C. What can the teleporter A do? Repeatly switches connection to B and C?
It would have to be every teleporter (or every allied teleporter) is linked to every other teleporter (or allied teleporter) Sort of like tunnel networks in C&C Generals. This would be weird though. And a lot of work.
Thats not actually an issue, because all teleporters would be connected to all other teleporters. The units would just warp to the teleporter closest to their destination. That said, its actually a fair bit more complex than I originally though. I got a application running in java that lets me play with flow fields, and I definitely think its possible, but not exactly how I described. A flow field can really only have one goal for it to work, otherwise you get strange stringy happenings. You cant compress it all down into a single field, you need to actually explicitly set the primary flow field goal to the correct teleporter.
Hm. It should be possible. But as always you need to pay attention to the places where gradients with almost opposing directions meet. Those points are always singularities in the sense that they do not posses any direction at all, the gradient just vanishes. That said, I believe there are design reasons why we have the current system. o The system is obviously designed to feel stargatey. o Automatically pick the nearest teleporter, will prevent using 2 parallel teleporters to get a higher throughput on an invasion. At least there is no trivial way to do it. o Currently queuing up a additional factory to a teleporter is a local thing: You select the factory, then issue a move/use order to the local teleporter. In the proposed system this has no meaning. You need to issue a move order which equates to the final destination through the teleporter. If the units should teleport through to another planet, that involves planet switching. o Automating to much of the path finding will lead to situations where units do things, which may be more clever, but the user doesn't expect and (of course) from a user perspective this expectation is always authoritative. We have those moments already, where people can not estimate the shortest path on a sphere and then complaining why units don't move along the "direct" path of a move order. Imagine a scenario, where a base gets attack and a user issues a move command towards the enemy units, but instead going directly against those units the path finding sees a shorter path through two teleporters at the edge of the base, where the starting teleporter lies at the opposit direction of the enemy units. Just imagine the reaction of the player, when he sees his units moving away from the opposing force.
