Porter Drone Unit ID

The Apocalyptic · 293

The Apocalyptic

  • Full Member
  • ***
    • Posts: 33
Porter Drone Unit ID
on: April 09, 2022, 06:03:06 pm
So I'm making a custom level, and it uses the AntiPorterTower in Fireswamp's port of the cw3 level Farbor to CW4, but I want it to leave certain pods alone.
Is there a way to do that?
My current attempt at a strategy for this has the AntiPorterTower target a Porter's drones, rather than the pods they carry, but I can't find out their unit ID, and it isn't on the wiki, either. Does anybody here know it?
If not, would having the AntiPorterTower ignore pods at certain coords or only destroy new pods work?



Vertu

  • Full Member
  • ***
    • Posts: 233
Re: Porter Drone Unit ID
Reply #1 on: April 09, 2022, 06:31:19 pm
The unit type of the core unit, Port Drone, is not provided (which is very annoying) and you can't just do "Porter Drone" in the UnitType. However, what you can do is check/target the pod being carried. Have a unit target the pod, then get it's ware type. Using GetUnitSettings to get the table of the pod's settings and specifically looking at the element "Resource" which works as: 0 = energy, 1 = AC, 2 = ARG, 3 = Liftic, 4 = Bluite, 5 = Redon, 6 = Greenar. Link to unit settings 4RPL CW4 wiki: http://knucklecracker.com/wiki/doku.php?id=4rpl:commands:getunitsettings#tab__pod

It is very unfortunate that the "sub-units" of main units aren't provided in the Core Unit Types and again, you can't just look at the name of the unit from the Creeper graph log such as "Porter Drone" and use that.
The pod isn't a sub unit but an actual other unit, hence why we can place Pods on their own in the editor and how they "land" and are used.
The pod mid-travel is very much still a normal pod except it is unselectable and all that other stuff. My Light SAM in VPAC did target flying Pods until they landed as it's listN of exceptions had the wrong number of assigned elements for the list. The Light SAM looked for units and if they had the status "OccupiesLand" set to false, is something that can be targeted if it's not in the listN of exceptions.

Life isn't fair because we say it isn't. Not because it is unfair. In fact, it is so fair we want to say it isn't and do.


The Apocalyptic

  • Full Member
  • ***
    • Posts: 33
Re: Porter Drone Unit ID
Reply #2 on: April 09, 2022, 06:40:10 pm
Yet your port of Particulate from Particle Fleet can destroy terp drones without affecting the main unit, and both the AC and regular bombers are considered separate units from their pads, which do have unit IDs. That, and your light SAM in the VPAC can target Greenar Drones.



Vertu

  • Full Member
  • ***
    • Posts: 233
Re: Porter Drone Unit ID
Reply #3 on: April 09, 2022, 06:42:23 pm
Yes but I can't make it stop doing so. I can't add "Porter Drone" to the list of exceptions as it's not the actual UnitType of the Porter Drone. They are only targetable because they are not impervious and don't occupy land as I made the targeting with the optimal code of being generalized. If something does not occupy land, it can be targeted by the Light SAM. There for, you can make any air unit and it will still be compatible with the SAM because dear lord, a white list will be FAR too long.

If I was able to do something about this, I would of included things like "Terp Drone" in the blacklist and "Bomber" as the SAM was originally meant to deal with only my VAUs.
« Last Edit: April 09, 2022, 06:44:03 pm by Vertu »

Life isn't fair because we say it isn't. Not because it is unfair. In fact, it is so fair we want to say it isn't and do.


The Apocalyptic

  • Full Member
  • ***
    • Posts: 33
Re: Porter Drone Unit ID
Reply #4 on: April 09, 2022, 06:50:25 pm
In that case, may I adapt some of the code you used there?



knucracker

  • Administrator
  • *****
    • Posts: 11794
Re: Porter Drone Unit ID
Reply #5 on: April 09, 2022, 07:02:44 pm
It does look like I left out the porter's drone from the unit definition table.  There was either some issue, or it was just an oversight. Not being in the unit list means that 'GetUnitType' will return an empty string for the porter drone.  However, GetUnitOfficialName might still work.  If it does, it will return "DeliveryDrone".  So _if_ doing something like GetUnitsInRange returns the Porter drone, then GetOfficialName would be one way to check if the unit is a Porter Drone.  If GetUnitsInRange doesn't return the Porter Drone, then yeah.... bigger problem.  Looking at the pods is a clever solution.



Vertu

  • Full Member
  • ***
    • Posts: 233
