In my test world, the Drone I tried to use for a quarry task just committed suicide when it should've started digging. This is because of a hard limit in the Area piece of 100,000 blocks. The drone just commits suicide without notifying this, however. Two solutions exist:

1. Look if this limit can be removed/increased so that it's really not a problem (100,000 isn't thát much)
2. Add a 'compile error' for areas with >100,000 blocks, at least for the staticly configured coordinates.

Possibly make the 100000 limit a config setting and throw a compile error (mentioning the config) if that is exceeded? This is something that server admins might like to have control of...

I also noticed this issue and assumed the area was too big (hidden limit). I was able to get around the limit though through relative cords vs static area. With that in mind, you may add the check to the main puzzle piece such as the dig or pick up and not the area pieces themselves. This will ensure relative cord variables do not exceed the 100k total block hard limit as well as static areas. If the total sum of blocks in the dig operation exceeds the hard limit, then prevent the export of the program and highlight the piece to show the user the error via tooltip similar to the existing error logic.

Also, I agree with @MineMaarten in that 100k limit should be adjustable via config option mainly due to the ease of use of static area pieces vs relative logic.

Made a couple of changes here:

1. The area size is now validated at compile-time, and on the main puzzle piece as @Tekstack suggested.
2. The size limit is now adjustable in config (see I:maxProgrammingArea in the general section)
3. The default limit is raised from 100,000 to 250,000. This is fairly arbitrary, and open to discussion...

Other notes:

• I've left the run-time check in, to catch any drones which may have been programmed (but not deployed) before this change. They will still suicide, but a message will now be logged giving the drone's location & reason for the suicide).
• This does mean more potential (client-side) work in the programmer gui when calculating the area set (the size of which is needed to do the validation), but shouldn't impact badly unless the player chooses a stupidly huge area (like, tens of millions of blocks). We could perhaps use a custom SizeLimitedSet to throw an exception if too many blocks were added but this would be a wider change (altering how IAreaProvider#getArea() works), and we also wouldn't be able to report the actual number of blocks to the player.

This is done now.