Rebalance Robotic Modules + tools

[Frank_Stein]

There's a practical limit on module tools I reckon because if you've got too many it'll be hard to switch between them in reasonable time.

perhaps there could be a better system for switching between preferred tools rapidly, such as a nice big tool menu that pops up in a few lines along the bottom, just above the rest of the ui, rather than the current small side-menu that must be scrolled thru with the arrow buttons

I personally like the idea of multitools, but as for another fast method, how about having something like three configurable presets? Stick 3 tools in one preset, another 3 in a second, and then press a hotkey plus a number key to swap between them?

[Noah Buttes]

I'll start work on the patch this Saturday, so try to get all your ideas fully fleshed out before then.

Personally material code with regards batteries could have a look at, seen as many "fuel" sources don't actually create a functional battery (nooooaah)

I am terrified of touching materials code again without being able to see the live code.

I'm not 100% how much of my patch got implemented, but I am 100% sure that changes have been made since then. I am also 100% certain that material code is an ungodly mess and would rather fully rewrite the damn thing than just keep slapping band-aids on it.

[misto]

o yeah

more bots should have fire extinguishers. especially medibots, since directly helping people not die is part of their job, and putting out someone whos on fire is a good way to help them not die

[ZeWaka]

I am terrified of touching materials code again without being able to see the live code.

I'm not 100% how much of my patch got implemented, but I am 100% sure that changes have been made since then. I am also 100% certain that material code is an ungodly mess and would rather fully rewrite the damn thing than just keep slapping band-aids on it.

Honestly the only changes that have been made since then have been by you by proxy of me. All of your patch has been implemented except for one part which is still being balanced/fixed/integrated.

[Noah Buttes]

I am terrified of touching materials code again without being able to see the live code.

I'm not 100% how much of my patch got implemented, but I am 100% sure that changes have been made since then. I am also 100% certain that material code is an ungodly mess and would rather fully rewrite the damn thing than just keep slapping band-aids on it.

Honestly the only changes that have been made since then have been by you by proxy of me. All of your patch has been implemented except for one part which is still being balanced/fixed/integrated.

Oh!

Well then!

I'm still going to hold off if I can help it, though.

[Sundance]

o yeah

more bots should have fire extinguishers. especially medibots, since directly helping people not die is part of their job, and putting out someone whos on fire is a good way to help them not die

A good idea, especially seen as quite recently I ran into this problem as a mediborg myself. [added]

I'll start work on the patch this Saturday, so try to get all your ideas fully fleshed out before then.

I've already sprited an omnitool (it looks like a swiss army knife doo-dad) and am working on the unilyzer. Most of the sprites are just robotic versions of their counterparts. I'll add them to the op when I'm happy how they look.

[misto]

does the civbots storage tank or some other tool allow them to apply grow formulas and other nice things to plants, or is that going to remain the sole province of human botanists

the medbot will need a stapler to finish limb surgeries, if drag+drop will finally let them attach limbs to ppl

i also wonder what will happen if a human is inside a crate inside the crate storage and they try to move. will the whole borg pop open and everything spill out? will it act as if the crate had been welded shut? what if the person starts flipping to break free?

[Sundance]

The chemistry side of things we'll leave to the chemborg. The storage tank for the civborg is to facilitate the janitorial side of things, but also for a general purpose, such as botany and hobo chemistry.

I'll add the stapler, that for sure is needed for the mediborg for him to do his job. I'd recommend it being of limited use. 30 staples (the standard?) is more than enough, and it stops rampant abuse of it as mediborg already has the ability to ruin someones day with the surgical laser.

Your last point is up to the community which is why I left it ambiguous, so feel free to share your opinion. I think it should plainly bust out of the crate and thus out of the borg. And yes for purpose it probably should act welded. The whole ability for mining bot to have a crate has a bunch of uses: It can take abandoned crates, it can collect stuff in space, including retrieval of corpses or stranded players. It also has room for nefarious purposes.
I should probably be a bit more clear; i'd like for it to work exactly like a pod storage, that way you can collect artifacts too.

[Erik]

Why not get rid of the module system as a whole, and refactor it into a upgrade system like we currently have, adding smaller upgrades such as "discount dans chemistry kit" that basically adds a set of tools and drains some extra battery when it's enabled.

[Roomba]

The last time this was implemented, it was absolutely terrible. Researching tools took up most of the round and involved looting multiple departments, and putting together a module even on par with the basic modules took up nearly the entire round.

