Feature Request: User definable properties for network components

[llamaizing]

I've seen a number of example scripts where properties for a network component are embedded in the nickname string of the component, e.g. "Storage 14 3000 5000". This is an inelegant and confusing way to handle assigning properties, so I am suggesting something better.

From the info window of the network manager tool, I propose allowing the user to define a list of properties for a given network component. Each property would have a key and a value, both strings. These would be totally arbitrary and up to the script to determine how to use them.

Mockup of what it might look like in the network manager info window:

Lua scripts would be able to access the values of the properties with something like my_network_component:getProperty("max_storage"), where the key is passed to return the value. Also could be my_network_component:getProperties() to return a key/value table of all the defined properties.

Scripts could set property values with something like my_network_component:setProperty("max_storage", "3000"), passing the key and value to be set. If a property doesn't exist with the given key, then a new one would be created. Setting a value to nil would remove the property.

[Panakotta00]

This more or less reduces the usage of other stuff like drives. Remember its not a mod that is made to make stuff easy. I'm not a fan of storing data in those components generally, the proposed nick solution is just to satisfy the people who really not want to go deeper. A better solution is to store the data at a computer. We could then propose a new handheld tool to make it easier to do changes, best would be a computer as you know it but as item. Then you can create a system that does that what you described and much more. For now, either you use the hacky nick solution, or the better storage on a computer and you store the stuff there. And I doubt a system like you described will be added.

[alonsobustamante98]

I believe this idea has some merit though. I'm thinking of perhaps including a Lua module for SQLite or similar? or some NoSQL? I confess it would be pretty handy and it has actually ocurred to me before as a feature. Any thoughts on this solution?

[llamaizing]

This suggestion is not about making things easier. It is about keeping things organized and less confusing. The current system of encoding variables within the nick is honestly a hot mess.

The implementation of how the information gets stored is not so important to me. Storing it all on a computer is not a problem.

I can even implement most of this myself in lua. The part that I cannot is the interaction through the network manager handtool. Namely knowing which network component the player queried through the network manager handtool, and being able to add a custom menu to the handtool's menu. Perhaps the simplest approach would be to add another tab to the network manager's menu that is just a screen controlled by a user-created script.

@alonsobustamante98 I'm not seeing the connection to how having an SQL module pertains to this feature request.

[alonsobustamante98]

I'm not seeing the connection to how having an SQL module pertains to this feature request.

I admit I don't remember what I meant specifically regarding its relevance. I've been sleep deprived at the airport when I wrote it. I still am, so kindly forgive me if I don't make complete sense.

Anyway back to this. In my opinion, this mod can afford such a "simple" convenience feature as far as I can think. Like, Panakotta himself has been developing visual coding as an alternative to Lua! This is comparatively minor, no?

What I believe could be a middleground to make a code-first database or something would be to show JSON stuff or Sql columns in the interface of the Network Manager in a similar way to how reflection of in-game assets is shown. It would be

• convenient
• more organized
• increase the utility of the Network Manager
• Aid the not very experienced programmers
• Still be mainly interactable through code.
• Quench my desire for a REPL a bit.

The way it would be managed by the users of the mod would be through SQL/NoSQL or basic Json manipulation. Maybe? Idk. It would obviously be saved in a hard drive in a "server" of sorts (perhaps one that has to be wired up to the Network Manager wirelessly or idk, like a server).

I'll edit this post after I reach Spain if I find it could've been clearer or smarter. I just wanted to throw this out there cause I'm obsessed with this mod and couldn't wait.

[RozeDoyanawa]

This more or less reduces the usage of other stuff like drives. Remember its not a mod that is made to make stuff easy. I'm not a fan of storing data in those components generally, the proposed nick solution is just to satisfy the people who really not want to go deeper. A better solution is to store the data at a computer. We could then propose a new handheld tool to make it easier to do changes, best would be a computer as you know it but as item. Then you can create a system that does that what you described and much more. For now, either you use the hacky nick solution, or the better storage on a computer and you store the stuff there. And I doubt a system like you described will be added.

I know what you mean, but I must agree with op. When I set up my hypernet for example, I need programatically find all the components relating to the system, then I need to sort out what power switches do what, how many interconnecting tubes there are, if there is an entry or not. All this have to be encoded in the nick-name for now. OR I have to make a table on a disk with ids and their properties. But the computer can be half a map away from the hypernodes, so changing this information becomes near impossible if in a table. You could argue that I should build one computer per node, and use routers, but give how much system resources each computer takes, I prefer having larger networks and less computers active. Not to mention how tedious it would be to go around and reset potentially 100 computers when the system crashes.

So, despite this reducing the point of storage media, the purpose this is for, is NOT replacing storage media. Just making field programmable options.

My current system parses the entire list of nicks, sorts by the first word, then kvm-splits the rest for options. Eg. "HyperNet node=SomeNode|type=entrance|gates=3|name=Roze's Example Node" There is no real alternative.