Does it make sense that I drive "through" a tree that is destroyed but my tank bounces off a rock even if the rock is destroyed. If the tank is already at full speed at the time of the collision it bounces back a long ways too!

Does it make sense that I drive "through" a tree that is destroyed but my tank bounces off a rock even if the rock is destroyed.

Tree collisions are handled separately from collisions with all other entities because tree collisions can (depending on setting "autodrive-tree-collision-heals") restore health to vehicles on collision. (I know that this doesn't make sense as tree collisions would leave a dent on a car in RL, but it seemed to make sense game wise, when a player was on the steering wheel.)

I probably should make sure that vehicles will only bounce off entities that still have health points left after the collision, and resume driving at reduced speed if the entity has been destroyed.

If the tank is already at full speed at the time of the collision it bounces back a long ways too!

I've noticed that vanilla cars hitting heavy vehicles (e.g. trains) at high speed would bounce way too far until they come to a full stop. Therefore, I've limited the bouncing period to 60 ticks (1 s) and gradually reduce the bouncing speed on each tick so that vehicles will stop after that time regardless of their original speed. Naturally, vehicles moving at full speed will cover more ground in that time …

https://i.imgur.com/n6PX9ca.png
Hit the rock that was in the green circle... it broke into "stone" . Rock was same as one in the red circle.
Bounced back to the position tank is in the photo.

Another thing I'm seeing is that sometimes the vehicle isnt responsible to turn keys when plowing through trees... not 100% sure thats an autodrive thing.

If it matters.. playing IR3 at the moment. Tank is fairly vanilla

I think... if there was a way to toggle all of the bounce/heal on tree hit/accelerate after hitting tree... all of it off for manually driven vehicles, that would be good.

IR3 has tiers of repair packs. with the Iron packs, and the level 3 auto-repair I can pretty much sit in the middle of a big biter nest getting soaked in spit and the tankdrops to basically 0 HP but wont die unless I run out of repair packs.

Another thing I'm seeing is that sometimes the vehicle isnt responsible to turn keys when plowing through trees... not 100% sure thats an autodrive thing.

It is an Autodrive thing. We tell a car to accelerate, reverse, brake, or coast along, by setting its riding_state, which is a table with values for acceleration and direction. The paths we get are a series of straight path segments, and we rotate cars into the right direction before entering a segment. Therefore, we set the direction of cars in autodrive mode to defines.riding.direction.straight.

So when is a car in autodrive mode? Naturally, when it is following a path. But Autodrive will also take over control of cars while they are bouncing (60 ticks), steamrolling trees, spawners etc. (30 ticks), or panicking.

It would be possible to set direction only if the car is following a path. In this case, it is essential that the car is moving in a straight direction because it might never get to the next way point if the driver diverted from the assigned course. Alternatively, I could allow players in the driver seat to change the direction of a car in autodrive mode, but that would require to delete the path and switch over to manual driving. Would that be OK?

Thanks for responding on this and please understand that in general I LOVE this mod.. it has brought back the joy of vehicle use to the game and let me banish the cheesy grapling gun and jetpack mods!

My questions and discussion here are are all about manual driving mode. Most of the functionality you describe makes a ton of sense for autodrive.

I would think you'd want to have a very light impact on vehicle control when it's being manually driven?

If not on a path and not "bouncing" don't do anything?
Don't bounce off anything that you destroyed by hitting.. rocks, trees....
It Seems like you are bouncing off (and autorepairing?) walls, pipes and power poles which is great.. possibly all player placed entities? Agreed... wrecking power poles by accident with the tank is annoying.

The accelerate while manually steamrolling trees/rocks/spawners is unnecessary because the player will have a finger down on the W key already. Are you saying also that the panic mode and/or possibly train sensor is active while manually driving? Perhaps unnecessary?

If I'm out in the tank driving around clearing biter nests, the only "help" Id like would be
- Bounce of any rock/tree that I don't break but maybe not bounce like half a kilometer :P
- Reload - Maybe a message indicating remaining rounds with each reload or when down to half a stack left?
- Refuel - Maybe a message indicating remaining fuel items with each refuel or when down to half a stack left?

Anything that locks me out of directional or speed control while things are going well is not helping. If the T3 repair equipment combined with the crazy repair packs in this IR3 mod I'm playing didn't add up to "invincible" it would be resulting in deaths.

Now to your last question.... near as we could tell, the only way to cancel a path is to go into map mode and issue a different path.... maybe I missed a hotkey or something? IF I'm trucking along in the wilderness in the car and stumble into a giant biter nest that was not showing up on the radar when I set the path, its a bit of a panic! Hard to cancel the path in that situation eh? Particularly if enjoying a beverage while letting this clever mod do all the driving. Allowing a manual direction input or deceleration to cancel the path would work.. also you could put "cancel path" on a hotkey that defaults to "s" key. That way it would be like how in a real car we cancel the cruse control by tapping the brake pedal!
-

Thanks for responding on this and please understand that in general I LOVE this mod.. it has brought back the joy of vehicle use to the game and let me banish the cheesy grapling gun and jetpack mods!

Nice to read that! :-)

