[MOD 0.14] AAI Programmable Vehicles

[Seldion]

So I use your mod to basically do mid game bitter spawn control to keep them from getting to close to my base and some times I send them on "raiding" party to collect some artifacts because a mod of mine still uses the alien artifacts.

Anyways on to my suggestion and love the mod!

So as I was playing I realized the creation of the units is fairly simple, I know this is for the base game in mind and all but I had a brilliant idea, Why not make a extended version where you have to assembly the vehicles them self in "Vehicle Frame Assembler", A fairly large new building that is only used to do what the name suggests.

Now the way it starts is you make the [for example] Chain-Gunner Frame, Simply some Iron and Steel, which makes a Chain-Gunner Frame, Then you take the frame and place it into another Vehicle Frame Assembler, and add the Propulsion to it[made in a normal assembler], which will make a 25% Chain-Gunner, then into another Vehicle Frame Assembler, this time you add the Control Unit/Mainframe that is also made from a normal assembler, this added with the 25% makes a 50% Cain-Gunner, Then you add the armor to it, making it the 75% Chain-Gunner and finally you put the Chain-Gun on it making it into a fully working Chain-Gunner

This is also repeated with the Flame-Tank, Warden, Laser Tank and Hauler, as well as the Excavator with there respective parts.

The frames as I stated above are simply some iron and steel, The Control units [named for each vehicle [I.E Chain-Gunner CU/Mainframe] are more or less some iron and control circuits and such, the Propulsion is if normal engines are used then simply a Fuel tank, Engine and suspention are all combined into a Basic Propulsion Unit that is used for the Hauler, Chain-Gunner, Flame-Car and Extractor, if they use Electric Engines then simply Batteries and Electric Engine Unit that makes a Advance Propulsion Unit for the Warden and Laser Tank.


[It would also be cool if you could make Advance Warden/Laser Tanks that need HAPU, Hyper-Advance Propulsion Unit, that in turn needs fuel cells instead of normal fuel, or maybe make a cross compatible mod that adds in the reactors from Fusion and Fission mod to make it where the Warden/Laser tank doesn't need fuel and the Laser Tank doesn't need ammo any more, just a though.]

Anyways, just a idea I had and though I'd share, just a rough draft really, Thank you for taking the time to read this and the time to make such a AWESOME mod, TRULY THANK YOU!

[mrvn]

I think it would make more sense to do all assembly in a single building and build components in normal assembler. Assembler could build the units too but with the assembler building the difference would be that the unit drives out of it. Reuse the garage for that and have it build new units from parts instead of accepting finished units for deployment.

[Nightinggale]

"Vehicle Frame Assembler" sounds pretty much like an assembler where an inserter takes the production and places it into a vehicle deployer. The vehicle will then drive out and awaits instructions. I have done that, though the inserter took from a chest and I placed a depot right outside to fuel the vehicles since they start really low on fuel.

[dead8eye]

Hi

my friend and i are testing and configurating this mod since weeks.
we have extremly problems to configurate the hauler -> miner -> depot logic command.
blueprints for this gets an error because the wrong "H" version of the string and manual setup doesnt work correctly too.

is it not possible to update the mod with another "hauler" and/or "miner" who can setup directly without any structures as requirement?

[mrvn]

Hi

my friend and i are testing and configurating this mod since weeks.
we have extremly problems to configurate the hauler -> miner -> depot logic command.
blueprints for this gets an error because the wrong "H" version of the string and manual setup doesnt work correctly too.

is it not possible to update the mod with another "hauler" and/or "miner" who can setup directly without any structures as requirement?

I think having to figure out how to automate is it kind of he idea. But here are some things I've done at the start:

* Place the miner and then add inserters around it fill furnaces directly. This gives you a nice production right at the start.
* Use a decider combinator as clock. Use decider combinators to output X/Y of the depot at T=0. Use decider combinators to output "Follow unit" signals at T=X where each X gives the hauler enough time to go there before the next one. Feed both into a unit controller.
* Use one hauler per miner configured to only accept what the miner produces. Send hauler to depot if not empty. Otherwise send to refule if not enough fuel. Otherwise send to follow miner if miner near full. Otherwise send to a zone for parking.

[Seldion]

"Vehicle Frame Assembler" sounds pretty much like an assembler where an inserter takes the production and places it into a vehicle deployer.

Yes but I am looking at it from a realistic point, the inserters are smaller then the vehicle them self, I know the game isn't based around realistic but that is why its a extended mod.

I think it would make more sense to do all assembly in a single building and build components in normal assembler.

True but I guess I am looking at it from a realistic stand point, the vehicles them self are as big as the assemblers, just doesn't make sense to me, granted tho making the I.E Chain-Gunner with just adding all the parts together at once would make more sense tho.

[AimMoreBetter]

Does this not work in 0.15? I see some of the vehicles that I have downloaded, but no the the miner. I also don't see the remote control unit.

[dead8eye]

Hi

my friend and i are testing and configurating this mod since weeks.
we have extremly problems to configurate the hauler -> miner -> depot logic command.
blueprints for this gets an error because the wrong "H" version of the string and manual setup doesnt work correctly too.

is it not possible to update the mod with another "hauler" and/or "miner" who can setup directly without any structures as requirement?

I think having to figure out how to automate is it kind of he idea. But here are some things I've done at the start:

* Place the miner and then add inserters around it fill furnaces directly. This gives you a nice production right at the start.
* Use a decider combinator as clock. Use decider combinators to output X/Y of the depot at T=0. Use decider combinators to output "Follow unit" signals at T=X where each X gives the hauler enough time to go there before the next one. Feed both into a unit controller.
* Use one hauler per miner configured to only accept what the miner produces. Send hauler to depot if not empty. Otherwise send to refule if not enough fuel. Otherwise send to follow miner if miner near full. Otherwise send to a zone for parking.

thanks for your help!
we are testing your suggetion but we didn´t understand how it has to work perfectly.
anything what we do has a result, that the miner itself works, but the hauler -> depot configuration not.
*for survival coop and newer players, i think this mod is to difficult to understand

[Berkys32]

Try this:
1) Constant combinator with ID of hauler and "follow" to ID of miner connected to vehicle controller. Whole setup connected to power grid ONLY through power switch, witch is connected to vehicle scanner with data from hauler and setup "ore you want < some amount you want"

2)Constant combinator with hauler ID and X/Y coords near depot where to unload connected to vehicle controller. Whole setup connected to power grid ONLY through power switch, witch is connected to vehicle scanner with data from hauler and setup "ore you want > some amount you want"

This way hauler should get signal to follow miner, or to go to depot, depends on amount of ore it has.
Its the simplest way I can get, but i suggest instead of basic "follow" command you should use "go to X/Y next to miner" setup. Follow command has no pathfinding, it could have terrible conclusions...

Contat me on discord if you want

[mrvn]

Does this not work in 0.15? I see some of the vehicles that I have downloaded, but no the the miner. I also don't see the remote control unit.

Works fine. Did you install all the right mods? Did you enable the remote control unit from the start option in the config? You might need to research and build one otherwise.

[mrvn]

Try this:
1) Constant combinator with ID of hauler and "follow" to ID of miner connected to vehicle controller. Whole setup connected to power grid ONLY through power switch, witch is connected to vehicle scanner with data from hauler and setup "ore you want < some amount you want"

2)Constant combinator with hauler ID and X/Y coords near depot where to unload connected to vehicle controller. Whole setup connected to power grid ONLY through power switch, witch is connected to vehicle scanner with data from hauler and setup "ore you want > some amount you want"

This way hauler should get signal to follow miner, or to go to depot, depends on amount of ore it has.
Its the simplest way I can get, but i suggest instead of basic "follow" command you should use "go to X/Y next to miner" setup. Follow command has no pathfinding, it could have terrible conclusions...

Contat me on discord if you want

Is that why my haulers keep running into things? They do seem to path find somewhat though or they would hit the walls all the time.

Why the power switch? Seems simpler to output eh X/Ys conditionally and feed the result from both deciders into a single unit controller (having only one give X/Y at a time). I also recommend using a clock to only occasionally send commands or to set the tick count for the same effect. Saves on UPS and units seem to get confused sometimes if they are constantly send somewhere.

Note: I'm getting my X/Y indirectly through a zone scanner instead of putting in some constants. That way I can just put the zone wherever I want it and the units will automatically follow. Especially at the start when you aren't sure where to place things. Or later when you control multiple units with the same circuit. Easier to send Hault <N> to green circle <N> than to plug in X/Y for each hauler.

[mrvn]

Playing some more I made some observations:

1) When going to X/Y some distance away the unit sees to first move to the center of a chunk and then plan a route from chunk to chunk. Finally it goes from the destination chunk center to the actual X/Y. Is that how the AI works or am I seeing a pattern where none exists?

2) The chain gun unit is real easy to research and built but is a total killer for the early game because of its rapid fire and long reach. Maybe too much so. But as soon as you get medium worms it shows how vulnerable it is to attack. And it is all you have for a long long time.

Why isn't there anything to improve the chain gun unit? It should start of with a slower gun and less reach and then there should be research to improve on that. Improved armor and more health for a mk2, mk3, mk4 version of it would also make sense.

Maybe also have 2 different types. One for close in attack. Lots of armor, rapid fire, little reach. And a sniper version, slow rate of fire, heavy hit, little armor, vulnerable to being swarmed. You would use the sniper to take out worms and the heavy unit as bodyguard and to take out bitters, spitters and hives.

3) The zone selection tool could be improved

3a) Filter like the deconstruction planer has:

For example filter for iron ore and only tiles with iron ore would be marked. Or Trees and rocks only filter.

3b) Counter while selecting

The deconstruction planer (and upgrade planner from its own mod) shows a running count of items under the selection. Would be nice to have that for zones too.

3c) Order and pattern for selections:

When you select a rectangle the area is filled line by line going left to right, top to bottom. But that is bad when you want to have a unit drive by each tile. Would be nice if one could set a separation between lines, so only every 5th line is marked for example. And have the lines alternate from left-right to right-left. Or have them go top-bottom and bottom-up. Or a spiral going inward or outward. Another useful pattern would be to only mark a line from the start corner to the end corner. This would make it easier to mark a path for the unit to follow.

3d) Code could be optimized

I looked at the code behind zones and it uses a list of marked zones. Then at various places it searches through the whole list trying to find a specific tile and return the index in the list. This is a really slow operation and gets slower the more tiles are marked. Is this the best you can do in lua and the modding API?

[Yinyang107]

Something is causing Bob's tanks and the helicopters from the Helicopters mod to have no weapon, and I think this mod is probably at fault. Any fix?

Edit: Actually it seems only to happen in sandbox mode so maybe it's to do with the fact that I have no body. So nevermind.

[mrvn]

Something is causing Bob's tanks and the helicopters from the Helicopters mod to have no weapon, and I think this mod is probably at fault. Any fix?

Edit: Actually it seems only to happen in sandbox mode so maybe it's to do with the fact that I have no body. So nevermind.

So to recap you do have weapons and you can load them and all. But you can't fire them because sandbox has no body. A major pain to try out stuff imho. I would love a sandbox with optional body.
I wanted to try out nukes but there is no way to fire them in sandbox.

[mrvn]

Ideas for some combinators

I've been playing with AAI for a while and there are some things I can't seem to do or do efficiently. I think there should be some extra AAI combinators to make some things possible or easier:

1) trigommetric combinator

I want to organize my chaingunner and wardens into a formation but I want the formation to be able to turn in any direction. For this I need to calculate the cos() and sin() of an angle to calculate the X/Y positions of each unit in the formation.
I could calculate some approximation for this but it would be inacurate, slow and use many combinators. So I think this needs a combinator that has cos, sin, tan and atan2 functions.

2) Selector Constant Combinator

