Programmable Controller is very slow and questions
duncanwebb opened this issue · 64 comments
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.
Not sure here.. it should be really fast with 10 speed upgrades. Any chance you can boil the demo program down to something minimal which reproduces the problem?
There is a minor documentation error, the manual says dispense upgrades and the controller says inventory upgrades.
Yeah, a couple of places in the manual got missed after the move to inventory upgrades in 1.14. I've probably already fixed it in 1.16...
It would be nice if a magnet upgrade could be added to the controller.
That has occurred to me in the past as well. I seem to recall I started looking at it and realised it might be more complex than I expected. I'll check again though.
It would be hand if the drone debugger could work on the programmable controller.
Yeah, but I have a feeling this might be another of those "more difficult than expected" changes...
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.
I can see the benefit of that, yeah. Could be a significant internal change, though, so again will need some investigation.
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.
Does this not work now?
I don't think the network API piece works with this program - it didn't like the item assignment.
What happens? Any errors?
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.
The minidrones are client-only entities, so yeah I can see they could end up getting orphaned if the client-side chunk unloads. I think that should be fairly easy to fix, though.
Not sure here.. it should be really fast with 10 speed upgrades. Any chance you can boil the demo program down to something minimal which reproduces the problem?
The drone has a supremium paxel so it is very fast, and you can see it runs fairly slowly. I reckon about the same speed as a drone without speed upgrades.
It would be nice if a magnet upgrade could be added to the controller.
That has occurred to me in the past as well. I seem to recall I started looking at it and realised it might be more complex than I expected. I'll check again though.
No problem, if it's hard, I could use a second drone to collect the items.
It would be hand if the drone debugger could work on the programmable controller.
Yeah, but I have a feeling this might be another of those "more difficult than expected" changes...
OK, it is a nice to have but not essential as we can use a scaled down area with a drone to test.
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.
I can see the benefit of that, yeah. Could be a significant internal change, though, so again will need some investigation.
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.
Does this not work now?
How can I test this, the order blocks are processed seems to be a bit random?
I don't think the network API piece works with this program - it didn't like the item assignment.
What happens? Any errors?
No errors, just the paxel remained in the chest and nothing seemed to be happening.
Thanks
Yes, the controller holds the inventory. TheOneProbe is very handy here for seeing what's in the controller. You can insert/extract items to the controller by normal means (hoppers/pipes/drones...).
The reason you're seeing slow behaviour when using "foreach" is that this will dig at most one block on each drone AI tick (which is every 3 server ticks). I see the same behaviour with a diamond shovel (it's not tool-related). From the debugging I did, it doesn't necessarily dig a block on each tick, either. Not exactly sure what the logic is here (I didn't write this code, Minemaarten did back in 1.7.10 or earlier...) but I'm pretty sure it's always been this way...
Using a Dig piece with the area directly will dig many blocks at a time (can't remember the limit offhand, but it's fairly big unless you check the "limit interactions" checkbox on the dig progwidget.
This behaviour is the case for regular drones too so it's not a Programmable Controller problem. Not sure if there's much I can or should do about it, though. There are better ways to control large scale digging with variables - check this old video from Minemaarten: https://www.youtube.com/watch?v=FIjEdD_Yj9Y for example.
I've placed a chest beside the programmable controller, and I am expecting to see something in the chest when the minidrone has something in its inventory. It looks like the items are being held in the controller, when I broke the controller it dropped items. Do items need to pulled from and pushed into the controller?
Thanks for the information, as usual very helpful. I've seen the video at least four times. I would have to take care when extracting items from the controller not to extract the tool.
The goal of the program was to build a moat around a village of about three blocks wide. The area piece can make a tube shape in the "y" direction but does not have a width setting. A width setting would be very nice as the calculations would be more accurate than three rings, especially for small radii.
The design was to use three consecutive tubes to make the moat. I could improve this design by using three rings and dig a column for each ring, that would be faster but a little more complicated. It wouldn't work too well to dig a wide column as the walls would be thinner at the sides. (might work with a 3x3 column)
One feature that drone programs have is that they don't know when an area has been processed. For example, we build a structure using a hollow shape and don't kill the drone, if we make an opening the drone comes back and fills the opening.
This is where the "for each coordinate" piece is helpful, when it finished then this area has been processed. (BTW this is where the generator piece could be useful to place a different block in a sequence). I don't see why the "foreach" piece should not be instantaneous, if you need to slow the iterations down that a wait piece could be used.
The "foreach" pieces don't seem to be used very much, very few search results come back, so I reckon you are free to modify them without impacting many programs.
I don't think the foreach will retain its state between restarts as it will be reinitialised on each game start.
I don't see why the "foreach" piece should not be instantaneous, if you need to slow the iterations down that a wait piece could be used.
It's not so much the foreach piece itself, but the way the drone's entire AI task is ticked - every 3 ticks, it moves onto the next widget in the program (on the other 2/3 tasks it does whether the executing widgets are still applicable). The AI manager logic is fairly complex and not something I want to mess with much (amazingly, it's virtually unchanged since Minemaarten originally created it... entity AI is one of the most stable parts of the Minecraft codebase, it would appear).
And the foreach is intended to process one blockpos per tick; I don't think the intention was ever to use it for large-scale building. I appreciate this is something drones are a little weak at - while you can do a lot with areas, there are limitations too. Like as you mentioned, a drone will keep coming back to fill an opening you add, although you can mitigate this by adding "gaps" as blacklisted areas in the place piece. But the drone still needs to scan the entire area unless you write a more complex variable-based program to track the drone's progress...
The area piece can make a tube shape in the "y" direction but does not have a width setting
By "width", I'm guessing you mean the thickness of the actual cylinder walls rather than the cylinder's overall radius? That would actually be quite nice to have, although it would probably need to work for other shape (box & sphere at least, possibly wall & line too). Might not be too difficult to add, I'll have a think about that.
I understand if it is tricky then changes are best avoided.
By "width", I'm guessing you mean the thickness of the actual cylinder walls rather than the cylinder's overall radius?
Yes indeed, the thickness of the line and for all shapes that are not filled.
Did we have a ticket about drone pathing? The drones are getting stuck on trapdoors being used window shutter. Funny, a zombie also gets stuck on an open trapdoor.
Actually, there is an easy way to do cylinders with thickness right now: blacklisting. E.g. have a whitelisted area of a solid cylinder with radius 10, and a blacklisted area of a solid cylinder with radius 7 (and exactly the same P1/P2 points), and you'll get a hollow cylinder with a thickness of 3.
Regarding pathing - yeah, I'm aware of it, and since it's such a fundamental problem (vanilla pathfinding), I'm not inclined to try to fix it. Or rather, I've tried in the past and been unable to figure it out... life is just too short for some problems and debugging vanilla pathfinding is one of those :-)
Thanks, hadn't though of excluding a cylinder from another cylinder. I've done it for doors and windows in the past and in the latest video.
Thought that this could be a problem of vanilla pathfinding.
Okay, I gave up with excluding a cylinder from a cylinder as the drone spent all its time scanning the excluded area.
This is a relatively simple program https://pastebin.com/tG3shGSy
And works like a treat with a drone, but does nothing with the same done in the programmable controller. I don't see why, there are no errors reported.
Any idea what could be the problem? Removing the import tools piece makes no difference.
BTW the "for each coordinate" survives a game restart. Easy to see with this version on the program.
Ignore the comment about the cylinders, I'd missed changing one to a cylinder.
https://pastebin.com/kMX78Tay this is simple and extremely fast.
I'm really trying to demonstrate "programmable controller and the "for each coordinate".
The shape is a more spherical so subtracting one from another leaves a hollow sphere with a wall thickness of 3. Not the same as a tube. Sorry it looked like it was round at the top.
Found something that may cause some problems. The following program in the programmable controller when the dig piece has "requires a tool", then it does not dig even when the controller has tools in it.
Also, I'm not sure but it does not seem to pick up items.
I can verify that the controller has issues when changing the dig piece to require a tool. I am trying to flush out my quarry program using the controller (mainly for the pathing/speed). Also, unfortunately, without the controller having access to a magnet upgrade makes for collection of dropped items/blocks very inefficient vs a normal drone. I noticed major TPS issues when trying to use a controller to act as a collection drone in a quarry (in comparison to 10x regular drones acting as collectors with magnet upgrades - no major TPS issues).
Yeah, I think the controller needs some attention (including magnet support). Now that I've got the 1.16 mob spawner system done, I'll spend a bit of time on it (and backport any fixes to 1.15 :)
So, I just did some testing with the programmable controller and "Requires digging tool" enabled, and it works fine - see https://streamable.com/sr4pun
This is with feeding a netherite shovel into the programmable controller to give the drone a shovel, and then extracting it again with a button-controlled hopper. As expected, the PC initially doesn't dig because it has no tool, starts digging as soon as I feed a shovel into it, and stops again if I pull the shovel back out.
Unfortunately, it doesn't always work. Not sure what I did it might be to do with limit interactions. When I tested it was not working but when I made the video https://youtu.be/uz4WY8Ouq6k it did work. It didn't pick anything up in both cases.
Hmm. Pickup is working fine here... https://streamable.com/0ipmyf
Not detecting any TPS issues so far either. Not sure how there could be... the codepath for drones and the programmable controller is identical once the AI code is entered. Only difference is the AI code is called from the drone entity's tick() vs. the programmable controller tile entity's tick().
I will, but the code for the PC is identical for 1.15 and 1.16. I've not changed anything there recently.
On the plus side, magnet support should be extremely easy to do. The code to do it is all there already, I just needed to mark the programmable controller as being able to accept magnet upgrades...
Great news about the magnet upgrade, looking forward to testing this.
I've been busy finding the mods for 1.16 and loaded my world in this mod collection. The behaviour is the same as in 1.15.2 I can through down blocks and the PC does not collect them.
There is some weirdness with the GPS tool, it showed on coordinate a used the actual coordinate. Multiple GPS tools were even more confusing.
Would it be possible to stop time when in the programmer GUI? XaerosWorldMap_1.11.2_Forge_1.16.4 does it when the map is open.
The PC does not support "for each coordinate" and may not support importing items from itself.
This program works and picks up items
The difference is the area type, boxes work and cylinders don't
Ah, cylinders! I missed that the first time round. From the manual:
Keep in mind that any Area widgets connected to this widget will always be interpreted as area type Box, regardless of the given area type. It's possible to create more complex shapes, though, by using whitelisting/blacklisting of multiple areas.
This is also the case for any other widgets that work with entities, e.g. the Entity Attack widget. It's unavoidable unfortunately, since getting entities in a non-cubic area would be quite difficult (and probably extremely laggy).
What I can do here is add a warning in the programmer if any area piece attached to such widgets is using anything other than the Box shape.
The PC does not support "for each coordinate" and may not support importing items from itself.
This program works as expected in the PC:
I'm not sure what you mean by "importing items from itself" ? That's a no-op in any case.
Would it be possible to stop time when in the programmer GUI? XaerosWorldMap_1.11.2_Forge_1.16.4 does it when the map is open.
Standard Minecraft behaviour is for container-based GUI's (i.e. ones with inventory slots) not to the pause the game. Why do you want the programmer specifically to pause the game when it's open? (And obviously pausing is only a thing in the SSP game, not applicable to SMP).
There is some weirdness with the GPS tool, it showed on coordinate a used the actual coordinate. Multiple GPS tools were even more confusing.
I don't understand this sentence. Can you start a new issue for this please? Too many different topics in this issue now.
Standard Minecraft behaviour is for container-based GUI's (i.e. ones with inventory slots) not to the pause the game. Why do you want the programmer specifically to pause the game when it's open? (And obviously pausing is only a thing in the SSP game, not applicable to SMP).
Developing programs takes quite some time and there is no indication of the current time so in survival SP it would be useful to stop time. Obviously, I could develop in creative and switch back to survival but this is tedious and easy to forget which mode you are currently in.
What I can do here is add a warning in the programmer if any area piece attached to such widgets is using anything other than the Box shape.
Why not convert the shape to a box for the pickup piece? With a white listed shape the box is a bounding box outside the shape and with a black listed shape the box is inside the shape. Here is what I mean for a circle.
Actually, easy to do in the program with the "for each coordinate" but tricky with drone coordinate calculations.
The cylinder pickup worked well in the drone program as it had the magnet upgrade and I never noticed that is was not working.
I'm not sure what you mean by "importing items from itself" ? That's a no-op in any case.
This is in the comment #651 (comment).
With the import items the sign never gets updated, if I remove the import pieces the sign get updated once, count increases once per cycle. Here I remove the import and the dig operations (with and without dig the count stayed at one)
BTW has there been some performance improvements in 1.16? 1.15 is just very laggy even using omni hopper feeding a pressure chamber.
BTW has there been some performance improvements in 1.16? 1.15 is just very laggy even using omni hopper feeding a pressure chamber.
Too vague to really comment on. I have fairly extensive setups in my dev worlds on both 1.15 and 1.16 and haven't experienced any serious lag issues. I don't recall make any major performance-related changed from 1.15 to 1.16. The only real way to track lag down would be via Java profiling to identify the areas where most CPU time is being spent.
Why not convert the shape to a box for the pickup piece? With a white listed shape the box is a bounding box outside the shape and with a black listed shape the box is inside the shape. Here is what I mean for a circle.
It isn't really that simple. I understand what you're getting at, but this adds a huge amount of complexity, since there are multiple shape types, and some types have all of X/Y/Z axes to support... so I'm not inclined to change the current behaviour. Fortunately, magnets now work for the PC, so the problem should be much less of an issue.
With the import items the sign never gets updated, if I remove the import pieces the sign get updated once, count increases once per cycle. Here I remove the import and the dig operations (with and without dig the count stayed at one)
Sorry, I'm really not following you here. Can you boil this down to a minimal program to demo the problem please?
Build 74 from https://jenkins.k-4u.nl/job/PneumaticCraft-Repressurized-1.16/ includes magnet support, minidrone "cloning" fix and clearer error reporting for non-box area types. I'll be doing a 1.15 backport too, but since you've started on 1.16, here's a chance to test out some fixes...
(and if you're taking your youtube series to 1.16, I recommend looking at the new 1.16 features: the Jackhammer, renewables, and the mob spawning system :) )
This should explain the import part. I'm using the release version rather than the beta version for 1.16.4
From the new program, it looks like centre doesn't get reset between inserting and remove the drone from the controller. Therefore, the position "pos" is retained and doesn't move.
I noticed while testing the "pos" was increasing as expected.
The entity tracker does not seem to cause much lag. In 1.16 the tracker was turned off and the FPS were similar to 1.15.
Ah, so just have the programmable controller forget all its (non-global) variables when the program is removed? That makes sense - wrenching and replacing a drone entity would reset all the variables. That should be easy enough to do...
So, I just did some testing with the programmable controller and "Requires digging tool" enabled, and it works fine - see https://streamable.com/sr4pun
This is with feeding a netherite shovel into the programmable controller to give the drone a shovel, and then extracting it again with a button-controlled hopper. As expected, the PC initially doesn't dig because it has no tool, starts digging as soon as I feed a shovel into it, and stops again if I pull the shovel back out.
@desht Not to beat a dead horse and drag this thread out anymore, but I believe I know what was causing the issue with 'requires digging tool.' I noticed @duncanwebb was possibly using a paxel (multi-tool). I too was using a paxel when experiencing the 'requires digging tool' issue and since have resolved it by using vanilla tools. This being said, I don't believe this is a PC issue and probably more of a cross-mod issue and this portion should be closed.
@Tekstack not related to the Paxel as it worked after playing the game on a later date and it hasn't happened to me since then. Sometimes mods don't load correctly when starting the game, happened to me a few times, or maybe something got corrupted after playing for a few hours.
I didn't really mean in PnC:R for performance improvements, just generally. I tested this in both 1.15.2 and 1.16.4 and in both cases the hopper-interface was very slow from 32->3 fps. But when walking about it seems smoother.
There are only about three shapes that are not boxes, cylinder, sphere and pyramid, the others seem to be boxes. I was only an idea, warning would help. The outside box is easy to calculate with drone pieces if the x or z are the same.
I'll work on the program now.
I noticed you seem to have some drone debug particles in the background there... those will have an impact on performance, particularly for large areas. Does switching off your entity tracker help at all?
Yes, that's it. I would expect the drone variables to be reset when the drone is removed or have an explicit reset button or reset the variables when the drone is updated in the programmer.
OK, build 75 should have some better variable behaviour (see notes above). Also I've added a client-side config to have the programmer GUI pause the SSP game - default is false (which is current behaviour), so you'll need to change that to true to have the game pause on you.
Only on 1.16 right now, will backport to 1.15 when I get a chance (tomorrow probably).
The programmer_gui_pauses works a treat; you are a star.
Cannot get the variables to clear, even reprogramming the same drone that simply clears the variable centre. Also tried breaking and replacing the controller.
Like showing the area type.
The pressure screen is too narrow, guess you know that.
With build 76 and this program:
I get the results I would expect. The counter on the sign continually updates from a start of -49 until the program is removed and reinserted, when it starts back at -49 again.
Cannot get the variables to clear, even reprogramming the same drone that simply clears the variable centre. Also tried breaking and replacing the controller.
That's strange. I verified all variables stored in the programmable controller's aiManager are wiped whenever the item in the programmable slot changes. I can try another change, which is to completely delete and reinit the aiManager from scratch (which I guess would be closer to how a drone entity would do it).
The pressure screen is too narrow, guess you know that.
Don't know what you mean by "pressure screen". I wasn't aware of anything being too narrow?
My bad, I hadn't initialized the sign coordinate so the updates weren't been seen until afterwards. Yes, it works as expected. Did you test it before the fix?
There is still something going wrong and it is to do with the import of the tools.
Sorry, I'm getting a bit confused as to what is causing the output. Again it looks like the import is not working and so the flow does not move onto the "After" sign update. What I was thinking was that the variables are not being reset so the "for each coordinate" was finished and there for nothing to do.
Here is the output on the sign https://streamable.com/y6c76c
Here is what one-probe is showing https://streamable.com/l3w08y
So, it looks like the tools are being imported and exported back and not moving on to the next puzzle piece.
Again... Why are you even trying to import from the controller? If it's in the controller, it's in the drone's inventory already; the controller inventory is the drone's inventory. It doesn't need to be imported. The operation makes no sense.
@duncanwebb I believe you are treating the controllers inventory like you would a regular drone. Treat it like you would an aerial interface. You hopper/pipe items in instead of using import pieces. This applies to everything from tools to items needed for building if you are using a block place piece (essentially anything a regular drone can carry with a few exclusions such as entities).
Yep - you can also import a tool from some other inventory like a nearby chest just fine (I just tested that with the PC - it works). But importing from yourself doesn't make sense.
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?
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...
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.
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
To be fair, this discussion is quite interesting (although this issue is getting reeaallly long now) :)
@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.
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.
@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.
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.
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.
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.
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).
Fixed in 2.7.0 release (and 1.5.3 for 1.15.2). Future PC enhancement work in #656