I would think you'd want to have a very light impact on vehicle control when it's being manually driven?

If not on a path and not "bouncing" don't do anything?
Don't bounce off anything that you destroyed by hitting.. rocks, trees....

Made it so for the next version.

The accelerate while manually steamrolling trees/rocks/spawners is unnecessary because the player will have a finger down on the W key already.

In the next version, vehicles that are on the GUI will steamroll trees, units, worms, and spawners -- whether they have a path or not. However, changes to speed or direction will be considered, (starting at the second tick after the crash, i.e. one tick after steamrolling has been initialized). If a vehicle has crashed with entities of other types that belong to another force, it will bounce if the entity has survived, or continue moving in its original direction but gradually slow down.

Are you saying also that the panic mode and/or possibly train sensor is active while manually driving? Perhaps unnecessary?

Yes, but that was a thinko. Vehicles must be controlled by Autodrive in order to get their sensors checked, and they must have train or enemy sensor installed to enter panic mode. So vehicles that are not on a GUI will only be in autodrive mode when they are bouncing.

If I'm out in the tank driving around clearing biter nests, the only "help" Id like would be
- Bounce of any rock/tree that I don't break but maybe not bounce like half a kilometer :P

Should be fixed in the next version.

• Reload - Maybe a message indicating remaining rounds with each reload or when down to half a stack left?
• Refuel - Maybe a message indicating remaining fuel items with each refuel or when down to half a stack left?

I'm not quite sure I understand:

• Does "remaining rounds/fuel" refer to ammo/fuel in the currently used ammo/fuel inventory slot? That wouldn't make sense as there is an edge case for fuel if the vehicle is consuming the last piece of fuel from a fuel inventory slot, so the current fuel slot is empty but there still may be fuel left in one of the other slots. (We only reload/refuel if all slots in the ammo/fuel inventory are empty and the vehicle isn't consuming anything.)

• Does "with each reload/refuel" refer to each time we check the ammo/fuel? That happens every 180 ticks (3 seconds) for ammo and every 360 ticks (6 seconds) for fuel. Wouldn't that spam too many messages?

Now to your last question.... near as we could tell, the only way to cancel a path is to go into map mode and issue a different path.... maybe I missed a hotkey or something?

You can cancel a path by using the vehicle's stop button on the GUI.

IF I'm trucking along in the wilderness in the car and stumble into a giant biter nest that was not showing up on the radar when I set the path, its a bit of a panic! Hard to cancel the path in that situation eh? Particularly if enjoying a beverage while letting this clever mod do all the driving. Allowing a manual direction input or deceleration to cancel the path would work..

In the next version, changing speed will cancel bouncing (accelerate if you're bouncing backwards, or brake if you're bouncing forwards), and changing direction will cancel the path.

also you could put "cancel path" on a hotkey that defaults to "s" key. That way it would be like how in a real car we cancel the cruse control by tapping the brake pedal!

I'll think about that … :-)

also you could put "cancel path" on a hotkey that defaults to "s" key. That way it would be like how in a real car we cancel the cruse control by tapping the brake pedal!

