Programmable Controller is very slow and questions

[duncanwebb]

Minecraft Version

1.15.2

Forge Version

31.2.36

Mod Version

pneumaticcraft-repressurized-1.15.2-1.5.2-88

Describe your problem, including steps to reproduce it

Not sure if the programmable controller is slow or if the "for each coordinate" piece is slow. The programmable controller has 10 speed upgrades.

The program is here https://pastebin.com/eSPSkp79

Here is the set-up.

Any other comments?

There is a minor documentation error, the manual says dispense upgrades and the controller says inventory upgrades.

It would be nice if a magnet upgrade could be added to the controller.

It would be hand if the drone debugger could work on the programmable controller.

It would also be handy to be able to use standby and suicide pieces in the programmable controller. This would allow testing using a drone and use the identical program in the controller. A warning would be sufficient.

It would also be nice if the "for each" pieces could be linked to a global variable so that their state could be saved between runs.

I don't think the network API piece works with this program - it didn't like the item assignment.

Do I need to just chunk load the programmable controller or the whole area? After a while there were a lot of minidrones hanging around, when only the controller was chunk loaded.

[duncanwebb]

This behaviour is specifically for multiple tools, with a single tool it works. It does make sense to import the tools from a different inventory.

I realize that it is useless to import tools into the programmable controller from itself, however the programmable controller does not offer any interactive debugging, so using a drone to develop the program seems sensible as it has a debugging interface.

When a drone program is debugged, then it would be ideal if the unchanged program ran in the programmable controller. This is what I was thinking about when I asked if suicide and standby pieces could be ignored.

If the programmable controller could use this interface then I wouldn't need to use a drone for debugging purposes. What could be nice is if messages written to signs could be logged to a file. A debug puzzle piece could turn on or off this feature, with a warning if debugging is enabled.

@Tekstack, I remember you sent me a drone program to build a green house that you developed for 1.7.10, this would be an ideal candidate for the programmable controller.

Not trying to be difficult or pedantic just trying to understand and find the gotchas.

[duncanwebb]

Changed the program to import to tools from a chest, this works just fine. However, take a looks at this https://streamable.com/i17uje the tools are being swapped. Is this because it is selecting the best tool?

[duncanwebb]

The moat program does a pretty decent job

[desht]

Yes, that is normal behaviour. Drones (and the PC) will always select the best tool in their inventory for the block they're breaking (i.e. the tool which gives the quickest break time).

Regarding the other issue (PC vs drone functionality), I get your point - it would be good to have more equivalence between the two. In particular, I'll see if I can find a way to allow debugging of the PC with the same interface as is used for drones. As far as disabled pieces goes, it might not be too hard to just make those pieces do a no-op on the PC, but there may have been a reason Minemaarten chose to do it that way...

[Tekstack]

@duncanwebb I'll be honest, I rarely use the suicide piece in any of my programs, but I can see where you are getting at with using a regular drone for debugging then transporting the routine to a PC. Typically I get around this by placing logic reserved for a regular drone (such as standby) at the end of a routine so that I can easily remove the problem/unnecessary logic after debugging (see below in red). Also, I will typically put a 'Drone Condition: Items' check at the very start of a program (See below in Blue). This insures the drone has the proper tool and avoids unnecessary imports in the main logic, but gives the routine flexibility in piping in the tool directly to the PC or having a chest in which the PC can grab the tool.

[duncanwebb]

I know this problem trying to figure out why something was done and if it is safe to change.

The programmable controller doesn't have redstone control, unusual for PnC:R machines, and it continually uses pressure even when not doing anything. The suicide piece could push the drone through the program slot in the sides interface, which stop the PC from using air. BTW, I tried feeding in a drone through this slot but it didn't work. I've not tried the network API.

[duncanwebb]

@Tekstack, I'm placing the standby piece after the start as this will cause it to standby if there is no work rather than hover there. This is a program for charcoal supply drone that took items from some storage drawers and crafted charcoal. Early on the charcoal was being used faster than the crops grew, so it was in standby while waiting for crops.

In my videos I was trying to introduce programming topic starting with medium and moving onto advanced.

[Tekstack]

One way around stopping the air leak could be through the use of a regulator tube module/lever in place of your proposed suicide. Have the drone activate the lever when it is complete thus cutting off any new air flow into the PC.

[duncanwebb]

Yes, I hadn't thought of that and it is neat. I used the technique but sometimes miss the obvious.

I made a plastic sheet making program where a drone turned on the vortex tube to cool the heat frame when there was plastic to process and when there was no plastic it turned it off.

[Tekstack]

Routines reserved for long wait/standby, in my experience, are better off left to regular drones vs the PC. For instance, I also have a routine for crafting Insanium essence (see below), which doesn't activate until the drone has access to 1,024 inferium. With that said, if you would like to discuss further, i'll send you a pm on your discord because this might not be the proper channel to have these discussions for @desht 's sake :P

[desht]

To be fair, this discussion is quite interesting (although this issue is getting reeaallly long now) :)

[duncanwebb]

I think we should really close the ticket

Not sure if the programmable controller is slow or if the "for each coordinate" piece is slow. The programmable controller has 10 speed upgrades.

The "for each coordinate" piece is slow but when using them to dig an area they are fast enough.

There is a minor documentation error, the manual says dispense upgrades and the controller says inventory upgrades.

This is fixed

It would be nice if a magnet upgrade could be added to the controller.

This is also done

It would be hand if the drone debugger could work on the programmable controller.

Maybe a separate feature request, if this is something you want to do?

It would also be handy to be able to use standby and suicide pieces in the programmable controller. This would allow testing using a drone and use the identical program in the controller. A warning would be sufficient.

Same as above

It would also be nice if the "for each" pieces could be linked to a global variable so that their state could be saved between runs.

This works, it was hard to find a way to test it and difficult to see for small programs.

I don't think the network API piece works with this program - it didn't like the item assignment.

Need to look at this again.

Do I need to just chunk load the programmable controller or the whole area? After a while there were a lot of mini-drones hanging around, when only the controller was chunk loaded.

This is fixed but haven't been able to verify it.

Desht has made quite a few enhancements.

• Magnet upgrades for the PC
• Mini-drone lying around
• Stopping time in SP survival
• non-box shapes for the pickup piece giving an error
• resetting the variable when a program is inserted into the PC

I think that area piece also shows the area.

Let me know what you would like to have.

[desht]

Yeah, I'll open a tracking issue for the remaining PC work (debugging and ability to load/ignore blacklisted pieces), and I'll close this one when the next release is out (probably 2.7.0 in a few days).

[desht]

Fixed in 2.7.0 release (and 1.5.3 for 1.15.2). Future PC enhancement work in #656