I could not find a method of clearing the turtle/computer id from them, this leads to unstackable computers/turtles
So could a way to do this be added into the mod

original feature request that caused this issue: #437

• Explanation of how the feature/change should work:
  config option to use the old way of labeling turtles or an ingame command to clear ids of a computer
• Some rationale/use case for a feature. My general approach to designing new features is to ask yourself
  quite a few of my more advanced programs place turtles themselves this leads to some issues when the turtles dont stack anymore.

edit: i need to learn how to spell.

I guess the cleanest thing to do would be add a recipe which clears a computer of all additional data. So you place a single computer in a crafting table, and get out a computer with no id or label. Fairly sure this is similar to what other mods do.

It might be too easy to accidentally wipe a turtle with the crafting method. Obviously it wouldn't happen when crafting with peripherals, because you could only put one in anyway, however its defintiely very easy to do if you have some sort of turtle.craft() system going - if you end up missing an item, the turtle is gonna wipe itself as a valid reicpe. It could also feasibly happen with a few misplaced shift-clicks.

Another proposal was letting the computer lose its ID if the drive is empty when being broken, but I can see this causing more complexity. The computer will have to perform a filesystem check on the main thread every time it's broken, so unless there's a way round that, there doesn't seem to be a very clean solution. This one could also lead to somebody losing an ID they care about.

I don't think doing "does this computer have files" is a great way of doing it. It makes sense, but I don't think it's the most intuative. You'll have some computers which'll drop with their ID and some which won't, and it may take a while for people to figure out why.

@ralphgod3 can you explain exactly what you're doing? I'm trying to envision a situation where you'd automatically place turtles and then not want them to keep their files.

Edit: Oh, are you booting them off an adjacent disk? That'd make sense I guess.

I don't think doing "does this computer have files" is a great way of doing it. It makes sense, but I don't think it's the most intuative.

It's not the most intuitive but you can't do that by mistake.

And how about a message in the advanced tool-tip that explicitly said how to do that ? Example: "Remove all files and label to make this turtle stackable"

I don't think doing "does this computer have files" is a great way of doing it. It makes sense, but I don't think it's the most intuative. You'll have some computers which'll drop with their ID and some which won't, and it may take a while for people to figure out why.

@ralphgod3 can you explain exactly what you're doing? I'm trying to envision a situation where you'd automatically place turtles and then not want them to keep their files.

Edit: Oh, are you booting them off an adjacent disk? That'd make sense I guess.

yes they are booting of an adjecent disk and I am never even actually copying the program to them they just need to start it from disk and then run it.
placed by a single "master turtle" which feeds them their allocated mining zone thru a wired modem


and when they are done or have stuff to drop of they form a nice line to drop it off

I do wonder if having them not saving their fuel when there are no programs on the turtle would be a problem.
the only way i could see this impacting people would be someone only running the default quarry/tunnel programs and then picking the turtle up.

This is why I couldn't get into OpenComputers, because the robots were non-stackable.

I just came back to MC after a long hiatus, to find my mining setup will no longer work because of this.

I respect the intentions behind #437 to make it easier for new users, and I apologize if what I'm about to say comes off as entitled or rude.

But this improvement for new users came at the expense of existing users and programs that stack computers or turtles in storage, such as armies of mining turtles that @ralphgod3 showed, and @Penquin8 mentioned. Without a method to "clear" a computer's ID, it just became very difficult to store even a small number of computers or turtles.

I'm actually one of those new users that this change was supposed to help, I just got into this mod a few weeks ago. I'm trying to write a mining program where a single turtle can deploy a swarm of other turtles, loading code onto them as it goes, then returning those turtles to storage once the job is done. I was inspired to get into this mod specifically because I saw somebody do this: https://www.youtube.com/watch?v=pZSQlQAqUCI

With this change, I can't store several stacks of turtles in a single turtles inventory after the mining job is completed. Now that a turtle becomes permanently unstackable after being turned on once, crafting new turtles is now the only way to have stackable turtles.

