Opencomputers: Possible Nanomachine Redesign

[Vexatos]

Since many people have complained that the way nanomachines currently work is both unintuitive and excessively random/luck-based (which I am not happy with, either), I'd like to hear other people's opinions and suggestions on the topic of a potential redesign. From what I have heard, people mostly want nanomachines to become less luck-based and obscure, generally easier to work with. If you have any ideas on how to achieve this, please comment. For now, the concept of "balance" is not important, although you are of course free to suggest possible ways of balancing potential new mechanics that you or others suggest. Just comment any ideas you might have that could make nanomachines better or less "annoying". And, as I said, completely changing the way they work is very much possible, so please don't worry about your ideas being breaking changes, either.

[Rosethorns]

I think the original design got too caught up in the idea of 'balance' rather than what is 'fun'. If we considered a hypothetical where nano machines were just potion effects and could all be seen without any experimentation, in the current whos who of balance in MC it still wouldn't be considered incredibly overpowered.

Generally because you have to code for it. There is of course the excuse that "Well people could just copy someone elses program" And while that is true and while that does infact happen with other aspects. Sharing and distributing programs is part of the /fun/ first of all and the person doing the copying would still need to know how to import.

At the end of the day there is still at its most basic steps to achieving, in this hypothetical, a reasonable amount of effort for the reward of being able to use digital potions. They cost associated which can be tuned based on testing. And there is room for other mechanics to take place.

End of the hypothetical

The idea here being that I think we need to think about what is /fun/ what is /motivating/ for a user of nano machines.

What I can categorically say is not fun for me. Is testing indexes one by one. Just to strike duds off a list never to be used again. The idea I feel of negative indexes was to add a woops cost element to using nanos. BUT in practice this doesn't pan out. As in the search for positive nanos. Which usually happens in a safe place. The user will experience the negative result. Take note. And never use it again.

This gets worse when you consider that not all effects occur when the player activates the index. Leading to what I feel is an absurd trade off of systematically testing each index in each trigger scenario which would be pain staking and un rewarding at best. OR using negative indexs with the /hope/ the have a positive trigger. OR using positive indexes and wiping them list the moment they find it has a negative trigger.

This is a criticism of the system as it exists now. Which isn't a solution but its a bedrock for what I personally know as being wrong with it. And can be a frame of reference for solutions.

I think if not a total rewrite of the system then a very simple solution would be to give the player a way to know AT LEAST if an index has a positive/negative constant effects AND if it has any triggers, what those triggers are. And if they are positive or negative.

And at MOST I believe outright describing the index would not actually be as harmful to the all precious balance as some are scared it would be.

[MalkContent]

Make them work a bit like the Crysis 1 nanosuit.
You have different boost options, but you can only have one active at a time.

Alternatively you can use all options but have to assign energy to them from a limited pool, so you can chose to spread it evenly or prioritize an option.
Distributing many/all energy points could have a chance of giving you sideeffects.

As to what those options should be, idk.

Also: You should be able to program the nanomachines. They are wireless capable and you can control them that way, but it'd be neat if you could just eat an eeprom/make an eeprom part of the nanomachines recipe to reprogram them. Since this would make them a microcontroller of sorts, you could also have the player have passive wireless capabilities. Maybe the ability to print messages to the players chat. Just minor stuff. For everything else there's tablets.

[payonel]

chat read/write and eating eeproms to program your inner-bot would be pretty awesome

[MalkContent]

Maybe crafting the nanomachines in the assembler to add components. the "powers" they are able to grant could also depend on what you add. wanna have your punches apply wither? add a black skeleton head. this was a bit of an op example and crap, but you get the point. limited amount of powers by limited slots.

Also with the idea of eating eeproms, it would be funny to me if you spawned the old eeprom out of your butt, with a "throw direction" away from the posterior.
You could argue the eeproms should not be able to recovered after eating them, but I say that just makes debugging a figurative pita. With the butt spawns, it could be a literal pita instead :D
Edit: requesting half a heart of damage and villager hurt sound for this x)

[lordjoda]

