Autodrive

by Pi-C

Car equipment for train avoidance, logistic network integration, circuit network connectivity, fuel refill, ammo reload, vehicle repair, radio control, enemy targeting, and gate control.

Content
2 months ago
0.17 - 1.1
2.98K
Transportation Combat Logistic network Circuit network

i [Implemented?] Toggle trash

1 year, 2 months ago

Please make a toggle to enable/disable trashing of unfiltered slots

1 year, 2 months ago

Just to make sure I understand you correctly: If a vehicle has is equipped with a logistic sensor, filtered slots will be requests while things in unfiltered slots will be taken away by bots (the mod actually creates an invisible requester and an invisible active-provider chest on top of the vehicle). You suggest that I add a switch to turn off the active provider, similar to the switch for toggling requests from buffer chests. Is that correct?

1 year, 2 months ago

Yes, my stuff gets trashed to random storage chests

1 year, 2 months ago

I'm almost ready for release (Yes, that's what I've been telling myself for the past month or so!), and your suggestion is not trivial (checking the state of a button is, but I don't want to mess with the GUI right now). I won't add this for the next release, but after that one is out, I'll start working on it.

Actually, toggling installed sensors already is on my todo list. Just needs some thinking about how to build the interface. Adding a button for every sensor would be simple, but then you'd have a GUI with very long lines -- not optimal. What would you think about replacing the current switch for "Request from buffer chests" with a button "Sensors" that would open a relative GUI placed at the right of the main one: a table where the first (or only) button in each line toggles the sensor (e.g. turn off Enemy sensor or Repair sensor). Additional buttons could be placed to the right of it to toggle features related to the sensor (e.g. Request from buffer chests, Toggle requester, and Toggle provider next to the button for the logistic sensor). The sensors GUI would only ever be shown for one vehicle, so if you have opened the sensors' GUI of one vehicle and click the button of another vehicle, that would turn off the button of the first vehicle and update the relative GUI with the sensors of the second vehicle.

Do you think that makes sense?

1 year, 2 months ago

Not GUI expert :) but i think accordion approach is great. As for table, some sensors are just on/off... so you will waste a lot of space, maybe group those in one row and more complex in separate rows...just an idea to think about

1 year, 2 months ago

As for table, some sensors are just on/off... so you will waste a lot of space, maybe group those in one row and more complex in separate rows...

Programmatically, it could be easier to use one line per sensor (e.g., additional buttons could be stored in a table with the sensor). Also, while keeping simple sensors in one row may save space, it could be confusing: If for complex sensors the first button signified the sensor and any subsequent buttons an additional function related to that sensor, players might be inclined to read the line with the simple sensors in the same way. Perhaps the different meaning could be more clear by using different types of GUI elements (e.g. sprite buttons for the sensors and a sprite next to a checkbox for the additional functions).

Anyway, that certainly will take some time. It's not just getting the new GUI to work, it must also interact with the main GUI and different events …

5 months ago

Some time ago, I've added buttons to the GUI for enabling/disabling the enemy and logistics sensor (the buttons won't work if the respective sensor is not in the grid). Is that acceptable?

New response