Goonhub
03-11-2021, 05:22 AM
(This post was last modified: 03-11-2021, 09:39 AM by aft2001. Edited 1 time in total.)
I should also note that data disks are a surprisingly rare commodity, with the few blank ones being available solely in a single box in technical storage and maybe a couple other places. You CAN wipe existing disks that have stuff on them though. Mechanics can print more though, so you'd wanna bug them for blueprints for Research's fabricator. L
As another note, the quantity of groups that can be hosted on a single disk can be easily changed by just changing the file size. Is 2 too much? Just make it bigger than 16 and only 1 can fit. 2 not enough? Make it 10 or smaller and 3 can fit, etc.
Personally I'd be happy to see EITHER DWAINE-hosted chemgroups *or* disk-hosted chemgroups. I can probably brainstorm how a DWAINE system would work later and edit this reply to contain that.
Now that I'm back at my computer I can make proper edits, whoo.
So, I've been brainstorming for a little bit and here's a bit of what I've come up with for a DWAINE-based chemgrouping:
The creation of chem groups should be near-identical to the process I described for the disk-based method, wherein you line-by-line punch in what you wanna add. Where the Disk and DWAINE systems differ is how they're loaded into the chem dispenser. For the Disk system, you would simply stuff the disk into a chem dispenser. But for the DWAINE system, you'd need to load the group from the mainframe onto the dispenser, somehow. This means that, unlike a disk-based system, a chem dispenser must be on-station in order to be used. This completely shuts down chem nerds from working at some off-station site they've made, unless they do genuinely super nerdy shit with setting up a wireless connection to the station PNET with MechComp somehow (in which case yeah that's fine, they've earned it).
Relatedly, I think the Mainframe should be less vital and more so a luxury. That is, it going down should not devastate the station, but rather just disable/remove conveniences and luxuries, such as Chem Groups. That and being a way to balance particularly strong game mechanics, such as Telesci, since the mainframe is uh, fragile.
Regarding the more specific/technical side of how such a connection would work, here is one way it could work:
As Chem Dispensers would have to be networked machines for this to work, their Net ID should be visible in their UI (or maybe you have to screwdriver it or something). When you make your Chem Group file, you will be prompted to add a Chem Dispenser ID to it, OR link it to your ID (since you can use your ID in Chem Dispensers already). When you go to use the Chem Dispenser you have linked it to, or log into a Chem Dispenser with your ID card, and click a new button which would refresh the available Chem Groups, a list of all groups for that Dispenser/ID will be made visible.
This 'refresh' button would send a packet to the Mainframe, which would include the name of any ID inserted, asking it to list what groups are available. The mainframe then checks to see what Groups stored on the mainframe are listed for that Dispenser's Net ID/ID card name, and will then send a reply packet with a list of the names of all groups the dispenser is allowed to use. These are then loaded into the UI and made visible, save for the actual contents of the group.
When a user clicks the Group, the Dispenser will send a packet similar to the 'refresh button' packet described in the last paragraph, but instead asking for the actual reagents in the group. The mainframe then does a check to see if the dispenser is authorized to use said group, and if so it will reply with the list of reagents and their quantities (likely in a file which can't be read). The dispenser will, upon receiving this packet, dispense the reagents as normal.
Notably this is absolutely not the only way a mainframe-based chem group can be done. For example, it could be worked such that you could directly load the group into a dispenser from the mainframe, rather than having to ask the mainframe every time the dispenser wants to use a group.
As another note, the quantity of groups that can be hosted on a single disk can be easily changed by just changing the file size. Is 2 too much? Just make it bigger than 16 and only 1 can fit. 2 not enough? Make it 10 or smaller and 3 can fit, etc.
Personally I'd be happy to see EITHER DWAINE-hosted chemgroups *or* disk-hosted chemgroups. I can probably brainstorm how a DWAINE system would work later and edit this reply to contain that.
Now that I'm back at my computer I can make proper edits, whoo.
So, I've been brainstorming for a little bit and here's a bit of what I've come up with for a DWAINE-based chemgrouping:
The creation of chem groups should be near-identical to the process I described for the disk-based method, wherein you line-by-line punch in what you wanna add. Where the Disk and DWAINE systems differ is how they're loaded into the chem dispenser. For the Disk system, you would simply stuff the disk into a chem dispenser. But for the DWAINE system, you'd need to load the group from the mainframe onto the dispenser, somehow. This means that, unlike a disk-based system, a chem dispenser must be on-station in order to be used. This completely shuts down chem nerds from working at some off-station site they've made, unless they do genuinely super nerdy shit with setting up a wireless connection to the station PNET with MechComp somehow (in which case yeah that's fine, they've earned it).
Relatedly, I think the Mainframe should be less vital and more so a luxury. That is, it going down should not devastate the station, but rather just disable/remove conveniences and luxuries, such as Chem Groups. That and being a way to balance particularly strong game mechanics, such as Telesci, since the mainframe is uh, fragile.
Regarding the more specific/technical side of how such a connection would work, here is one way it could work:
As Chem Dispensers would have to be networked machines for this to work, their Net ID should be visible in their UI (or maybe you have to screwdriver it or something). When you make your Chem Group file, you will be prompted to add a Chem Dispenser ID to it, OR link it to your ID (since you can use your ID in Chem Dispensers already). When you go to use the Chem Dispenser you have linked it to, or log into a Chem Dispenser with your ID card, and click a new button which would refresh the available Chem Groups, a list of all groups for that Dispenser/ID will be made visible.
This 'refresh' button would send a packet to the Mainframe, which would include the name of any ID inserted, asking it to list what groups are available. The mainframe then checks to see what Groups stored on the mainframe are listed for that Dispenser's Net ID/ID card name, and will then send a reply packet with a list of the names of all groups the dispenser is allowed to use. These are then loaded into the UI and made visible, save for the actual contents of the group.
When a user clicks the Group, the Dispenser will send a packet similar to the 'refresh button' packet described in the last paragraph, but instead asking for the actual reagents in the group. The mainframe then does a check to see if the dispenser is authorized to use said group, and if so it will reply with the list of reagents and their quantities (likely in a file which can't be read). The dispenser will, upon receiving this packet, dispense the reagents as normal.
Notably this is absolutely not the only way a mainframe-based chem group can be done. For example, it could be worked such that you could directly load the group into a dispenser from the mainframe, rather than having to ask the mainframe every time the dispenser wants to use a group.