I think it could be interesting to add still a bit of "randomness" but more predictable. So to add to the "powers" mentioned above it is not always certain that you get the desired effect with a specific item. But you can try which item (and maybe different combinations) result in which effect which then is always the same on the specific server! On another server the same item(s) can result in the complete opposite. Or nothing. Or maybe actually the same. This encourages to not look in the wiki for the best effect but to actually experiment. I mean who knows what these machines are made of anyway ;)

[Vexatos]

I think that effects having both a positive and a negative effect at the same time might be a nice idea (e.g. an effect that provides a potion effect but also makes nanomachines hungry). The bad effect could either be continuous like a bad potion effect to the good one, or an avoidable one like the hungry behaviour.

[Rosethorns]

Strength? Anti resistance (today I learned there is no opposite resistance effect)
Regeneration? Hunger
Speed? Mining Fatigue
Haste? Slowness
Invisibility? Blindness
Resistance? Weakness
I think having set combinations of "powers" with related trade offs would be good. Above I list minecraft buffs with related debuffs. But OC doesn't need to stick to MC buffs.

And I want to discourage the "random per server" thing. While experimentation is fun in concept it gets tedious in practice. Many mods with experiment elements end up having a chorus of people who complain about having to experiment again rather than just dive into the mod unimpeded. After 1 or 2 play throughs people know what is possible. So forcing people to rediscover what they already know exists is frustrating.

If you are going to have a random seeded element I still strongly suggest that it not be obscured. or at the very least take minimal effort to figure out.

I'd also like to say, I like Malk's suggestion of having a limited "pool" of boosts that you can distribute say you have a pool of 10. Regen is worth 8 and saturation is worth 2. or maybe you take resistance at 5, saturation at 2 and jump boost at 2.

Maybe then you can also /actively choose/ to take a negative nano and it opens more room in the pool.
So if strength is 6 and resistance is 5 you can't afford it. But you take hunger for a pool boost and now you can.

I think that could be fun.

Of course it would mean that people would need to play test and tune the costs but thats fine?

[NickNackGus]

I apologize for the disorganized way in which I suggest these various ideas.

I like the idea of revealing what effects each node has, even if it's just a count of positive and negative effects.

I feel that there should be a way to reliably get desired effects from nodes of a nanomachine, but still allow random side effects from those nodes. I do not object to having random effects from nanomachines, however. Perhaps the nanomachines could start how they are now, and they could be modified to have specific effects via a brewing stand, crafting, or some other means.

I like the energy system idea for nanomachine effects, and would like to expand upon it. Any of these ideas can be rejected or modified.

A player might have a meter for how much of their body contains nanomachines - too many nanomachines, and they start experiencing negative effects. With far too many nanomachines, they'd get wither effects, losing their nanomachines if they die while sick. Ideally they would not lose their nanomachines if they die when not sick. Or maybe have the nanomachines "eat" each other. Just keep the player from getting too many nodes available without trapping them in a death loop.

For energy available for effect nodes, I suggest having the player naturally regenerate energy that can be used by nodes, and having nodes consume energy from the pool. This allows players to briefly use far more energy than they can produce, as long as they don't completely run out of energy.

For each node, I recommend giving the name of at least one effect, whether positive or negative, and also having side effects, which may or may not be revealed, as long as the number of positive and negative effects is.

If an effect is positive, it consumes energy, and the amount of energy consumed may vary from effect to effect, or by the level of the effect (eg speed II vs speed I).

If an effect is negative, it may also produce energy. For instance, a node may give the player hunger, but by making the player hungry, it generates more energy for the player to use. The amount of energy generated varies by effect and strength. This makes it so negative effects are actually considered by players rather than ignored outright; imagine you were next to death, and you tell your nanomachines to give you blindness and regeneration IV to quickly get to full health. Since nanomachines reveal the player's health, a connected tablet or built-in EEPROM could detect when such a situation arises and heal you with predictable side effects.

If an energy system is used, then perhaps there should be a way to ingest a battery or similar to boost your energy pool...or maybe not batteries. I feel like suggesting that eating batteries allows you to have cool effects is not the kind of message we want to send to kids. So, if there is a way to increase your energy pool, perhaps it should be a type of food?

