Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Research/Theory/Question: AircraftType Transit Stations
#1
Introductory side note: I pondered creating a generic research thread, akin to Sleipnir's and countless others, but those are generally a pain in the ass to wade through. So I hereby declare research should be done in separate threads for each theory.

ModEnc Wrote:If DockingOffset= points to outside the Foundation=, the aircraft will be produced on that offset as usual, but they'll refuse to land there after flying.

Nikademis Wrote:Having the docking points outside of the foundation I have found that this has no affect on the planes not returning to base

Given that the whole point of Nikademis's thread was that he had problems setting the coordinates right, I don't know if he has actually tested this, or just thinks he has. Nevertheless, even if ModEnc is right, I would assume this to be fixable by our fearless code warriors in Ares.

The Theory
Why do I create a thread about this? Frankly, because I had an idea and I have no YR installed to test it. So I need someone else to do it.
I am assuming the following premises. I openly admit I'm only 80% sure on the first one, it's been a long time since I tried this. If it's not true, that would remove the need for Nikademis's find, but this way would probably be more glitch free anyway.
  • Passengers cannot step into AircraftTypes while they're docked, because there's a building below them. (That's why non-Ares custom paradrops usually use AircraftTypes that can land everywhere.)
  • AircraftTypes can have passengers.
  • AircraftTypes can be made to land outside the foundation of a building.
  • In older versions, AircaftTypes could be re-assigned to a different Airport - this would work either in those versions, or if that gets restored in Ares.

So what am I getting at? Basically, something like actual airports. Imagine the following:
  • You code up a Transit Station, using 3x3Refinery as the Foundation, placing DockingOffset0 directly in the empty cell.
  • You code up a transport AircraftType that docks with the Transit Station.
  • Since the Transport is not sitting on the actual building, troops can enter.
  • Since we can re-assign the Transport to a different Transit Station, we now have a transporting AircraftType that can only land on specific pre-designated locations/airports on the map.

Awesome alternative uses:
Paradrop Station
Since AircraftType + Passenger + Weapon = Paradrop, even without the ability to re-assign, this system would be good to have a sort of "Paradrop Station" - soldiers can enter the parked plane at the station, and be flown off into the danger zone. This way, the paradrop plane would not land at a random hostile area once it's done attacking, but return home for re-use, and it would automatically be healed.

Teleportation Station
The Holy Grail of chrono modding research: A sort of "Stargate" between two bases, where units enter on one side and emerge on the other.
If reassigning works, one could simply place wormhole artwork where the unoccupied cell is, and use an invisible/immune/ultra-quick/possibly even chronoing if that can be made to work AircraftType as the transporter.
Soldiers would seem to enter the wormhole, you select the wormhole, select the target Teleportation Station, and have your soldiers emerge there.

Generals-style Tunnels
Same principle as above (Transporter airplane is disguised as much as possible), but the Transit Station is made to look like a tunnel entrance instead; you could also create a digging unit which deploys into a tunnel entrance, allowing you to dig a tunnel behind enemy lines and then starting to send your army through.

Super-awesome alternative uses:
Actual Teleportation Station
Did I mention the Holy Grail of chrono research?
Well...the Chrono Miner does use teleportation, does it not? And the Refinery uses the Dock= system as well...and reassigning has not been turned off for Miners.....just sayin'...
Of course, AirportBound is not designed for VehicleTypes, so you'd have to craft a way to limit the invisible transporter - you don't want to enter an unrestricted, invisible, invulnerable chrono transport into the game.

So we simply don't allow it to move where we don't want it to in the first place!
Tell your users that, in order to work, your Teleportation Station needs a Teleportation Platform; create a second building that requires the station and uses ToTile to convert to a piece of environment that looks sufficiently sci-fi; assign that tile to an unused TerrainType, like Weeds or Ice; now simply make sure that the Transporter can only move on that specific TerrainType - that way, it should not be able to leave the transportation platform - only jump between stations. It has the additional advantage of allowing you to select precisely who can enter the wormhole and who can't - just don't allow the suckers to pass Weeds/Ice.

Summed up, again, since it was all sort of train of thought:
  • Create a Teleportation Station; use 3x3Refinery as Foundation, place a wormhole graphic over the empty part of the foundation, despite it not actually belonging to your building. Make the DockingOffset lie on the empty part of the foundation. Make it come with an invisible, but not immune, Transporter (FreeUnit - not immune because it will be a VehicleType, and thus not AirportBound).
  • Create a tile that looks like a teleportation platform and is part of either TerrainType Weeds or Ice.
  • Create a secondary building, with Prerequisite=Teleportation Station, ToTile=YourTile.
  • Limit your Transporter's movement:
    Should be as simple as MovementRestrictedTo=Weeds/Ice;
    If, for some reason, that does not work, set it to a SpeedType which has 0% on everything but the TerrainType you chose for YourTile.
    Theoretically, it should work with both normal teleportation as well as Chrono Miner's hybrid teleportation - but: If you choose normal transportation, the Transporter could jump to any Teleportation Platform on the map, regardless of whether it's next to a Teleportation Station or not. By using the Miner's hybrid engine, it would try to move by wheel if you clicked anywhere else but on another Station, and stop moving at the end of the Platform. Hence, hybrid should be preferred.
  • Make sure the unit(type)s you want to allow to enter the wormhole can move on Weeds/Ice.

Warning
There is one flaw in this: Since Station 2 would use FreeUnit as well, the second Transporter could basically "jam" that Station's DockingOffset/Platform (iow, you can't jump with Transporter 1 to Station 2, because Transporter 2 blocks the spot).
A workaround would be not to use 3x3Refinery, and place several Teleportation Platforms (with accompanying DockingOffsets on the Station) around the Teleportation Station. This would make the whole transit system a lot easier.