Re: Porter Drone Unit ID
Reply #6 on: April 09, 2022, 07:06:40 pm
Earlier after being placed and activated:
Code: [Select]
GetUnitPosition(self) ->PACpos
Code: [Select]
GetUnits("" <-PACpos GetUnitRange(self) false false true 2 1 1) ->enemies
Concat3("Found enemies: " GetListCount(<-enemies) "<br>") ->debugText[3]
if(GetListCount(<-enemies) gt0)
clearList(<-targets) #Refresh to update our potential targets.
0 ->count
do(GetListCount(<-enemies) 0)
#Search through all units in range to see if they can be targeted and create a list of targets.
GetUnitPosition(<-enemies[I]) ->ePos
<-ePos.y <-PACpos.y - ->difference
GetTerrainLOS(<-PACpos <-ePos true) ->hitPos
if(GetUnitOccupiesLand(<-enemies[I]) ! ListContains(<-unwanted GetUnitType(<-enemies[I])) ! && <-difference lte(<-MAX_TARGET_LOCKABLE_HEIGHT_DIFFERANCE) && <-hitPos.x lt0 &&)
<-enemies[I] ->targets[<-count]
<-count 1 + ->count
endif
loop
Concat3("Found Targets: " GetListCount(<-targets) "<br>") ->debugText[4]
else
ClearList(<-enemies)
endif

Also yeah. Things like the TerpDrone and GreenarDrone are not in the list of core unit types.
Only the TerpDrone and GreenarDrone are not replaced if destroyed, leaving the Terp and Refinery unusable. The rest either self-destruct or replace the drone but it would still be useful to have the list of all core units, including such "sub units".

I might try the GetUnitOfficialName though. It might work very well.
« Last Edit: April 09, 2022, 07:08:18 pm by Vertu »

Life isn't fair because we say it isn't. Not because it is unfair. In fact, it is so fair we want to say it isn't and do.


The Apocalyptic

  • Full Member
  • ***
    • Posts: 33
Re: Porter Drone Unit ID
Reply #7 on: April 09, 2022, 08:23:39 pm
You may want to fix the irreplacability issues with the terp and refinery, Knucracker.

Anyways, it just occurred to me that it may be possible to restrict the unit I wish to edit to only alter target pods above a certain elevation. About how high does a deliverydrone fly above level terrain, assuming no creeper?



Vertu

  • Full Member
  • ***
    • Posts: 233
Re: Porter Drone Unit ID
Reply #8 on: April 09, 2022, 09:05:59 pm
You may want to fix the irreplacability issues with the terp and refinery, Knucracker.

Anyways, it just occurred to me that it may be possible to restrict the unit I wish to edit to only alter target pods above a certain elevation. About how high does a deliverydrone fly above level terrain, assuming no creeper?
It uses the MoveTowardsAndAvoid API at least in behavior so it actually has no limit. When it goes higher it stays at that new height. I think it auto flies to a height of 30 so it should be less about that and more about your original intent to target only specific pod types.

Life isn't fair because we say it isn't. Not because it is unfair. In fact, it is so fair we want to say it isn't and do.


The Apocalyptic

  • Full Member
  • ***
    • Posts: 33
Re: Porter Drone Unit ID
Reply #9 on: April 11, 2022, 12:07:18 pm
The type of pod in question is "Not present at start of level."

Anyways, I would need to know how tall an average pod is. The Y coordinate is determined by the base of the unit, correct?
« Last Edit: April 11, 2022, 12:13:22 pm by The Apocalyptic »



The Apocalyptic

  • Full Member
  • ***
    • Posts: 33
Re: Porter Drone Unit ID
Reply #10 on: April 11, 2022, 12:27:02 pm
I decided to just check for the impervious status. Fortunately, there is an easy way to do that with 4rpl.
Quote
GetUnits
GetUnits(<-unitType <-startPos <-range <-isSquare <-is3D <-requireLOS <-enemyState <-builtState <-imperviousState) ->units

Description
Returns list of units in range of a given position. The returned list is sorted so that the first item in the list is the closest.
unitType:
a string indicating the unit type1) to return. If empty string (), then all units are searched.
startPos:
a V3 (vector3) indicating the point to search outwards from.
range:
a floating point number that is the maximum distance from startPos.
isSquare:
a boolean. It means to check in a square rather than a circle around startPos. For 3D checks, the vertical displacement is also checked (so the range is effectivly a cube rather than a sphere).
is3D:
a boolean. It determines if a true 3d distance is used for range, or if only the X and Z components (2D) distance calculation is used.
requireLOS:
a boolean indicating if terrain line of sight is required.
enemyState:
an int (either 0,1,2). 0 = ignore enemy status. 1 = Only find units that are enemies. 2 = Only find units that are not enemies.
builtState:
an int (either 0,1,2). 0 = ignore built state. 1 = Only find units that are built. 2 = Only find units that are not built.
imperviousState:
an int (either 0,1,2). 0 = ignore impervious state. 1 = Only find units that are not impervious. 2 = Only find units that are impervious. Things like ore deposits are impervious.
Specifically, the bolded portion.