I'll think about that … :-)

I've tried it out. While it does seem to be convenient to link the custom-input to the "move down"-key, the related event would trigger each time a player used that key. This would happen when the player was in a vehicle, but also each time a player was walking southwards, so the event would be triggered unnecessarily a lot, which is bad for UPS.

I'm therefore reluctant to use the "move-down" key PER DEFAULT as hotkey for cancelling cruis control. However, I've added an undefined hotkey that you must set yourself (Main menu --> Settings --> Controls) before it can be used.

There is another undefined hotkey for emergencies which will also cancel the path, but additionally it will stop the vehicle. While only the driver of a vehicle may use the hotkey for cancelling the path, the hotkey for emergency stops can be used by the passenger as well.

I've tried it out. While it does seem to be convenient to link the custom-input to the "move down"-key, the related event would trigger each time a player used that key. This would happen when the player was in a vehicle, but also each time a player was walking southwards, so the event would be triggered unnecessarily a lot, which is bad for UPS.

Good point.. particularly on a key that we'd be holding down frequently rather than occasional press.

I'm not quite sure I understand:

• Does "remaining rounds/fuel" refer to ammo/fuel in the currently used ammo/fuel inventory slot? That wouldn't make sense as there is an edge case for fuel if the vehicle is consuming the last piece of fuel from a fuel inventory slot, so the current fuel slot is empty but there still may be fuel left in one of the other slots. (We only reload/refuel if all slots in the ammo/fuel inventory are empty and the vehicle isn't consuming anything.)

Didnt realise you let it get that close to out of fuel before refueling. The premise is a warning when getting low on fuel, perhaps a half stack including fuel slots and vehicle inventory combined Or a half stack in the fuel slots and the vehicle trunk empty.

• Does "with each reload/refuel" refer to each time we check the ammo/fuel? That happens every 180 ticks (3 seconds) for ammo and every 360 ticks (6 seconds) for fuel. Wouldn't that spam too many messages?

Another thought might be to check this during the refueling operation? As in if you fuel from the trunk and THIS is the operation that empties the trunk of fuel and now you just have the fuel in the fuel slots.. one warning "Trunk fuel/ammo depleted" this would leave you kind of treating the trunk as the main fuel tank and the fuel slots as the fuel reserve.. and you are warning when only the reserve remains.

I'm done IR3 now... and into a Nullius run... just got my car 46 hours in.

The premise is a warning when getting low on fuel, perhaps a half stack including fuel slots and vehicle inventory combined Or a half stack in the fuel slots and the vehicle trunk empty.

I don't keep track of what's in the trunk. When the vehicle has to be refueled, I loop over the items returned by LuaInventory::get_contents() for the trunk (which returns the total amount of each item) and try to insert the item. If something was inserted, that may have filled one or more or even all slots (e.g. if there are 500 coal items in the trunk but the fuel inventory has only 3 slots). So I check LuaInventory::is_full() for the ammo/fuel inventory and try to insert the next item unless all ammo/fuel slots are blocked (i.e. each slot contains at least 1 item).