Theoretically, it should now work like this:
  1. You build the Teleportation Station.
  2. You build the Teleportation Platform(s).
  3. You repeat 1 & 2 at a different place
  4. You can now enter the "wormhole" at one place, select the wormhole, select a different wormhole on a different Teleportation Station, and exit there.




In all cases above, "soldiers" could also be "tanks", if the modder is so inclined. Take note of known problems with paradropping voxels, though.


Foreseeable problems
The idea relies on several unconfirmed premises:
  • If, for some reason, passengers cannot enter AircraftTypes on an airport because of something in the docking system, not because of the building below them, the system will fail. (Except for the super awesome hybrid alternative.)
  • If Nikademis is wrong, and DockingOffsets cannot be placed outside the foundation, the system will fail; this limit would have to be killed through exe-hacking or YRPP.
  • This will not work out of the box in YR 1.001; this ability would have to be re-enabled through exe-hacking or YRPP.
  • The alternative uses use invisible and potentially immune aircraft; frankly, those are a pain in the ass to hunt down and kill. If the modder sticks to the idea and doesn't allow landing elsewhere, this is no problem during transit - but I'm not sure if they properly get killed while they're docked. The reason being, usually while they're docked, if the airport explodes, you're blowing up a building below them - it's sort of normal they blow up as well. With this system, they would technically be next to the building. Since the AircraftType would not be flying, it is possibly AirportBound would not fire. So, in an extreme scenario, you would be left with an invisible, unkillable enemy unit on the map. While the unit itself could have (should have) Insignificant and/or DontScore set, if there are still units inside the transporter, the attacker would be pretty much screwed. An un-immune transporter could be found and killed, but unless the attacker finds a way to trigger the transporter to lift off, the defender is pretty much unkillable. Unhappy
  • The super-awesome alternative assumes the Transporter's target TerrainType is taken at the location of the DockingOffset; if it is taken at 0x0 or elsewhere below the building, the ground below the building will have to be covered with Transportation Platform tiles as well.


Ideas? Comments? This turned out a lot longer than expected, mainly because stuff and flags kept coming back to memory while I was typing. As said, I have no RA2/YR atm, so I can't test any of this. I would be really glad if someone did.
Maybe this has all been tried years ago and I'm way too late - I don't know. But I can say that I miss the old days where did stuff like this daily Unhappy

Just...somebody say something LOL
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#2
Very interesting, I never heard such an idea. I'll be sure to try it when I have time, and give results.
Reply
#3
There's one basic presumption that I do believe to be wrong:
Renegade Wrote:Passengers cannot step into AircraftTypes while they're docked, because there's a building below them.
As I see it (intelligent guesswork, haven't looked at the code for sure just yet), passengers cannot step into AT while they're docked because their internals say "we're docked with something", not because the cell occupied by the AT is also occupied by the dock building. I'd like to be proved wrong though.

As for the later remarks, I keep telling you that, according to Westwood's thinking, consistency is for the feeble-minded. No two functions in this game work the same way, even if it's VT docking and AT docking. Nonetheless, looking at docking is in my short term plans.

(Nitpick: YRPP is the wrong place to extend functionality, Ares is where that should happen. Same way as writing new magic functions into the DirectX SDK headers doesn't magically make the d3d.dll implement them.)

Worth playing: 1 | 2 | 3
Reply
#4
I did some testing with a 3x3Refinery foundation, and putting the DockingOffset in the blank cell. The plane refused to land after paradropping troops. Testing passengers boarding aircraft docked on a building now.

Edit: Tested. The infantry move onto the building until they're right underneath the aircraft, but refuse to enter it.
Ares Project Manager.
[Image: t3wbanner.png]
[Image: cncgsigsb_sml.png]
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
Reply
#5
(06.01.2009, 21:51:15)DCoder Wrote: (Nitpick: YRPP is the wrong place to extend functionality, Ares is where that should happen. Same way as writing new magic functions into the DirectX SDK headers doesn't magically make the d3d.dll implement them.)
Actually, I was making that difference on purpose - because I was consciously trying to imply "any DLL based on YR++", not just Ares.
After all, even though Ares is the prime enhancing DLL, nothing stops me from creating fix_the_goddamn_aircrafttypes.dll - which would not be Ares-based.

As for the docking/loading issue - would that be fixable in Ares? Just telling it "load passengers even if you're docked"? (Assuming you're guessing correctly.)

@Nighthawk: Thanks for testing so far Smile Could you test off-foundation DockingOffsets in general? Like, just taking the Airfield and setting the Offsets to 1000 in each direction or something, and see if they still work? That would answer that basic question - anything else after that is work in details.

Given that both of these problems are AircraftTypes related, has anyone tested the VehicleTypes-based theory yet?
A simple first test should be to give a Chrono Miner passenger seats instead of harvesting slots...and then see if you can properly have it jump between refineries (might lead to errors if it tries to unload the soldiers into the refinery though LOL ) [cue random technician crying "It's people! It's made out of people!!"]



Happy to see there's interest in this Smile Makes me miss the old days, though Unhappy
Nonetheless, I hope to see more random theories popping up in the future!
(Also, I'll install YR asap.)
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#6
I once played a little mod map where you were able to load passengers in to the normal miner. Altough the „Harvester without back“ (means the chrono teleporting one) didn’t have PipScale=Passengers, the infantry automatically loaded out when i sent it to the refinery (there was no pip with the amount of passenger seen).

But I’m not sure if you can load passengers into a docked miner. This needs more testing.
Reply
#7
Right, tested with the DockingOffset a couple of cells away from the building altogether. The infantry would load onto the aircraft. However, once it had paradropped the infantry, the plane refused to land again, and either would hover above its landing point, or just fly about it randomly.
Ares Project Manager.
[Image: t3wbanner.png]
[Image: cncgsigsb_sml.png]
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
Reply
#8
I told you so - the game is completely consistent in being absolutely inconsistent. Either way, thank you, that's good to know. There's data called FoundationOutline loaded with each Foundation and containing the references to the cells surrounding the actually occupied part, I guess it's tied to that somehow. Oh well, more digging for me.

Worth playing: 1 | 2 | 3
Reply
#9
More importantly, Nighthawk's description is consistent with ModEnc's description of behavior for DockingOffsets outside the Foundation (meaning, in turn, Nikademis was wrong yet again).

The guest's post is interesting...automatic unloading would be awesome. I really need to test the VehicleTypes based solution now.
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#10
Tested the Refinery-transport logic. The transport unit would only "dock" if it was set with Harvester=yes. It did automatically unload the passengers when it chronoed back to the Refinery.

However, because of the Harvester=yes line, it kept chronoing constantly between the ore field and the refinery building until I manually gave it a move order. I guess the speed of the loop was because I removed the Storage tag, as it tried to harvest for a split second before returning. But, it seems the logic won't work unless your unit can harvest ore.

Also, when built, it will behave like any other miner and automatically trundle off towards the ore fields.
Ares Project Manager.
[Image: t3wbanner.png]
[Image: cncgsigsb_sml.png]
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
Reply
#11
Hmm, well that should be prevented by the movement limitation...I will code up a working implementation of this once I have YR running.
Thank you very much for testing this Smile
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#12
Well, the miner literally teleported between the refinery and the ore field, but I'm assuming just disallowing movement on ore will prevent that? I could test it when I get home.
Ares Project Manager.
[Image: t3wbanner.png]
[Image: cncgsigsb_sml.png]
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
Reply
#13
Yeah, and there is a bug in original game (never fixed in patch) i always use for fast money in QMs

Try it out: Close a wall arround refinery and then select the miner and order it to unload in the walled refinery (while its already docked in that walled refinery). It will automatically teleport to the nearest ore...

If you build clever you can do that with just barracks, power plant and const yard instead of using walls.

Maybe that's something for your Ares patch or RP or whatever...
Reply
#14
Confirming Nighthawk and ModEnc, the aircraft wouldn't land with the offset not on the building (I put it in the empty cell of 3x3Refinery).

Okay, in the pic, the one on the right is before leaving, and the one on the left is after coming back after attacking (the stuck one).

Don't mind the pips, terrain, changed HVA on the harrier, and slaves Tongue


Attached Files Thumbnail(s)
   
Reply
#15
Thank you Smile
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply




Users browsing this thread: 1 Guest(s)