In my opinion, this change was shortsighted, and harms the functionality of the mod. The problem of new users accidentally losing their files is not a problem that should be solved by breaking compatibility with existing users programs. It might make new users happier in the short term, but for me at least, it's created a bigger problem for the long term, as my plan for a self deploying and returning mining army is now far more difficult to implement. Or I'll just have to use a previous version of the mod, which I don't want to do, as I'd really like to use the generic API in a 1.16 world (as Plethora has not been updated to 1.16).

I believe that this is a documentation/education problem, not a functionality problem. As a new user, the incomplete documentation and lack of any official and up to date tutorials for CC:Tweaked have been the source of far more trouble for me than accidentally losing files, as I either need to check the outdated ComputerCraft wiki, or Google my problem. Because of this, I'm going to try to spend some of my time contributing to the documentation at https://tweaked.cc/.

Instead of changing default computer behavior, I think that automatic ID preservation should be rolled back, and instead, I propose the following: I think the quickest and easiest solution to the problem of new players unexpectedly losing their files is adding a feature to the edit program. After saving and/or exiting a file, the shell should print a warning to the player if the computer they're editing on is unlabeled, informing them that they will lose their files if the computer is broken. This warning should also be printed after running pastebin get, and wget get.

This would mean that new ID clearing functionality doesn't have to be implemented, existing programs don't have to be rewritten to use the new ID clearing, and new users will be taught an important rule about how the mod works early on.

I agree with 99-Lives. :)

This (and #437) are one of the fun ones, because in either case you only see the people who it's not working for.

As a bit of background, I used to help out on some CC related discords and servers, and this used to be a constant source of frustration for players. We'd have a lot of people either accidentally or unknowingly break a computer, and lose several hours work (or pester an admin to recover it).

I think this is the crux of the issue here. Players shouldn't be punished for doing things "wrong", especially people just starting off with the mod. Hence the change in the first place and the fact that it's not going to be rolled back.

I propose the following: I think the quickest and easiest solution to the problem of new players unexpectedly losing their files is adding a feature to the edit program.

I don't think this is a bad idea at all. However, I'd rather avoid the rough edges entirely, rather than going "here's a rough edge and how to avoid it".

I believe that this is a documentation/education problem, not a functionality problem. As a new user, the incomplete documentation and lack of any official and up to date tutorials for CC:Tweaked have been the source of far more trouble for me

I know, I know! It's ... better than it was a year ago I guess? _{^{(or worse, as cc.cc's images are broken now)}} Real life does not permit me as much time as I'd like, and writing docs be rather tiring.

If you'd be able to contribute that'd be fantastic. Even highlighting the areas which are lacking is useful - I'm no longer in a position to know what resources are useful for people just starting off with it.

As I've mentioned above, I'm pretty unlikely to roll back this change, so would like to see what other alternatives there are - hence this issue being open :).

