AIVehicle.VehicleType and AITile.TransportType confusions

[Xander]

So I'm at the point where I'm trying to replaced a crashed vehicle and I noticed a bit of... awkward duplication. When I want to build the AIDepotList I have to use AITile.TransportType, but surely it'd make more sense to use AIVehicle.VehicleType? I can't imagine many cases where you'd be looking for the depots without a Vehicles information stored somewhere.

At the minute I'm having to switch statement it to translate between the two but if something could be done API side that'd be awesome

Or maybe it's something else for the Common.Library?

[fanioz]

My vehicle has a goto depot order. And I extract information from there. Or you didn't like this approach?

[Xander]

My vehicle has a goto depot order. And I extract information from there. Or you didn't like this approach?

It's not ideal as my vehicles don't have goto depot orders.

[fanioz]

AIRoad.IsRoadDepotTile.
AIRail.IsRailDepotTile.
AIAirport.IsHangarTile.
AIMarine.IsWaterDepotTile.
Are theese, still not enouh to valuate an AIDepotList ? Or you mean something else?

[Xander]

That's not what I'm trying to do. I want to establish which depot type I should be looking for, given a vehicleID (as in when a vehicle crashes).

Code: Select all

function Engineer::ReplaceVehicle(vehicleid){
	AILog.Info("ENGINEER: Replacing vehicle " + vehicleid);
	
	local depotlist = null;
	
	switch(AIVehicle.GetVehicleType(vehicleid)){
		case AIVehicle.VT_ROAD:
			depotlist = AIDepotList(AITile.TRANSPORT_ROAD);
			break;
		default:
			AILog.Warning("ENGINEER: I can't handle this kind of vehicle");
			return false;
			break;
	}
	//Find the nearest depot to the vehicles starting station
	depotlist.Valuate(AIMap.DistanceManhattan, AIOrder.GetOrderDestination(vehicleid, 0));
	depotlist.KeepBottom(1);
	AIVehicle.StartStopVehicle(AIVehicle.CloneVehicle(depotlist.Begin(), vehicleid, true));
}

It would be nice if the switch statement wasn't needed and I could go straight to

Code: Select all

depotlist = AIDepotList(AIVehice.GetVehicleType(vehicleID));

EDIT: As I said, it's not critical, it's just a Like-to-have

[Dustin]

So I'm at the point where I'm trying to replaced a crashed vehicle and I noticed a bit of... awkward duplication. When I want to build the AIDepotList I have to use AITile.TransportType, but surely it'd make more sense to use AIVehicle.VehicleType? I can't imagine many cases where you'd be looking for the depots without a Vehicles information stored somewhere.

At the minute I'm having to switch statement it to translate between the two but if something could be done API side that'd be awesome

Or maybe it's something else for the Common.Library?

How does you AI crash vehicles in the first place? I don't think mine ever managed it.

[Xander]

How does you AI crash vehicles in the first place? I don't think mine ever managed it.

Your AI won't but other players will with their trains...

[Dustin]

How does you AI crash vehicles in the first place? I don't think mine ever managed it.

Your AI won't but other players will with their trains...

Explain? Do you mean players are using exploits to crash the AI's trains? Or do you mean you are playing as the same player and you make an error that crashes trains?

[Xander]

How does you AI crash vehicles in the first place? I don't think mine ever managed it.

Your AI won't but other players will with their trains...

Explain? Do you mean players are using exploits to crash the AI's trains? Or do you mean you are playing as the same player and you make an error that crashes trains?

No. I mean using the old "run a train over a road as a vehicle goes over it" crash.

[Abenhor]

That's not what I'm trying to do. I want to establish which depot type I should be looking for, given a vehicleID (as in when a vehicle crashes).
It would be nice if the switch statement wasn't needed and I could go straight to

Code: Select all

depotlist = AIDepotList(AIVehice.GetVehicleType(vehicleID));

I think you can, as things are for now, but maybe a developer would say what is planned for the future...