I have several structures with a series of constant combinators and decider combinators that select one of the constant combinators for output depending on a selector (usually a repeating timer going from 0 to N). It would be much nicer to have a large constant combinator where you configure a selector signal and then a variable number of rows. If the selector is 0 it outputs row 0. If the selector is 1 it outputs row 1. And so on. Building this myself is just tiresome and you never leave enough space to extend it later on.

3) Zone Combinator

I find myself in the position that I want to convert a signal into a zone. But not A=5 into redcircle=5. I want A=1 ==> black diagonal-left , A=2 ==> black diagonal-right and so on. Or using two signals A/B to select color and pattern. That way I could map e.g. between hauler ID and zone color and pattern the miner should visit.

4) Mapper Combinator

For miners I have a list of what each miner should collect, e.g. iron ore or copper ore. Now I need the zone to be used for each. So again I have a signal that needs to be mapped into a zone. Iron ore=N into green circle=N, copper ore=N into green cross=N and so on. So I'm looking for a combinator that takes a list of pairs of signals and maps each input signal to the respective output signal. In my case iron ore to green circle and copper ore to green cross.

It should optionally filter any signal not mapped or pass them through unaltered. I can think of many other places where I could use this. For example how often do you need to just pick X/Y out of a bunch of signals?

Idea for beacons

While zones are great to mark tiles and then direct vehicles to drive there they are also very fragile. It is easy to accidentally mark or clear an area and overwrite a zone used for a path or parking position. Or if you have to move a parking position or depot and the zone that marks it then all later zones change their index. You have to remove and replace them all to keep the numbering.

So I'm thinking of something more fixed than a zone marker. Call it a beacon. A beacon could be a real entity that you build (cheaply) and place on the map. The beacon would then have a beacon number and unique ID just like any vehicle. The follow ID signal could be also be reused to direct vehicles to beacons or the unit scanner (or should there be a beacon scanner) could be used to get X/Y of a beacon. Beacons should be like concrete, so vehicles can drive over them without bumping into them.

I also think depots should have beacons built-in. So each depot would have also have a number an unique ID.


What do you think? Does that make sense?

[Nightinggale]

1) trigommetric combinator

Now that's a great idea. It was likely left out of vanilla due to not really being useful, but with vehicle angles it suddenly quite useful. Not just formation, but also generally calculating angle when manually controlling vehicles, a task where ticks from scan to controller input is important, meaning a combinator doing a calculation in one tick is vastly superior to vanilla combinators doing in the same in say 4 ticks.

2) Selector Constant Combinator

I have several structures with a series of constant combinators and decider combinators that select one of the constant combinators for output depending on a selector (usually a repeating timer going from 0 to N). It would be much nicer to have a large constant combinator where you configure a selector signal and then a variable number of rows. If the selector is 0 it outputs row 0. If the selector is 1 it outputs row 1. And so on. Building this myself is just tiresome and you never leave enough space to extend it later on.

I have had good results when combined with the switch combinator mod. That's really useful when designing any such multiplexer.

3) Zone Combinator

I find myself in the position that I want to convert a signal into a zone. But not A=5 into redcircle=5. I want A=1 ==> black diagonal-left , A=2 ==> black diagonal-right and so on. Or using two signals A/B to select color and pattern. That way I could map e.g. between hauler ID and zone color and pattern the miner should visit.

Sounds interesting, but it can also be useful to get something going the other way. That is select a color and then it will output a direction signal for the first direction signal it can see in in the chosen color, like if it's an arrow pointing up, it will be direction=360 on output. The ability to disable zone color for this could be useful as well.

Another interesting combinator could be one, which outputs a constant combinator if input is true. Input can then be zone = red (any zone of the red type > 0), or a direction of any color or any conditions currently available in the decider combinator. This will make it significantly easier to code vehicles driving to follow arrows painted with zones and change speed according to colors. However the last part about the standard decider condition will make it universally useful for even non-AAI tasks.

4) Mapper Combinator

There is the converter combinator in useful combinators mod and there is arithmetic combinator where you can say "iron ore + constant 0, output result as green circle". If none of those can solve your issue, then I don't get it right.

