Modular Machines

[BlueScope]

More or less a grand unification of the Integrate Electronics, Modular Computers, Assembly, , NTNet modules, and perhaps Hacking - with bonus points for gathering all machine/computer construction under the same umbrella. This, in addition to the return of a much more streamlined, and less abusable, Scripting module. Make them all work and play together, and expand options.
I realize that this would be ridiculous in scope, even for multiple coders working together religiously, to the point of me posting this thread being pointless. I’m slowly warming to the idea of returning to coding, and the above modules would likely be the first ones I look at - with the eventual goal of the described unification. So, I’ll use this thread to collate ideas for how such a module would work, and what features it would have.

I’ll post notions ITT as they come to me, but I’m looking for thoughts regarding the following:

• Additional Integrated Electronics components, assemblies, and so on
• IE components that need fixing
• Modular Computer parts that would be fun/useful to have
• Potential hazards/benefits of reintroducing the Scripting module
• How one would remove the many exploits of the Scripting module
• How each module could integrate with the others
• Anything else relating to modular systems that are already in the code
• Which aspects of these modules should be the highest priority in fixing/adding/tying together

[BlueScope]

A few IE component ideas. Some are mine, some are other’s.

• HREF Interactor
  This component would be used to interact with HREF (Menu) options in various machines, computers, and so on. It’d be extremely tricky to implement and balance. Would this be too powerful? How else could the modules described in the OP interact with existing machines/computers?

• Damage Detector
  A very, very simple addition to the IE module. It would accept an object REF, and output the integrity and max_integrity variables. I would suggest folding this feature into the Examiner component, but it’s already pretty robust as-is.

• Gene Scanner
  As opposed to the Plant Gene Scanner. A way to start interacting with the Genetics module.

• External Reagent Scanner
  As opposed to the existing Reagent Scanner. Essentially, it would serve as a Health Analyzer, set in “reagent scan” mode. An “Advanced” version could act more like Science Goggles on “reagent scan” mode.

• Floor Bolts
  Essentially an automated implementation of wrenching an assembly up and down.

Additionally, there should be some features that could be added IE assemblies.

• ID Lock actually locks the assembly, making it unable to be opened with a screwdriver. There would have to be a way around this, perhaps with some kind of hacking?

• Assembly types that are “solid” (cannot be walked through)? For a high metal cost. Too robust? Input appreciated.

[BlueScope]

I had this notion in the Hacking Rework thread, and it struck me as an excellent way to implement the Scripting module in such a way that would make it accessible, flexible, but leave it unable to be abused.

A tool would be created, and when it is used on an open machine, a menu would appear. The menu would be an abstraction of the logic of the machine, laid out in terms of “instructions”. By clicking and dragging, one could introduce new “instructions” into the machine’s logic, or change the order of existing “instructions”. One could potentially save a desired “instruction set” to some kind of disk. Available “instructions” would be generated based on the particular machine type.

This logic could expand to cover damn near every machine, computer, and technical object in the game. To increase the modularity of this idea, available “instructions” would be dependent on what components compose a machine, rather than the machine itself. My primary concern would be a drastic increase in required server processing power, potentially.
Instructions would be laid out in a list, one after another - to compose a Set. I’ll post an image abstracting what it would look like later.
I’m actually quite excited by this idea. It would create an entirely new branch of Science - Programming. One could shove it into Integrated Electronics - in the form of a “Processing Chip”, and into Modular Computers. I’m thinking Modular Computers would serve as the “tool” mentioned above. It has none of the weaknesses of the old Scripting system, and all of the strengths. Would really appreciate feedback on this one.

[BlueScope]

Here’s the abstract menu layout for “Instruction Scripting”.

1 - Instruction Type Selection
Particular types of instructions would be divided into different categories, which can be cycled through utilizing the left and right arrows.

2 - Available Instructions
These are what would be clicked and dragged into the Instruction Set to create new or different functionality. Up and down arrows to cycle through the list of options under a particular category. As I said above, available instructions would be determined by the components of the device.

3 - Instruction Set
The functional instructions which dictate the behavior of a machine. Up and down arrows to scroll through the Set. There would be a GUI option to quickly delete instructions in the set, and one can click and drag to move them around. The maximum amount of instructions in a set, the speed at which they are executed, and so on - would be determined by the components of a machine.

4 - Instruction Number
Used to reference the order in which the Instruction Set is executed. Also could be used as variables in some instructions (for instance a “Jump” instruction that sets a particular instruction number to execute next). Could also be used to change the order of the instruction, in a similar manner to how one changes the position of a component in an assembly, in the IE module.

5 - Input/Output Box
Instructions would require alterations of internal variables, generally. This is where that would occur. Additionally, as a Set runs, any output could be displayed here. Additionally, it could be used to display run errors. Sets with errors would not execute more than once, to preserve server processing power.

6 - Save
If connected to a device with memory storage, save the current Instruction Set

7 - Load
If connected to a device with memory storage, load the selected Instruction Set

8 - Exit
Exit the GUI

I additionally forgot to include a “Run” button, which would execute the Instruction Set. I’m sure I’ve forgotten other things as well. Thoughts on this system?

EDIT: There should probably also be GUI options to jump to the top and bottom of the Instruction Set list. The “Run” menu option would toggle to “Stop” - allowing the Run to be cancelled. In order to edit the Set, it’d need to be “Stopped”.

[VeteranKyl]

I really like a lot of these ideas. I’m always for adding more customization and experimentation. One thing of note that may need some careful balancing is the HREF Interactor. Perhaps a potential test of that feature could be to implement a more slimmed down version. Some machines only require a single click to interact with them, so maybe an ‘operate’ component could be created that either does a single click action on an object, or uses an object on another.

[BlueScope]

Hmm. Yes. Agreed. I’m envisioning a text data input pin in the component, which specifies which function of the linked machine/computer is activated. That’d shift the component from utilizing a blacklist, to utilizing a whitelist - which is far more safe. Also, there’d probably be a rather long cooldown and high power cost for it. The only issue would be the likelihood of some aspects needing to be hard coded, which is a pain. This kind of thing needs a huge degree of flexibility.

[VeteranKyl]

Which is why I suggest a stripped down version that just acts like a mouse click. Don’t know how hard it’d be to code a bot to emulate a player clicking something, but it’d hopefully be easier than having one that interfaces with a machine.

[BlueScope]

Clicks are processed in terms of HREF’s. Activating one would be like clicking.