Even if those issues are resolved, you still run into the fact that unless robotics (and with the recent materials update, mining) are fully staffed with competent people, roundstart borgs are pretty much crippled unless someone devotes their round to bringing them up to par with what an average assistant could accomplish in five minutes of work.

[Noah Buttes]

Why not get rid of the module system as a whole, and refactor it into a upgrade system like we currently have, adding smaller upgrades such as "discount dans chemistry kit" that basically adds a set of tools and drains some extra battery when it's enabled.

The last time that was implemented, it turned into a giant clusterfuck that was incredibly unfun.

Nope.

[Frank_Stein]

Whoa now, the problem with the last Robotics attempt was round start borgs were significantly nerfed, and the research method was unwieldy.

I think it can definitely work if ironed out more. The progression scale just needs to be adjusted from unfun-okay-fun to okay-fun-lots of fun

[Noah Buttes]

Whoa now, the problem with the last Robotics attempt was round start borgs were significantly nerfed, and the research method was unwieldy.

I think it can definitely work if ironed out more. The progression scale just needs to be adjusted from unfun-okay-fun to okay-fun-lots of fun

The issue with a system that permits a high level of customization like that is that it is incredibly difficult to balance properly because you have to account for a whole spectrum of different variables at once. In comparison, the fixed module system is comparatively easy to balance because it enables the adjustment of discrete, quantized packets of tools rather than adjusting the whole massive system at once.

Here's some balance considerations regarding cyborg tools, points in bold are present in both the current module based form and the proposed progressive form.

• How strong is this macguffin by itself, that is, independent of its interaction with other macguffins?
  
• How strong does this macguffin become when used in tandem with this other macguffin?
  
• How does the possession of multiple macguffins, while not necessarily being used in tandem, affect the overall utility of the macguffin user, hereafter referred to as the macguffiner?
  
• How does the usage of a macguffin by a macguffiner affect its target, hereafter referred to as the macguffinee?
  
• In relation to time, how quickly should a macguffin of this strength be available for use to the average macguffiner?
  
• In relation to expenditure on the part of the macguffiner and/or the macguffinee, what amount and type of resources should be expended to produce a specific macguffin?
  
• How quickly should the macguffiner/macguffinees be able to acquire the resources to make a specific macguffin?
  
• How strong is a particular macguffin in relation to the typical strength of the assembled body of macguffinees at the point in time where the acquisition of said macguffin becomes feasible or likely?
  
• If this macguffin is too strong, what trade offs should it have to balance this strength?
  
• Are the trade-offs of a macguffin capable of being reduced, eliminated, or converted into strengths by other macguffins?
  
• How does the order of macguffin acquisition affect the level of utility and/or enjoyment provided by said macguffins to the macguffiner?
  
• How does the order of macguffin acquisition affect the of utility and/or enjoyment provided by said macguffins to macguffinee?
  
• Is a specific combination of macguffins likely to result in unintended side effects to the macguffiner?
  
• If yes, will these side effects negatively affect the assembled body of macguffinees?
  

If that's too much, I can make do with an analogy.

Editing the modules is like tuning a guitar. If one of the strings is off key, you fix it. You'll have to tune the other strings eventually, but it's not really a big deal.

Editing a system that permits customization is like tuning a piano. If one of the strings is off key, you have to call in a professional to tune ALL the strings. Granted, the professional tuning lasts a lot longer, but it's a hell of a lot more expensive, time-consuming, and laborious. Plus, if the professional fucks up, there's several tons of pressure on each of those piano wires, so you can kiss your piano goodbye.

Basically, it'd be an arduous ordeal of testing, receiving feedback, rebalancing, and testing again that would probably drag on for months.

It'd be even worse if it were implemented as a patch, because then feedback is limited until it actually goes live. Then some coder unaffiliated with the patchmaker has to field all the inevitable complaints and either address them directly or hand them off to the patch-maker to start slogging through fixing it.

I can only think of a few active coders who might be patient enough to deal with that mess, and one of them is busy wrestling with atmos code.

[ZeWaka]

giant effortpost

What a great explanation of the challenges of balancing. I can't even come close to contributing anything else.

[Frank_Stein]

I think one way to approach it would be to tie it to the modules, with branching paths.

Standard borgs would be more versatile at the tasks involved with their module specialization, but would have the option to further specialize in a related task, at the cost of becoming less of a Jack of Trades

An example, medic borgs specializing in healing down one branch, and surgery down another

---

A basic medic borg could do a bit of both and be okay, an upgraded borg could do one or the other phenomenally