It should optionally filter any signal not mapped or pass them through unaltered. I can think of many other places where I could use this. For example how often do you need to just pick X/Y out of a bunch of signals?

I too have wondered about a filter combinator. It would be nice to have some sort of "constant combinator interface" where you enter some signals and then on each tick, it outputs the values present on input for each of the chosen signal types. Obviously 0 is skipped. Sounds simple, yet really useful for getting an overview, particularly if it can use the "chest overlay" where you see signals. This too can be quite useful for many non-AAI tasks.

[Earendel]

Ok I'm back and ready to get back into modding.

@mrvn, you have some nice ideas there a lot of them run into API and/or performance limitations. Right now the programmable structures mod has a large UPS strain mainly just due to reading and writing signals. The structures act like giant combinators. Making a sin or cos combinator would be just as slow even though the actual calculation would be quick.

I'm planning to make a path/waypoint system with ids soon and the waypoints would act a bit like the beacons you described except that they'd be digital entities like zones instead of built structures.

[Nightinggale]

Sure there are performance issues regarding adding more signals, but how is performance for one modded combinator vs 5 vanilla ones? How many vanilla combinators should a modded one replace to break even on performance? The part about performance is often mentioned when it comes to combinators, but I have never seen anybody talking about CPU time saved/lost when replacing a bunch of combinators with a single one.

Speaking of performance, I did propose scanners, which triggers when input is true, or triggers when input is true and last input was false. This will allow consuming CPU time when it's needed and stay completely idle for ages when it isn't needed. It also reduces tick latency because it can trigger when you need it, even if it only triggers once every 100 ticks.

[Earendel]

Sure there are performance issues regarding adding more signals, but how is performance for one modded combinator vs 5 vanilla ones?

Vanilla vs modded combinator speed, I'm not sure what the exact value is but the ballpark is closer to 50000 than 5.

Also, the actual calculations can be done quickly, it's reading each incoming signal and writing each outgoing signal that takes the most time. So for example, custom combinator plugged into you logistic system would be way slower due to reading lots of signals.

A case where you only write the output if the input changes only solves half the problem because just reading the incoming signal and looking for a change is also quite inefficient. For this reason most modded combinator-like systems are restricted to only run once per second.

[mrvn]

Ok I'm back and ready to get back into modding.

@mrvn, you have some nice ideas there a lot of them run into API and/or performance limitations. Right now the programmable structures mod has a large UPS strain mainly just due to reading and writing signals. The structures act like giant combinators. Making a sin or cos combinator would be just as slow even though the actual calculation would be quick.

I'm planning to make a path/waypoint system with ids soon and the waypoints would act a bit like the beacons you described except that they'd be digital entities like zones instead of built structures.

I'm pretty sure that a single combinator that takes a angle and outputs the sin(angle) * 100 would be on par with a combinator network to compute the sin with 2 digit accuracy manually. You need a lot of combinators to calculate this yourself if you even know how to do that.

And yeah, I've run into the UPS problem. I modified the tile scanner into a chunk scanner. Input X, Y and distance and it outputs a summary of an area around X, Y with max(dx, dy) <= distance. Distance 2 means it looks at a 5x5 square, which is OK for UPS. Put try looking at a whole chunk (distance = 16, 32x32 = 1024 tiles) and the UPS drops below 4 here. I'm not sure if it is the reading and writing of signals because that is relatively constant no matter how many tiles. Writing land=1, land=25 or land=1024 should take the same time. I think it's more the amount of lua code to run in general.

I'm thinking about two ways to make a chunk scanner work without killing the game. The first one would be to limit the range but that would need to be low. Scanning the area a mk5 miner covers (11x11 iirc) is stressing it. So my other idea is to make it scan less often the more tiles you scan. So basically if you scan 25 tiles it will only scan every 25 ticks.

The way I want to make this plausible and visible is to use the scan progress and energy consumption. So when you input a signal to scan 32x32 tiles it will use up energy for 1024 tile scans and then it needs to recharge for the next 1024/n ticks and the scan progress bar would show the recharge. If it doesn't have enough energy accumulated it won't scan.