In this light, it's probably more efficient to output a warning when the trunk is empty.
(Note to myself: We could store accepted ammo/fuel items with vehicle prototype data to possibly speed up the search for ammo/fuel items. Then we also could output the warning if the trunk is not empty but doesn't contain any of the required items.)

I've already restructured data so that in on_init/on_configuration_changed we will store ammo and fuel categories with all the ammo/fuel item prototypes. When storing the gun (all gun item that are used in at least one of the supported vehicle prototypes) and equipment prototypes, we also keep track of the ammo/fuel items that can be used with them. Data of the vehicle prototypes now include a list of all accepted ammo/fuel items. This makes the code for refueling and reloading more efficient because we don't have to check for all items in the trunk whether they can be inserted into the fuel/ammo, but can look for just the accepted items stored with the vehicle prototype.

I've also moved data of fuelable equipment from the vehicle data to grid data because these are static most of the time, so we now only update the list of installed equipment when equipment items are added to or removed from the grid. Currently, I'm working on doing the same thing for installed sensors -- where the gain should be even bigger because we used to rebuild the sensor list each time a vehicle was reset (e.g. after arriving at its destination). But while this was simple for fuelable equipment, there are far more occurences of references to sensors in the code, so there's a good chance that some errors may sneak in. :-)

one warning "Trunk fuel/ammo depleted" this would leave you kind of treating the trunk as the main fuel tank and the fuel slots as the fuel reserve.. and you are warning when only the reserve remains.

Regarding ammo reloading: Should I print a warning when there is no ammo for one of the guns, or only if no gun can be reloaded? (For example, bullets couldn't be used to reload the vanilla tank's flamethrower, but if there are bullets in the trunk you still could use the tank machine gun.)

Regarding refueling: We first try to refuel the vehicle. Thereafter, we check each fuelable equipment item installed in the vehicle grid and try to refuel those. Let's say you have 2 miniature reactors from IR3, but there's only enough fuel cells for one of them. Should that raise a warning, too?

Also, in what manner should the warning be displayed? While I probably could compile a list of all equipment items for which there is no fuel, there may be a number of different equipment items, so the message could become quite long. That may pose a problem because line breaks are ignored in flying text. Perhaps use force.print() to write a chat message to all players on the same force as the vehicle, or show an alert?

How often should a warning be printed? We check ammo/fuel every 3secs /6secs, so issuing a warning each time would result in incredible spam. What delay would you suggest?

Interesting! Does Nullius have any vehicles or grid equipment items where remains of used fuel must be removed (like the "Heavy Picket" from IR3)? It would be great for testing the changes to refueling. Of course, I'm also interested in problems specific to Nullius. I've already taken care of making my prototypes compatible, but only testing in a real game can reveal mistakes. :-)

Happy to go back and re-test my IR3 issues with the next version of Autodrive.

No idea on Nullius, just have the car so far. Couldn't craft the remote... see my recent post on that one. There is no biters though.. and no trees!

Please try version 1.1.13!

Posted some nullius testing...

The premise is a warning when getting low on fuel, perhaps a half stack including fuel slots and vehicle inventory combined Or a half stack in the fuel slots and the vehicle trunk empty.

I don't keep track of what's in the trunk. When the vehicle has to be refueled, I loop over the items returned by LuaInventory::get_contents() for the trunk (which returns the total amount of each item) and try to insert the item. If something was inserted, that may have filled one or more or even all slots (e.g. if there are 500 coal items in the trunk but the fuel inventory has only 3 slots). So I check LuaInventory::is_full() for the ammo/fuel inventory and try to insert the next item unless all ammo/fuel slots are blocked (i.e. each slot contains at least 1 item).

