Clear you cache and
redownload the unit from FU to get two bugs fixed. (I have not updated
TA:Cataclysm's Stargate.)
Maelstrom wrote:Nice! I tested it out, and really liked it. But... One problem. I found quite a major bug. Stargates suck in other stargates!
I (tried) to build a 3x3 square of stargates. I managed to build one, and then halfway through another. Then the half built one got sucked in. The commander finished building it anyway. Then, he went on to the next one. That also got sucked in, but was eventually completed. Then onto the next row. By now we had 3 stargates all sucking each other in in turn, continuously blinking in and out of existance. The same thing happened till I got on to building the 6th stargate. Then, the commander as well as the half built 6th gate got sucked in to one of the numerous orbiting stargates. That was the last I saw of them. From then on, I only saw 1 stargate every half a second, for about one frame.
I tried this again another time, two stargates sucked each other in and flew across the map, to rest atop one of the walls on the Castles. Very... Strange?
I knew that my Stargate were able to teleport buildings in Spring, but somehow I failed to realise that it implied that Stargates would teleport other Stargates. Which cause a mess, because then both Stargates want to teleport each other.
I found out that apparently, Spring allows me to
- Attach Stargate A to Stargate B
- Then attach Stargate B to Stargate A
When that happened, both Stargates just vanished from the map.
Technically, I think that at every tick (so 30 times each second), Stargate A moved (or was moved?) to match the position of the piece of Stargate B it was attached to, then Stargate B moved (or was moved?) to match the position of the piece of Stargate A it was attached to. Since for the animation and the broadcasting I make teleported unit not attached to the base, but to a piece a bit next to it, that made Stargates fly that distance each 1/30 of seconds. Which mean they were fast flying far away out of the map.
But personnaly I prefer to think of it as: "Oh gnoes, by attaching A to B and B to A, I created a logical impossibility which warped both gate out of this plane of existence! Playing with wormhole technology is so dangerous, it creates paradoxes and that makes things vanish!"
Oh, and there was a Commander C attached to Stargate B. The commander too disappeared. When I pressed Ctrl C then C, to jump into the commander suit, I saw he was apparently jumping up and down. And the view was centered on the other corner of the map than the one I had my comm and built gate in the beginning. But maybe the commander was in reality out of the map, but the view remained blocked by the map limit. Just like for planes out of map in FPS mode.
When I asked the commander to build something on the map, Spring crashed. I guess the routine for the pathfinding of nanobots between two different planes of existence could benefit some debugging. Gnome and Castro think that I should create a request thread asking for Spring to support building things from other dimensions!
More seriously, I updated the script of
the Stargate on FileUniverse so Stargates don't attempt to teleport others Stargates anymore, and so the issue is all solved.
Isaactoo wrote:Also, If you send a non-gunship aircraft into the portal it gets stuck and just spins there. (in Spring anyways)
Plane have to fly pretty low to be grabbed by the Stargate. The Stargate use a spherical detection of units close, but I centered that sphere on the gate base, not on the ring center. Well, I could center the sphere on the ring center if I wanted to, I wanted a large grabbing radius for land unit and low grabbing radius for air units, so I kept the grabbing area half-globe shaped. So making a plane use the Stargate is pretty tricky. You have to decrease the altitude of the plane by telling it to land or by first person controlling it.
In TA, planes have the choice between letting themselves being teleported, or escaping at any time during the teleportation: Because I used the isairbase=1; tag to have units keep their order list, plane can take off the stargate just like they would take off a repair pad.
In Spring, apparently, planes that gets attached have only their XZ, and not their Y, moved to match the position of the piece they are attached to. Just like ships in TA refuse to be dragged underwater. That confused the gate into thinking they escaped like they can in TA, and so the Stargate just stopped to care about the planes, and the plane stay attached to the gate.
Well, that's my guess from seeing all the planes I sent into one Stargate get stuck into the event horizon.
Since it doesn't crash Spring, it could be interesting to have those "planes traps", where each plane that fly low enough to hit the event horizon gets stuck forever, but Stargates weren't meant to be butterfly nets, so I fixed that bug by making sure it that the Stargate script think a unit escaped, it drop it once anyway just to be sure. So with that new version, flying planes now just aren't teleported by Stargate. They may trigger the gate and be moved a bit by the gate animation if they fly now enough, but then the continue their flight right after. I updated
the version on FileUniverse to fix that too.
Also, as I was thinking that units underconstruction follow the factory when the factory is moved, but buildings underconstruction can be moved, I wondered what would happen if I attempted to grab a unit under construction from inside a factory. The experiment wasn't very conclusive, but I think the nanoframe couln't be grabbed. Which is how Spring should react IMO. However, during the test, I sorta managed to get my arm adv kbot lab to be stuck into an endless loop of being sucked in and spurted out by the Stargate. And each time it dropped, it imprinted the shape of its yardmap into the ground. In positive relief. After a while, that created two edges where the lab dropped. But, as you know, nothing is ever created, nothing is ever lost, everything just transforms, so the matter used to created those edges had to be taken somewhere. And indeed, after a while, a large shallow depression around the area became visible. Which gives me an idea for a new crazy zwzsg spring unit: The Driller, a unit that grabs the nearest building around and repeatedly smash it into the ground to dig a hole. Yay, my scripts render terraforming without the use of explosives possible! (the restore ground button doesn't count because you had to use explosive to deform the ground before being able to restore it later.)
On a more optmist note, I succesfully teleported a transport hovercraft loaded with three peewees. I was really happy to see it working fine instead of turning into a repeat of the philadelphia experiment.
And thanks for the bug reports. I need more people like you.