The obvious "solution" is a config option. Though this does feel more like a workaround than an actual solution (and, as mentioned in #653, these are always a bit awkward on servers). A similar strategy would be a datapack - I'm fairly sure it's possible to configure a turtle item from a TE with loot functions now.

Ultimately, I'd like to find something which works reasonably well for everyone. But I don't think we've found a good way of doing that yet :/.

Thank you for the response @SquidDev. While I disagree, I appreciate the openness.

I'll make one last complaint about #437, then I won't press the issue any further.

The GitHub Wiki states "CC: Tweaked tries to remain as compatible between versions as possible". I think it's important to acknowledge that CC:T 1.88 , when #437 was released, broke backwards compatibility. It might not have been a Lua API change, but the behavior of computers and turtles as blocks in the game world changed in a way that can break programs that depend on them losing their ID, and becoming stackable.

If you've decided that the pros of this change outweigh the cons, then so be it, it's your project. I rest my case.

If computers will keep their IDs by default, then a method of "clearing" the ID should be added, and this should be a method that allows players on multiplayer servers to choose how their own computers behave.

So here's my alternative suggestion. Computers should get a new boolean property, let's call it keepId, similar to it's ID, colour, and label properties, which control how the loot table behaves. keepId is true by default. If you break a computer while its keepId is true, it will drop the computer with it's ID. If keepId is false, it will drop a computer without it's ID.

#437 makes labels are entirely aesthetic, as they no longer affect if a computer drops with it's ID. If keepId is implemented, I don't think a label being set should override a false keepId. So even if a label is set, a computer should drop with no ID if keepId is false. I think this makes the most sense, but I'm not really fussed either way.

The os API should be updated, with something like os.setKeepID() allowing control of a computers keepId property from Lua, just as you can with os.setComputerLabel(). An accompanying shell program, such as keepid set <bool> to control this should be added.

The Disk API should also updated to control the keepId of a computer in a disk drive, just as it can with the label. disk.setKeepId() After some feedback in the Discord, this doesn't actually make sense, since the computer would have to be placed and broken for it to take effect. But the disk API should still be able to clear a computers ID, and return it to a blank, stackable state. Maybe a new disk.clearID() or disk.deleteID() could do this.

I think this qualifies as something that works reasonably well for everyone. Instead of being a server wide setting, players can control how their individual computers behave. Programs that depend on computers not keeping their ID's will need to be updated, but only a single line should need to be added, such as os.setKeepID(false) or disk.clearID().

The GitHub Wiki states "CC: Tweaked tries to remain as compatible between versions as possible". I think it's important to acknowledge that CC:T 1.88 , when #437 was released, broke backwards compatibility.

Sorry, meant to update this when I saw your original comment and entirely forgot. I've updated the wiki with some information. Feel free to tweak the wording if you think it could be clearer though - I think the wiki is editable by everyone.

Has the idea been considered to clear the ID only if there are no files saved to the computer/turtle? That gives a way to deliberately reset them, and if there never was anything saved, there's no harm in being reset!

if there never was anything saved, there's no harm in being reset!

Unless you write your code into datapacks and don't need configuration data on the things being broken but the other end needs to have the breaking computer to have a fixed id. But this sounds very much like an edge case, and the old behaviour of labels would still work.

What part of the mod is it exposing, and why do you find it ugly?

My guess, that it exposes that computers lose id's and that makes them lose their data (and fuel in turtles). I suppose this is where a crafting recipe that 'wipes' the drive of the computer would be prefered.

My guess, that it exposes that computers lose id's

If that's the case, then the fact that computers have ID's has already been exposed by the tooltips now showing them. It's not much of a jump to add the ability to delete the ID. If exposing ID's is ugly, well, that bridge has already been crossed.

I suppose this is where a crafting recipe that 'wipes' the drive of the computer would be prefered.

The problem with a crafting recipe is that it makes automating ID deletion more complex. Instead of a computer being able to just delete it's own ID, one would need a second crafty turtle to perform the task instead.

The IDs do lean on the 4th wall a bit. (How do all these computers manage to make sure that none of them gets the same ID? And how do they manage to do that while keeping these IDs sequential?) But that's just something that has to be put up with unless one is willing to overhaul how the mod works.

I guess that interacting with IDs in such a way that wipes the computer is a bit like spotting someone behind the magician's curtain and then leaning over for a better look. You lose more of your suspension of disbelief by acknowledging the way that things are working. (That said, MC has always had a bit of a loose suspension of disbelief for me but others may want something more immersive from the mod.)

The problem with a crafting recipe is that it makes automating ID deletion more complex. Instead of a computer being able to just delete it's own ID, one would need a second crafty turtle to perform the task instead.

To be honest it's not that big of issue in my opinion. Making something a bit complex is not a bad thing. It is actually a challenge. It just becomes part of design process for turtle swarms and actually would make whole operation be more grounded. Removing id stops being some magic function call (as suggested in Pts before) and becomes player/crafty turtle opening the computer/turtle case (via crafting recipie) and reseting it to factory state.

Regarding #675 (comment) from SquidDev

I don't really know what to do about #653, but am kinda avoiding it right now because I'm really not happy with any of the proposed solutions. I think it has to be something people opt in to, rather than some heuristic. Any heuristic is going to be wrong and/or confusing in some cases, and so best avoided.

How is the API and behavior Lupus added a heuristic? It's an explicit choice that a user can opt in to, on a per computer basis. Being a Lua API, the behavior is programmable as well.

I agree that a heuristic is a bad idea. The suggestion to clear the ID if there are no files on the computer is too implicit, and would be painful to program within the computer, as one would have to write code that deletes itself at the end of it's job.

Personally, I would have replaced isTransitory with keepID or keepFiles, which better describe the values behavior in my opinion. And I would have inverted the true/false behavior. Setting a value to true to delete files doesn't seem sensible.

The trouble is that I personally see the proposed opt-in systems as kinda ugly. It's exposing a bit of the mod that I don't really want to expose. It's just that some people find that bit useful, and so it needs to be done :/.

What part of the mod is it exposing, and why do you find it ugly?

Do you mean the loot table? If so, this is what labels previously did, so it's not unprecedented. And how else can one implement a solution without exposing the loot table?

I really want to find a solution here, so please, help me understand what the problem is.

The full discord DM relating to this issue:

Lupus59012/01/2021
Sorry to bother you, but I had an idea to solve CC:T PR 504 but I'm having issues implementing it.
The basic idea is that a computer with no label and no files will wipe it's ID when mined, but I'm struggling to get the computer's file system.
How am I best to access (or create) a copy of the current computer's FS in BlockComputerBase.java?
#504
https://github.com/Lupus590-CC/CC-Tweaked/blob/8472112fc1eaad18ed6ed2c6c62b040fe421e81a/src/main/java/dan200/computercraft/shared/computer/blocks/BlockComputerBase.java#L152
https://github.com/SquidDev-CC/CC-Tweaked/search?l=Java&q=filesystem
SquidDev12/01/2021
You really want to avoid creating a new FileMount as that'll scan the whole folder.
Honestly, I'm really not happy with this solution, as it's not just the ID which is lost - fuel is too (also it's unintuitive, but that's more subjective).
Lupus59012/01/2021
I'm hopeing that getcapacity and getfreespace are accesable
I could check that it's a turtle and that the turtles doesn't have fuel
SquidDev12/01/2021
That's just gonna irritate the people who want to be able to stack turtles whenever though.
Lupus59012/01/2021
based on lua testing they return the same on an empty computer
Lupus59012/01/2021
add turtle.dumpFuel()?
SquidDev12/01/2021
But then just do a os.transient() as 99-lives suggested. :slight_frown:
SquidDev12/01/2021
Right, sorry - finished what I was doing so will give a bit more of a proper answer.

I don't really know what to do about the id issue, but am kinda avoiding it right now because I'm really not happy with any of the proposed solutions. I think it has to be something people opt in to, rather than some heuristic as that's going to be confusing and any heuristic is going to be wrong in some cases.

The trouble is that I personally see the proposed opt-in systems as kinda ugly. It's exposing a bit of the mod that I don't really want to expose. It's just that some people find that bit useful, and so it needs to be done :/.
Lupus59012/01/2021
Fair. I'm going to continue implementing the transient stuff just because it's enjoyably and teaching me Java. I'll probably still make a PR.

wouldn't it be possible to have the crafing recipe be just turtle in -> blank stackable turtle out
with no need for any additional resources. only a crafting turtle to do the stacking.

with no need for any additional resources. only a crafting turtle to do the stacking.

It would be too easy to accidentally wipe the turtle when applying upgrades via crafting then.

with no need for any additional resources. only a crafting turtle to do the stacking.

It would be too easy to accidentally wipe the turtle when applying upgrades via crafting then.

Smelting recipe maybe?

I love the idea of using a function call to clear the ID, I think that the reason it seems 'magic' and breaks the fourth wall is because of the name keepID
May i propose that same solution but the function should be named something like: os.erase(), os.wipe(), os.reset(), or os.data_reset(). And of course this call also shuts off the computer and erases the files, the fuel, and the id. If one would implement a shell program for this it should have a confirmation like type 'YES'.

It should also be noted that exposing the IRL internet is much worse than exposing IDs in terms of damage to player immersion, and both are already done.

I already had a similar thing in #675. I don't think that it's the function name that SquidDev doesn't like, I think it's that it doesn't feel like it fits with the mod still.

It might be worth trying the crafting recipe idea, that seems to be the option that he is least objectionable about.

I mean why not just make it so if the turtle is broken with an empty memory it doesn't keep Id? Would avoid accidental wipes and would allow to easily have stackable turtles.

Squid liked automatic id lose event less, I was originally going to do it in the PR I made for the os.isTransient.

See: #504 (comment)

I believe the setting to change the behaviour could be the best.

The craft idea could go wrong if the user had a turtle.craft() system going on.

Another idea would be a new method in the disk api like erase_id() to erase the id of a turtle inside a disk drive or in the computer peripheral api, which shuts down the target computer and erases his id, or the equivalent in the os api for the computer that runs it, since he only gets the id when it is turned on, or am I wrong about that?

Craft with another item which is not used in any normal turtle recipes? Perhaps a redstone torch? Rationale, the torch acts like a magnet to the computer's hard disk.

I think the whole auto-labeling feature was a bad idea, it's made every program I have that uses nested turtles unusable, and having more than a few turtles now is an instant inventory clogger. As much as I hated losing programs while learning how to use the mod, I don't think breaking stackbility is worth it at all.

I have a few possible suggestions:
-Remove the auto-labeling, and add a warning somewhere that explains labels and unlabeled computers losing their data.
-Have the auto-labelling just not apply to turtles, since that seems to be where most of the problems stem from.
-Add a config option for it, so that people who don't want it can turn it off.

Please do something about this soon, I miss being able to auto-place armies of mining turtles.

Equipping a redstone torch and attacking the turtle to erase it?

Or maybe a dedicated tool, like a degausser?

Or something pointy, like a paperclip, to push into the little hole, like CD-ROM drives have?

With all due respect to SquidDev, of course. I don't mean to beat a dead horse.

Equipping a redstone torch and attacking the turtle to erase it?

Or maybe a dedicated tool, like a degausser?

Bad idea: This is too easy to erase it with a miss click and this is the case for all "pick X item and (shift) [right/left] click on the turtle.

Bad idea: This is too easy to erase it with a miss click and this is the case for all "pick X item and (shift) [right/left] click on the turtle.

I was mostly thinking about an action a turtle can do to erase another turtle, but you do have a point about accidental clicks from a player. There would likely have to be a delay before it clears the turtle, like when breaking a block.

edit: grammar/spelling

Upon consideration, I'm happy with the current state of things.

I just think one thing. What about a new item : a "turtle rack". allowing to "stack" labelled turtles and only turtles (like bags, danks, backpacks, ) ? Without inventory it could have two modes : "FIFO (First in, first out)" and "LIFO (Last in, first out)".

Ok, but how would a turtle interact with this item? A lot of the complaints are from people who want to be able to have one turtle pick up several other turtles and transport them (usually for mining setups).

His behavior should be hybrid between itemstack and bucket:

• Try to place it and it will place one turtle (if there one inside) and return itself with the remaining turtles to the slot like a bucket
• When the turtle break/pick another turtle the second one will be add inside like an itemstack (from player view)
• turtle.getItemCount() will return the turtles count (maybe 0 if there no turtle inside)
• and of course turtles racks aren't stack-able itself.

Something similar to os.format() has been suggested already, SquidDev vetoed it.

Why not an os.format() or something like that that erases all data and removed the id from a pc, and then shuts it down?
No accidental erases with crafting, and easy to use and automate