I agree that having an EEPROM inside your body to control the nanomachines would be very nice, as it means that you don't need to carry a tablet to automate nanomachines, there's no network delay or other programs using the CPU, and there's no chance of interference from other wireless network cards. If EEPROMs are rejected from being ingested like nanomachines, then I'd recommend reducing the wireless range of nanomachines down to 0, with a special case that they only listen to messages from tablets held by the player that ingested them. Call it NFC if you want.

Any energy system used should be visible to the system that programs the nanomachines.

I like the idea of programmable, modular armor, which could either control nanomachines or duplicate their effects, but I feel like that would be a different topic entirely.

[GoneNomad]

NanoMachines (NM) are a specialized computer system that lives inside your body.

• Your first NM must be combined with a BIOS before ingestion. This prepares your body for NM use. Otherwise, NM just pass through your body. Gives you a base ??k of file space and Energy capacity. (Yes, I watched Johnny Mnemonic recently.)
• Actions are what this batch of NM can do for you.
  
  
  
  • NM need to be smart enough to tell you the major and minor effects of each Action. Effects you are almost able to identify can be revealed after some time in your body.
  
  
  • Having more NM means they are smarter, and better able to tell you an Action's effects
  
  
  • NM can read your body's current status and report on it.
  
  
  • Actions can be labelled
  
  
  • Available Actions can be changed by ingesting/excreting NM (200mB per item). Excreting is somewhat painful, your body can handle it safely once every minecraft day. You get to choose which Action to excrete.
  
  
• You can program NM to check for certain body states, time (based on your age), request information via wireless and (de)activate specific Actions. Available memory is a base ??k (that first NM), added to by the available mB of NM.
  
  
  
  • Program space available as a filesystem with a maximum size.
    
    
    
    
    
    • Actions show as zero-length files with gibberish names (UUID for Action effects), can be renamed or deleted (excreted).
    
    
    
    • Environment variables for global variables (your stats, delay length, current and max Energy, etc) _not sure about this one_
    
    
    
    • Runs autorun.bat every X seconds. More delay saves Energy.
    
    
    
    • Files might be deleted if you lose NM.
    
    
    
  
  
• NM Actions, Intelligence and Energy are based on the amount of NM (_in millibuckets_) in your body.
  
  
  
  • Higher amounts of NM allow for more Actions and Energy (and effect discoverablity), but food restores less of your hunger and saturation.
  
  
  • At higher levels (1200 mB+ of NM), you have to supplement your diet with Grog (food for NM), or die from lack of basic nutrition. Over 2000 mB of NM will kill you outright.
  
  
  • Current nutrition levels can be reported
  
  
• All NM are lost upon death or being struck by lightning.
• Energy is at a set base generation amount plus extra per mB of NM. There is a maximum of Energy your body can take, this slowly increases over time as NM adjust your body for their use.
  
  
  
  • Grog can immediately add to your available Energy, up to your maximum. It is a bit poisonous for human flesh.
  
  
  • Some special NM Actions will add bonus amounts (_they act specifically as a battery for the rest_)
  
  
  • Energy cost per Action is available upon request.
  
  
  • When you do not have enough Energy for all currently active Actions, you will involuntarily sneak, jump into the air and take damage. All Actions that can be disabled will be.
  
  
• Unless you set up some protection, others can talk to your NM.
• Direct communication to NM is possible using a computer/tablet with _NM Interface_ Upgrade and you standing on said computer with no boots or holding the tablet in your hands. (_adds another component with a minimal filesystem_) Not quite fingerprint ID, but close.

• Heavy radiation is a problem for NM. Prolonged exposure to such materials has a chance to mutate an action (add/change/delete Actions and/or their effects, force an Action always on/off, kill off some NM, cause you random damage, etc)

  • With some Actions, prolonged exposure to sunlight causes the same thing. Wear a helmet.
  • Having all of your NM disabled while around such materials will help deter mutation.

