![]() Road vehicles have only 3 generations, and each vehicle has only 1 successor or predecessor model. ![]() I know that implementing this for trains, ships and aicrafts is not very straightforward, so let's focus on road vehicles only. This is an impossible task to do manually, and breakdowns on these obsolete vehicles render the company nonviable. Sounds easy when you have a few dozens road vehicles, but it's not fun when you have hundredths of vehicles. With the current scheme, we have to manually replace road vehicles to their newer models. It would be really useful to add an option to autorenew road vehicles to their newer/faster model either: When a road vehicle is getting old but it's one of the old models that then becomes unavailable, it never gets replaced. finished loading/unloading, reached a waypoint. only send a vehicle to a depot when it has just completed another order, e.g. some default constant if service_interval = 0).Ĭ) Add some other constraint. a certain number of days since last service (e.g. or 4., so maybe some money rule would be enough)ī) Add some time constraint to checking for sending a vehicle to a depot for autoreplace. Ī) Remove automatic sending vehicles to depot when autoreplace/renew is set. IMO there is no reasonable way to check 4. new vehicle not refitable to the needed cargo, newgrf restrictions, length restrictions. The vehicle is send to depot, even when autoreplace will fail anyway. (though there might be, when it reaches depot)Ĥ. The vehicle is send to depot, even if there is not enough money for the replacement. Vehicle::NeedsAutomaticServicing() does not test wagons for autoreplacement rules.ģ. No matter whether the vehicle was just serviced.Ģ. Vehicle::NeedsAutomaticServicing() sends engines to depot when an autoreplacement rule is set for them. ![]() The aircraft lands, goes to the terminal, gets paid (thus crossing the money boundary), and at that moment, a new day has to be activated.)ġ. (with the autorenew2.patch file, the above bug is triggerable by settng up a replacement for an aircraft, and borrowing just too little money to get the replacement active (you need 'auto-renew-money + 2 * cost-of-new-engine'). I have not further explored that solution.Īttached you can find the additional fix, and an updated version of autorenew2.patch (now against r12225) in autorenew3.patch. The fix for this problem that I implemented is to also detach the vehicle from the station data structures in CheckIfAircraftNeedsService() by adding a call to v->LeaveStation().Īn alternative solution could be a more careful selection which vehicle to exchange goods with. At line 1558 "assert(v->current_order.type = OT_LOADING)" is performed, which fails, since we just decided for the aircraft that it needs service. This function calls LoadUnloadVehicle() (line 1556) for vehicles in the station 'loading_vehicles' list. This makes a call to CallVehicleTicks() (vehicle.cpp, line 740), which does goods exchanging through LoadUnloadStation() (economy.cpp, line 1799). Two lines later in the game-loop, vehicles are handled. In particular, the aircraft is not uncoupled from the station 'loading_vehicles' list. If at that point, the need for maintenance is detected, the order is changed to OT_GOTO_DEPOT. If a new day is detected, v->OnNewDay() is executed, which for an aircraft, results in a call to CheckIfAircraftNeedsService() (aircraft_cmd.cpp, line 711). ![]() In the StateGameLoop() (openttd.cpp, line 977), the date is increased (line 1003, and vehicles are handled line 1005). Not sure whether my patch was the cause or just the trigger I suspect the latter.Īn aircraft at a terminal is tied to the station by means of the st->loading_vehicles list while exchanging goods/passengers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |