Allow placing chinook drop locations

[WheteThunger]

Server owners want the ability to place custom chinook drop locations, similar to https://umod.org/plugins/chinook-drop-randomizer.

Requirements need to be further defined.

[m-hynek]

Map makers are using assets/bundled/prefabs/modding/dropzone.prefab, I will test if it works with MA

[WheteThunger]

That prefab doesn't have a BaseEntity component so it can't be dynamically spawned. However, I believe it creates a GameObject and attaches a CH47DropZone component to it. When each CH47DropZone instance gets created, it gets added to the CH47DropZone.dropZones static list. When a CH47 wants to know where to drop the crate, it will call the CH47DropZone.GetClosest(Vector3 pos) static method.

Even though it's not an entity, the plugin could still create a GameObject and attach that component, and show debug information to represent its location. This would have to be a new type of addon, probably best suited as an internal Custom Addon (#10).

One thing we still need to do is define the use case in more detail, since I'm not sure what the user expectations would be for this. If we implement it the above way, then a chinook may choose a location that the server owner does not expect, depending on where the chinook spawns. Off the top of my head, I don't know how the chinook spawn location is decided. A good person to talk to would be ArkNerds (in RustEdit discord), since he tried to get 0x89A to create a plugin for map makers which would address this sort of use case.

[WheteThunger]

I did some more research and experimentation.

There are a handful of monuments which have built-in drop zones.

• Power plant
• Train yard
• Water treatment plant
• Airfield
• Dome

The idea with this feature is that server owners could add additional drop zones to monuments, particularly monuments not in the above list.

However, there is an issue. The CH47PathFinder uses abysmal RNG logic which tends to cause the same monuments to be visited in the same order nearly every time. To illustrate, here are the monuments on my map which are eligible to be visited by the chinook, with their corresponding indices.

launch_site_1 : 8 / 115
bandit_town : 9 / 115
compound : 10 / 115
water_treatment_plant_1 : 14 / 115
powerplant_1 : 15 / 115
airfield_1 : 16 / 115
trainyard_1 : 17 / 115
military_tunnel_1 : 18 / 115
radtown_small_3 : 19 / 115
mining_quarry_c : 20 / 115
satellite_dish : 21 / 115
stables_b : 22 / 115
mining_quarry_a : 23 / 115
sphere_tank : 24 / 115
mining_quarry_b : 25 / 115
OilrigAI2 : 112 / 115

The path finder will roll a random number between 0 and 115 (the number of monuments on that map). It will then check the monument at that index to see if it's eligible to be visited. If that monument is not eligible (which may also be the case if the monument was already visited), the path finder will check the next monument, then the next, until it finds one that is eligible. When it reaches 115, it will wrap around to 0 until it has checked a total of 115 monuments. With the above distribution, you can see that most monuments are between 8 and 25, meaning that any RNG roll between 26 and 112 will either select the oilrig or the next in the list (launch_site_1, bandit_town, etc.).

The reason I mention the path finding issue is that even if we allow server owners to add more drop zones, those drop zones won't be evenly used due to the RNG. I think we need to build a separate plugin that replaces the path finder. Fortunately, I think we simply need to subclass the CH47PathFinder class, override the GetRandomPatrolPoint() method, then replace the path finder instance of the CH47AIBrain instance any time the CH47HelicopterAIController entity spawns.

[WheteThunger]

I've created another plugin which should resolve the monument ordering. https://github.com/WheteThunger/BetterChinookPatrol

[hamilton5]

Thank you so much for putting this in! I had a problem with one of the spawns. I believe it's a height issue, I think drop zones are supposed to be raised off the ground. I had no problems with this lighthouse spawn, but at ferry terminal it would not drop here until I edited the data file manually and added +10.

[WheteThunger]

Hmm, that's a bit surprising. The CH47 code doesn't care about the height of the drop zone, only the 2D distance (in X and Z coordinates). In order for the CH47 to drop the crate, it must orbit the monument for at least 60 seconds, and have been spawned in at least 5 minutes ago. At 5 minutes, its desire to drop the crate is 0 and starts going up by 3.33/second. At 10 minutes, its desire to drop a crate is maxed at 1000. Maybe when you were testing, the times that it dropped a crate were because it visited another monument first, so it was around long enough to have a sufficient desire to drop the crate.

[hamilton5]

The 5min thing is plausible, maybe I should let it go longer and see. But I recalled these rustedit discord posts:

[WheteThunger]

I've seen such comments before, but they don't align with the code, at least not since April 2022 when I first looked into this. I recall bmgjet saying that the Rust code previously used a 3D distance check. If so, I'm not sure when it changed, but that would explain why people continue to believe height matters. My guess is that anybody who has faced this issue in the recent past was probably experiencing the 5 minute issue, and misattributed the issue to the old logic that considered 3D distance.