• NM can be labelled by putting in BIOS slot of a PC (Don't like it, but nothing better comes to mind.)

• NM can be duplicated by adding original NM with fresh NM in Assembly Table.

  • NM have no specific Actions correlated to them until they are in your body for a minecraft day.

• Actions include 0-3 major effects and 0-2 minor effects. each effect has an Intelligence and Energy level associated with it.

  • A higher Intelligence rating means the NM need a higher Intelligence to tell you what it does
  • Some major effects will exclude any other effects (like the battery above)
  • Special NM will assist in food-energy interface, Energy capacity, computing power, etc
  • Some NM will not be able to be disabled once activated, but may be excreted.
  • Rare NM will turn themselves off after a certain period of time (a minor effect).
  • Some pre-configured NM might be found as loot.

I don't have any more time to go into various effects. That can wait until later.

Haven't decided between a list of preset Actions and random collections.

I want to be able to use a tablet to access my digital memory, act as an interface for it to get more information about the world. I want my NM to look for certain wireless connections and interface with them. I want to have my NM Interfaces decrypt my internal filesystem according the hash I set.

Later on, advanced versions can be implanted in animals. No good will come of it.

[NickNackGus]

Come to think of it, there's a simple way to implement security for nanomachines if they're going to use an EEPROM. Add a craftable default nanomachine BIOS that does wireless communication, maybe have it flash automatically if it's blank when crafted into edible form if that's how we want to "eat" the EEPROM. If you want to add security, then you need to come up with your own security system and either eat a new EEPROM, or eat a programmed eeprom in the first place. This also means you can disable wireless communication to your nanomachines altogether.

Oh, and in case someone reads the GoneNomad's suggestion for files as having some sort of mass storage eaten or something like that, I think GoneNomand is thinking of how their favorite Unix-based OS treats hardware nodes - by creating special files that can be controlled via standard I/O commands. They don't exist on the actual hard disk, but exist in RAM, and can be read or written as normal text. This still leaves the matter of renaming those special files, though. I'm not sure how the implementation of that would work.

Either way, I'd say that the environmental variables like health and whatnot that they suggested should be available as functions, similar to how the energy in a computer or robot is accessed via functions. I like the idea of accessing these things via files better, but Lua seems to be more function focused than I/O focused. I'd love to see file-based I/O for more hardware in OpenComputers, but I don't think we're likely to use that approach. Still, having the effects as files does make it easy to remove the ones you don't need; perhaps they could be some sort of library files so they can be "included" from Lua code instead of read and written as normal files.

[PongWithBreakout]

I have some idea about nanomachines' mechanic: what if nanomachines can... learn. Instead of random effects or programming you need to learn nanomachines by drinking potions.

[skyem123]

While learning might be neat, what would the other non-potion effects work?
Unintended side-effects?

[NickNackGus]

I imagine learning non-potion effects would work by getting the effect through other means - the only way to get haste would be to stand in range of a haste beacon, for instance (unless a mod adds access to a haste potion).

Here's a silly extension of the idea: consider milk an effect. If you want to clear all effects with one command, apply the milk effect.

[PongWithBreakout]

Hmm... Well, some non-potion effects such as Haste and Absorbtion can be got via other ways that potion, as NickNackGus pointed already. But now I curious how to handle a magnet and Disintegration with learning system.
But from a beginning I wanted to say that learning isn't a immediate process: it takes some time. And for successfully learning a "sample"(i.e. potion) should be provided for all learning time. If potion is over while a learning process isn't over then some side-effects will be presented(or, if sample was too short, learning will be unsuccessful)

[Darinth]

So I was originally coming here to make the simple request to at least be able to implement some form of security on nano machines, even if it meant a more 'expensive' variation of nanomachines. I'm was happy to see that they're up for a potential redesign and so I started running through different ideas on how this would be best accomplished.

This is what has come to mind in the past couple of hours looking through OC code and thinking. I unfortunately don't know Scala, but I was able to piece together enough of it to be able to make a lot of sense.

1: There's no longer a single 'nanomachines' recipe, instead treat nanomachines similar to potions. You drink nano machines in order to make a functions available. So, you could drink 'fire resistance' nano machines in order to make that particular function available. You could then drink fire/temperature detection nano-machines to make the function to detect if the player is on fire available.
2: Nano machine control could be handled in a few different ways.
A: Consuming 'wireless nano machines' would then add nano-machines that could be wirelessly controlled via a table or any similar device. I'm still going to advocate for some kind of security or at least the basic ability to provide a way to send a signal to your nano machines and not potentially interact with someone else's nano machines. Even if it's just telling nano machines to listen on a different port that'd be simple and fantastic. These nano-machines can then relay commands to all of your ingested nano-machines to turn them on/off.
B: Controller bauble. If baubles is installed, a charm, amulet, or ring could be programmed to act as a controller. The item would have to be preprogrammed (probably be installing a flashed eeprom into it) and it would allow you to run programs that interfaced with your available nanomachines.
C: Controller nano-machines. Programmed similarly to the bauble, but consumed rather than worn. It then runs just like any other portable device and has access to your nano-machines.
3: Different types of nanomachines have different requirements, many of them will simply wear out naturally through use.

Functioning example: I craft and consume regeneration, instant health, fire resistance, health monitoring, and fire detection nanomachines. I then program a batch of controller nano machines to basically do the following: If my health gets below 16, activate the regeneration nano-machines. If my health gets below 10, activate the instant health nano machines. If I'm on fire, activate the fire resistance nano-machines. As long as high-level variations of these nanomachines that could provide more powerful buffs don't become available, the the effect nanomachines have a very limited number of uses before wearing out, or some other limiting factor it should be balanceable.

Reference:
Effect Nanomachines, provide an activateable effect:
Potion effects. (It's probably easy enough to just make crafting these nano-machines require a potion and inherit the potion effects of whatever potion they're crafted with, but that does prevent some status effects from being obtained such as levitation)
Magnetization.
Various particles, because why not.
Perception. Provides the ability to provide a HUD, make noise, etc... that are only visible to the player. Mostly useful for providing feedback on your nanomachine status.
Block placement.
Block breaking.
Ender access (Inventory management with access to your ender chest, or a specific ender chest from the mod of the same name if installed. This is where I'll store your extra torches so I can get you more when you need them.)

Monitor nanomachines, provide queryable effects and events for controlling nanomachines:
Health.
Hunger.
Oxygen.
Presense of various status effects
Location (would have to be relative to waypoints or similar).
Velocity (Downward velocity exceeds a certain threshhold? Sounds like a good time to burn those absorption and/or instant health nanomachine).
Motion sensor (Danger Will Robinson, Danger!)
Object recognition (Inventory monitoring. Dude, you're almost out of torches. Let me fix that for you.)

Other nanomachines, nanomachines that don't fit into another category:
Control nanomachines. 'Brains' for a group of nanomachines. These are the only ones that can actually run a program.
Wireless nanomachines. By default, these wireless nanomachines listen on port 1 like a wireless computer and accept commands.
Neural Interface. Can be setup (via control/wireless nanomachines) to make a UI wheel available to the user. Events for wheel selection need to be listened for by control nanomachines or wireless messages need to be listened for and acted upon by a wireless device.

In the background, I suspect that this will basically treat the player almost like a drone in many ways. Eating control nanomachines will basically flash your character's eeprom. Eating various nanomachines will make additional peripherals/apis available.

[Darinth]

Probably a reasonable method of balancing them is to consume xp upon eating nano-machines in a method very similar to how enchanting works. Must have x levels, and will consume Y levels. Either have it so that each set of nanomachines you consume costs progressively more or make it so all of your nanomachines have to be mixed together in a batch and consumed at the same time, with a formula to determine the total minimum level and level cost for a particular batch of nanomachines.

[Saklad5]

I would really like a programmable HUD for the player. When I first saw nanomachines in the guide, I was really excited because I was hoping they’d add that.

Imagine being able to monitor elements of your base without sticking around, or getting live feeds of arbitrary variables. My current solution to this consists of sending HTTPS packets to my Apple Watch upon certain triggers, but an in-game option would be quite nifty.

[xarses]

@Saklad5 You can program a HUD using OpenPeripheral Glass or OpenGlasses, each have different trade offs

[Shazuli]

Not sure if this is still an open debate still, but here goes:

I've read through a few of these, and I really like the idea of eating an EEPROM. Here is my idea: Let's say instead of 10-20 ports, how about 200 ports? I'll call these "nerves" for now. Rarely does a single nerve give an effect, but up to maybe 10 nerves activated at the same time can give a effect. My idea with the EEPROM is that you program it so if it gets n signal it will activate this, this and this nerve.

And for research. Instead of doing one at a time (200^200) you can get data back from them similar to how you get back hunger and health points. This will give hints what nerves you have to activate to get the desired effect. Maybe I want Regeration (10 is the ID for Regeration):
modem.broadcast(1,"nanomachines","data",10)
Then the nanomachines will activate different nerves, first at random, but after a little bit, it will begin sending small wireless packages with maybe 10-15 different nerve IDs (e.g 70/112). Then it's up to the player to find which of these 10-15 nerves are the right combination to get Regeration. Then he/she has to program a EEPROM, maybe a simple table with the name of that table as port-name you need to call to activate with the content inside be the nerve IDs you have to activate to get Regeration:
EEPROM:
port1 = {10,89,15,189,3}
Lua Terminal:
modem.broadcast(1,"nanomachines","setInput","port1",true)

The player can add as many tables as he/she wants inside of the EEPROM, but the storage space is limited as we all know, and too many nerves can cause too stress on the player's body. And as for not wanting to re-discover for each new world/server: How about the which nerve-combination is determined by the player's name, which should be different for each player. So you have to do your own research, but how you activate the table ports are up to how good you program/steal/borrow.

You can keep on improving how good a certain effect can be, Regeneration can be researched again, and again. Maybe one can activate Regeration with only three nerves? And this can activate Regeration II with eleven nerves.

This system would give an almost instant way to get your effect, but you can keep going however long you want for the ultimate version. This also will make sure you don't have to re-invent the wheel every time either. Maybe a server can change the random seed generator, but it could be kept the same for every server/world. And by going for the potion ID you can also (if whitelisted) research other mods' potion effects.

There we go, did you read everything? Nice! I would love a system like this in OC! From a guy who has played his fair bit of Thaumcraft over the years.

Edit:
It would be neat if this wasn't just limited to potion effects. Maybe they can enhance your hearing to get a mobs' relative position if they make a sound. Show animations only you can see (particles, cloud, wave, etc.) similar to OpenGlasses' Terminal Glasses, but a much more unrefined, blurry version relative to the player's position (a hallucination happening on your optic nerve). Play sounds only you can hear (computer.beep()). Write/read to chat.
These sensory enhancements could be like an on/off switch when active, sends a event signal with you as a medium. Maybe you can add a function in the EEPROM that can be bound to that event name similar to event.listen().

And another idea I just got: What if the Nanomachines are useless without the "Controller Switch". It goes on the outside if your body that can be attached to maybe your back or back of your head. This is the thing that tells the Nanomachines what to do and gets input from them. This needs power to work, but can be charged by just standing beside a Charger, and can be programmed by inserting a EEPROM into it.
The amount of nerves you can activate depends on the amount of them you have in your body, so drinking more of it will add more to your body. Maybe you will slowly lose them as they are burnt out, malfunctioned from damage, exited your body in "various" ways. Maybe there is a chance if you have taken damage from something, that they have malfunctioned. So they can cause more damage to your body or cause unexpected side-effects. The number of broken Nanomachines will accumulate inside your body, but they can be removed by sending a function to the Controller Switch to "flush out" them, but this will also flush out working ones too (not everything, but maybe 15-25% of all the nanomachines you have in your body), so it's up to the player how fresh he/she wants his/hers Nanomachines to be.

[Dory05]

Since the core of OpenComputers is "Highly configurable", I would think that the nano-machines should have a core system, and then the balance can be left to the modpack maker or player. The way I would suggest doing this is by making the nano-machines a more expensive option to justify their immense benefits. You would be able to put the case in the assembler, then add certain components to be able to interact with certain parts of the body or other computers; a wireless card for wireless interaction, a GPU for interacting with the optical system (Showing GUIs, marking things, etc.), and an Angel Upgrade to allow the nanomachines to move around in the body, allowing potion effects and such (The last one may not be the best idea, but you get the point).

Programming it would be the same as a Drone, using an EEPROM to create a basic receiver program, and a wireless device to create a sender program. For example, let's say the nanomachine has a program that will trigger a potion effect when it receives a signal on port 1. When ingested, the nanomachine will begin to listen on port 1 for the message, and when it does, it fires the potion effect. This will consume energy, and when that energy is depleted, the program pauses.

The balancing would be done by changing configs, for example, determining what items give what access, how much power each function uses, etc.

[shadoxxhd]

Another solution would be to let users grow their NM neural network.

TLDR: change the neural network to a hopfield network, and make it editable

Every time you eat nanomachines, a few random neurons are appended to your NMNN.
You can see the overall network architecture of the network (connection table maybe?) and power individual nodes. As soon as a node is powered, you get the lvl1 version of that effect (-> you know what it is). Depending on the connections to other nodes, they might activate as well - you will always be able to predict the activation depending on the network weights.
The network itself could be either a self-training hopfield network (binary activation network that is attracted to memorized states (memory network) and can be trained by simply force-activating (clamping) your prefered pattern for an extended amount of time) or some other type of recurrent network. Non-recurrent (feedforward) networks would be harder to extend dynamically.

Balance
Training and building the network should be hard/expensive, while running it should be relatively cheap (high initial cost, low running cost).
Training costs could include very high energy consumption, material resource consumption and strong negative effects (poison/weakness/slowness for a relatively long time).
Alternatively, the network could be untrainable but surgically modifiable, allowing you to 'burn out' unwanted nodes (connectors or effect nodes). This would be more random, but would ultimately also allow total customization if enough effort is invested.
These approaches could also be combined by limiting the degree that a network can be trained, while allowing burn out of completely out of place nodes (eg. connections have to stay inside a certain range).

Since energy cost should scale greatly with active controls, and only slightly with active effects, having fewer trained combinations means more stability, while having accepting the steep energy cost of direct control would allow you to skip training (and train the network to activation patterns you like in the process).

Stronger effects should require more active nodes of the same type - depending on other balance choices, either linearly (3 speed nodes -> speed 3), exponentially or 'minigame-based' (see below).

Customizability
A hopfield network could simply be trained to support several stable activation states. Adding nodes would make the network more complex, but once trained also more stable. Strong effects should always require relatively large networks (no single node resistance 5).

Challenge
The easiest option (trainable network) would not require a lot of effort once some level of understanding is reached, but would still be educational and interesting.
If the network doesn't train itself automatically, users would have to engineer connection weight changes to get the desired network by themselves. This would be a larger challence, but could be annoying depending on how the interaction is implemented (large networks could have tons of weights needing adjusting).

Non-trainable networks would require more planning concerning which nodes to cut out, but the network might be unusable inbetween trimming actions unless improved strictly incrementally (which would be resource inefficient). This could be good or bad, depending on desired balance.

Optional: Complicating Minigame
If engineering stable activation states in a hopfield network alone isn't interesting enough, higher effect levels could be achieved through a more complex interaction of active nodes than simple effect stacking.

Effect nodes would each have an (randomly generated) assigned number, and to improve the effect you get you'd have to optimize some non-trivial function of the active numbers. This could be as easy as requiring the sum of all values to be as close to a certain threshold as possible without crossing it (effect level would be either 1/(threshold-sum), with negative effects beyond the threshold, or number_of_active_effect_nodes/max(difference_to_target_level,1) (or some function of this, like ln(~))), or as hard as the nodes needing to be activated in a certain rhythmic pattern.

[L0ckloop]

I agree with GoneNomad but I need to add something. How about when you add nanomachines you treat your body like a computer? For example, after some days, the nanomachines dig out ports that you can connect to. Oh, and you can connect to your body with a special block to a computer. Maybe make all computer items edible, and to take them out, you use a scalpel to take it out, but you lose health for every item you take out. Also, use an assembler to create the nanomachines to create it with your components. Oh, you can add as many upgrade containers/disk-drives/etc (oh and just make screens and keyboards work with container slots) as you want, at least until your inventory gets filled because containers take up inventory slots. Oh, and you can access screen through the inventory. Finally, add upgrades meant specifically for the body. Pretty much, you’re a cyborg. Oh, and anyone can access your body if you don’t have security, which means they can mess directly with all your functions including health, heart-rate, and even take control of your whole body. You can access your body with component.body and body.(...). Oh, and create a Hard drive/eeprom hybrid for higher tier nanomachines and computers, maybe you can partition the EEPROM/hard drive and make partitions read-only. Oh, and lower tiers use the EEPROM. Finally, while you can interface with a screen, an upgrade would allow you to interface with the optical nerve, controlling your sight.