In this light, it's probably more efficient to output a warning when the trunk is empty.
(Note to myself: We could store accepted ammo/fuel items with vehicle prototype data to possibly speed up the search for ammo/fuel items. Then we also could output the warning if the trunk is not empty but doesn't contain any of the required items.)

I've already restructured data so that in on_init/on_configuration_changed we will store ammo and fuel categories with all the ammo/fuel item prototypes. When storing the gun (all gun item that are used in at least one of the supported vehicle prototypes) and equipment prototypes, we also keep track of the ammo/fuel items that can be used with them. Data of the vehicle prototypes now include a list of all accepted ammo/fuel items. This makes the code for refueling and reloading more efficient because we don't have to check for all items in the trunk whether they can be inserted into the fuel/ammo, but can look for just the accepted items stored with the vehicle prototype.

I've also moved data of fuelable equipment from the vehicle data to grid data because these are static most of the time, so we now only update the list of installed equipment when equipment items are added to or removed from the grid. Currently, I'm working on doing the same thing for installed sensors -- where the gain should be even bigger because we used to rebuild the sensor list each time a vehicle was reset (e.g. after arriving at its destination). But while this was simple for fuelable equipment, there are far more occurences of references to sensors in the code, so there's a good chance that some errors may sneak in. :-)

one warning "Trunk fuel/ammo depleted" this would leave you kind of treating the trunk as the main fuel tank and the fuel slots as the fuel reserve.. and you are warning when only the reserve remains.

Regarding ammo reloading: Should I print a warning when there is no ammo for one of the guns, or only if no gun can be reloaded? (For example, bullets couldn't be used to reload the vanilla tank's flamethrower, but if there are bullets in the trunk you still could use the tank machine gun.)

Regarding refueling: We first try to refuel the vehicle. Thereafter, we check each fuelable equipment item installed in the vehicle grid and try to refuel those. Let's say you have 2 miniature reactors from IR3, but there's only enough fuel cells for one of them. Should that raise a warning, too?

Also, in what manner should the warning be displayed? While I probably could compile a list of all equipment items for which there is no fuel, there may be a number of different equipment items, so the message could become quite long. That may pose a problem because line breaks are ignored in flying text. Perhaps use force.print() to write a chat message to all players on the same force as the vehicle, or show an alert?

How often should a warning be printed? We check ammo/fuel every 3secs /6secs, so issuing a warning each time would result in incredible spam. What delay would you suggest?

IR3 has tiers of repair packs. with the Iron packs, and the level 3 auto-repair I can pretty much sit in the middle of a big biter nest getting soaked in spit and the tankdrops to basically 0 HP but wont die unless I run out of repair packs.

I've noticed something like that the other day when I wanted to kill a vehicle for testing purposes by pumping a stack of rockets into it. It seems cheaty that a couple of stacks of even the most basic repair packs + repair sensor 1 make vehicles virtually invincible.

The original idea was that if a vehicle is hit, it will get a chance to survive if it can get to >0 health by repairs. If the vehicle starts with 10 HP and takes a damage of 12 HP, on_entity_damaged should show its final health as -2 HP, so if it's repaired with a tier-3 repair sensor it would likely get to >0 HP and have a slight chance of surviving the next tick (thus giving an incentive to use the best repair packs with the best repair sensor). But if it was killed by a nuke and final_health went way down below 0 so that even immediate repairs wouldn't restore it to >0 HP, the vehicle was clearly meant to die.

However, on_entity_damaged puts a lower limit of 0 on event.entity.health. Thus, re-adding even the tiniest amount health will revive a dead vehicle. Unless we get an API change that allows for negative health, the closest I can come to implement my original idea is this change:

Before:

• In on_entity_damaged, call repair function and set flag indicating that vehicle must be repaired.
• In on_tick, call repair function if the flag is set.

After:

• In on_entity_damaged (if event.entity.health > 0), call repair function and set flag indicating that vehicle must be repaired.
• In on_entity_damaged (if event.entity.health == 0), don't do anything. (Vehicle will die.)
• In on_tick, call repair function if the vehicle still exists and flag is set.

Please try version 1.1.15!

Didnt realise you let it get that close to out of fuel before refueling. The premise is a warning when getting low on fuel, perhaps a half stack including fuel slots and vehicle inventory combined Or a half stack in the fuel slots and the vehicle trunk empty.

Another thought might be to check this during the refueling operation? As in if you fuel from the trunk and THIS is the operation that empties the trunk of fuel and now you just have the fuel in the fuel slots.. one warning "Trunk fuel/ammo depleted" this would leave you kind of treating the trunk as the main fuel tank and the fuel slots as the fuel reserve.. and you are warning when only the reserve remains.

Check out version 1.1.16! I've added a GUI for preferred items to be used when ammo, fuel, or repair sensor are installed. You'll get an alert if there are not enough full stacks of first-choice items in the trunk (clear textfield for alert thresholds or enter 0 to disable alerts). Additionally, you can set a number of stacks to be requested for the vehicle's consumption (fuel: vheicle + equipment) if the vehicle has an active logistic sensor. These requests are independent of normal requests set by filtering trunk slots, and have a higher priority.

Besides first-choice items you can also select two alternative preferences. Vehicles will use these if no first-choice item has been set or if there is no first-choice item in the trunk. When the trunk contains neither first-choice nor preferred items, the vehicle will fall back to the first other usable item found in the trunk.