Existing players used to logging in with their character name and moo password must signup for a website account.
- Greenhorn_Guest 5s [The Drome - Restroom]
- Thia 20m
- Mikael 4s A soul cant be cut.
- Soltan 2m
- Raven 1h I lost myself, in the dark charade.
- Rillem 11m Make it personal.
- Bruhlicious 8m Deine Mutter stinkt nach Erbrochenem und Bier.
- Pladdicus 5m uh
- SmokePotion 29s Right or wrong, I'm getting high.
- Vanashis 7m
- Sivartas 4h
- zxq 18m Tools: https://ansicolortool.neocities.org
And 22 more hiding and/or disguised
Connect to Sindome @ moo.sindome.org:5555 or just Play Now

Decking Improvements
THEY'RE TRASHING OUR RIGHTS!!! TRASHING!!!!!!

At the moment, many aspects of Grid 4 seem to be kind of "high risk, low reward". For example, if you as a decker want to try and scan some shiny corporate terminal into your deck, you need to either buy a shitty throwaway deck that's just going to eat up space in the MOO and eventually starve the supply for other players, or risk your "main" terminal trying to scan it, which may result in all of your data, programs, etc, falling into the wrong hands. This would be perfectly fine, if it was really worth that risk at all. Most of the time, the commands you can execute on a device via the Grid are almost entirely useless, outside of extremely fringe cases. Most of the time it's just information you could've figured out by looking at it like any normal user, if that. This is, of course, if you can even scan the device in question into your deck in the first place. The vast majority of the time, the device will not be linked in to the Grid whatsoever, making your entire plot, scheme, or plan to get physical access to it entirely pointless.

I do understand that these complaints are largely a result of Grid 4 still being very new and work-in-progress. With that in mind, though, I think it's worth (at least temporarily) allowing deckers to transfer data between decks. This would cut down on deck hoarding, and make poking around in places you probably shouldn't more viable of an activity. Or maybe deckers could manually add devices via their device ID! There could be hardware for changing the device ID of something to keep deckers out, and corporations could make a habit out of having their NetSec code monkeys cycle out the device IDs of important infrastructure on a regular basis.

Building on this, while it has been said a few times in the past that staff want to keep Brlang simple enough for players without any OOC programming background to not be at a disadvantage, it does seem like this idea formed at least part-way through its development. I say this, because despite this being the given reason for there being no conditional statements, loops, etc, a lot of commands that are available, including on certain geocodes and devices, really do seem like they were created with the intention of being used in a conditional or a loop. For example, the "is_transmitting" command, which just returns a boolean. Why are there datatypes in the first place, if everything seems to just be treated as a string and nothing needs to be compared? I think it's possible for Brlang to be more fleshed out, including things like conditional statements, branching execution, etc, without leaving players at a disadvantage. It's hardly quaternions.

_IF_ we were able to transfer scan data, I think it would have to be between the same model of terminal. To prevent scanning on a QuickTerm and transferring it to a NovaTerm. I do agree that it is kind of getting to the point of having to keep a pile of terminals that each have one or two scans because you can't risk taking it out in public.
I could get behind that. Would "the same model of terminal" include an unmodified terminal and a modified terminal of the same make as "the same model"?
What if you had to like, buy like, little flash drives you can plug into decks in order to manually transfer the data or programs? You could put little labels on them.
Seems like E-mem modules would already serve that purpose, no? I'm down for that, though. I understand the original reasoning of not doing that (we don't want deckers becoming cuboid software dispensers that never go outside) but I think it's worth at least trying out before we write it off like that.
Why does having conditional statements matter so much? You can check "is_transmitting" first then use dynamic commands to toggle it on and/or do the other commands you want.
Branches would remove some of the reason for getting a better term, since you could just put multiple complete programs in one program.
What dynamic commands? Currently there is no way to use the output of one command to influence or as input for another command. You cannot store things other than user input in variables.
You can use a variable for a device command.
Yes, but you can't store the output of another command in a variable. You can only store user input in variables.
If you see that it is transmitting, you just do whatever command you wanted to do. If you see that it is not, you do the toggle command, then do the command you wanted.

Ex:
Device- is_transmitting
Request- command1
Request- arg1
Device- command1, arg1
Request- command2
Request- arg2
Device- command2, arg2

So if is_transmitting is false, your inputs would be:
toggle, whatever, desired command, desired argument

Additionally, what you're proposing wouldn't always work. For example, the "is_transmitting" command returns a boolean (true or false), while the commands to enable or disable transmission are two different commands (grid_disable_transmit_receive and grid_enable_transmit_receive). You would not be able to toggle a device's transmission status by just feeding in the is_transmitting output without using a conditional statement.
Then the inputs would be: enable, whatever, desired command, desired argument
If it's not a toggle, why do you even need an if in the first place? Just always run enable.
Yeah, sure, in this one very simple example you could just do that and manually enter everything. But that massively stunts deckers from doing… anything cool, really? You can't write a program to locate the specific bar someone's in and then return a camera screenshot of that bar by just manually hammering in everything. I mean, you could, but it would take forever and fucking suck.
It's really tough because I totally get why the scan limitation exists, but I do think the market for QTs is drying up because people are forced to hoard them.

I think if the compile specs of the terminals match, then it could at least just be used for consolidation. Like same terminal base model or 'specs' (I don't want to go into detail about mods because IC). Most scans aren't terribly useful anyway and the ones that are are already on hoarded terms that people are scared to bring outside.

I would really love if some commands could have a 'return' value that gets put into a variable. Which might be a good way to handle meta commands from the other thread. That would be basically the same syntax as the input tag so I don't think it's too far-fetched.

As for conditionals… I think a program abort/return might at least be nice. So not really branching but just end program early if line 1 equals line 2.

The term hoarding is a bit of an issue, but I also think partially the cause for it is permanent nature of the access, once you scan the thing, it stays scanned and there is extremely little that can be done around it, especially if the term is just kept under lock and key. If the access was limited to X uses or whatever other factor then losing access would become more normalized, and losing that term would be less of a sting.

But also, yes, while pulling out those heists can be satisfying, the payout is just not there yet on it's own, though it can absolutely be worth it as part of a wider scheme. But then this needs constant balancing so you do not get too much power from your closet.

I especially dislike being able to remotely add anything, or zap someone over terms. This just pushes people to be more in the literal closet, if a decker pisses you off, id them, and hire someone to shoot them.

Sure, but then after someone shoots them they have no recourse whatsoever. They famously don't make that much money, so they can't hire someone of their own, and their skillset tends to lock them out of being anything to worrry about in terms of combat. Are deckers supposed to just roll over and take it whenever someone decides they feel like stomping on a nerd today?
Some decker's don't make much money, others make quite a lot. Same as any other cohort of characters, varies from one persons grit to another, and often remembering that not all your chy must come from skillchecks.

As for being pushovers, this is the same as any other character in the game, if you want to be able to scrap directly, put the time and train for it, or build a rep so people won't dare, or other RP solutions.

Yeah, "put the time in and train for it", until their UE maxes out and they get pulled apart anyway because whoops they also had to "put time in and train" 3-6 other non-combat stats & skills to dizzying heights
How is that different from literally any other character?

I think people grossly overestimate how much other 'jobs' make out of skillchecks in general, and then see what they make as little. Mechanics, nurses, doctors, arms tech, drivers, security techs on average I doubt pull more than few kay a week out of the skillchecks.

I agree with you that it's "the same as any other character in the game", by which I mean unless you are playing a combat character or sleep on a big pile of money every night your character basically exists at the mercy of a hundred John Murders and can hardly do anything interesting without getting a knee-jerk reaction of turning you into a red stain on the sidewalk. I at least wish the consequences were more interesting than "vat time lol"

I feel like we're getting off-track, though.

No, you are misreading it and I think intentionally. I very intentionally used the term 'skillchecks', what you earn beyond that is up for you to figure out as your character can be more than whats on their @stats and honestly oh so many ways to earn do not require any skillchecks at all.
And I think you're misreading what I'm saying. I don't give a shit if deckers don't make a ton of money, my original point was that deckers don't currently get to do enough interesting shit with hacked devices to make the risk of trying to scan in certain places worthwhile. They don't need to be able to give someone a brain haemorrhage through the Grid (although i still think that would be cool) or make a trillion chyen from what they do, but they should at least have SOME way of fucking with people. They're breaking in to restricted computer systems. Why not let them re-enact that montage from Hackers where they cancel The Bunk's credit cards and mark him as legally deceased and put out a warrant for his arrest and whatnot.
Considering that we are in a cyberpunk world, the world is oddly disconnected from the grid as a hole.

I understand the reasons for this to a degree, people managing their finances/transactions/sending large amounts of information between each other entirely from the grid would negate a lot of the in person interaction, but I think more things could be possible. Scanning something in the bank, for example, could allow you to monitor it and scrape data of people's accounts and steal money, or hacking an employment terminal let you fake being an employee of a corporation (obviously this would likely backfire epicly but I can think of creative ways to use it)

At the moment, a decker is a really difficult type of character to play because they just simply aren't worth engaging with for the most part.

They aren't a threat to anyone and aren't really useful to employ, either, so they don't really have a place in either the mix or topside.

I come at this with the prospective of a new player, so take what I'm saying here with a pinch of salt.

This is just from what I've observed and from my own interactions.

I agree with paintextblue to some degree. It has always been my opinion that the grid first has to be usable and attractive to the non-decker. It needs to be made so non-deckers can do a bunch of cool and useful things and that these things are convinient enough to WANT to do them. The grid needs to be functional for non-deckers.

THEN you have a layer of exploits and improvements that deckers can provide on top. It has improved a lot but for a long time, in my opinion, the grid has been primarily focused on making deckers necessary to do most anything useful. With that model, most only deckers will be using the grid. It becomes this abandoned playground only used by a few deckers.

Adding grid connected devices is a huge improvement. It expands everyone's use of the grid by default. So more of this is better to me. But I still think that the grid itself needs to be streamlined so most characters want to be on it, using it, and are capable of doing so. Because a largely unused grid is no fun for deckers.

ACLs are a great addition. I'd like to see more businesses create Nodes for storing data that in the past used things like whiteboards. Maybe move corporate SIC keys to grid nodes. Find ways to make datastores grid connected. Make decent search possible for the average user.

I am confident that most players who make a decker didn't do it so they can do grid searches better than the rest or become a webmaster. They wanted to do the cool stuff. Again, I think grid 4 is a huge improvement. I just think that without making characters want to use the grid it will continue to be underutilized and of less value to deckers.

I agree with Grey0 here, and they made the point better than I could

The more interconnected the world is via the grid, the more useful it will actually be to have deckers.

More grid enabled devices is a great start, and there's certainly some things you can do there, (provided you can get the information you need without having terms stolen) Trying not to say to much here because FOIcC.

There are characters who have been trying to make the Grid more interesting for non-deckers, but the engagement with those from what I've seen has been near-zero. I agree the Grid needs to be more appealing for the average guy, otherwise it just feels like an abandoned void for Deckers Only. Maybe some features for pure convenience, like streaming TV shows on your gridterm (easily possible now that the Grid is in-MOO rather than a web app), managing finances, more convenient management of security networks, etc. Of course, these conveniences could also potentially be turned against you by a powerful enough decker. Not saying deckers should be able to drain people's bank accounts, because that would be insanely OP without serious balancing (maybe requiring dedicated chrome that itself requires GridSight and thus a hardline into your body, and featuring ICE that can absolutely fry the shit out of you through it?), but SOME way to fuck with people.
I don't see why you shouldn't be able to drain someone's bank account, given enough time. Just have bank ICE be greater than base ICE for terms and nodes. Maybe allow new ICE to be put on them to, and daemons for those who really care.

Requiring it need gridsight would be fine too.

I personally just think the grid should be more of an underpinning to the world, rather than something that just happens to be a part of it.

I don't know…that might reinforce the idea that you can't trust the banks in a cyberpunk theme...
Then put it as a complete idea and how exactly will this be balanced and good for the game? There is a trend that decker topics just derail into endless wishlists and it's hard to follow as a result.
Thinking about the idea of transferring scans again…

What if you could put the scans on an e-memory and the e-memory had to be 'formatted' to match the type of terminal? (So if you wanted to use your scan on a NovaTerm, you would need to acquire the scan using a NovaTerm). If you 'reformat' the e-memory, it deletes anything that's on there.

( Someone recommended at Town Hall that scans should have a limited number of uses and I definitely disagree with that. I think it would actually make the hoarding problem worse because now instead of hoarding one term with scans, you'll have to hoard multiple with the same scans if you need many uses. )

It's an interesting problem to solve.

I want people to have to explore and for there to be risk in losing a term.

I don't want that rush to be so great that people never take them out.

I don't want you to be able to copy them or people will just copy infinitely.

I want to avoid the problems we have with camera networks.

I don't want life for deckers to be too hard.

Transferring between terms of the same type is an interesting possible solution. I don't really want to deal with emem if we don't have to. That system is annoying to work with.

Directly transferring from one term to another of the same type is a maybe.

Can anyone think of other solutions that wouldn't make it too easy while also not making it as hard as it is now?

Maybe to put a limit on scan uses? If you will have limited use of a scan, it becomes notably more acceptable to lose it, vs a permanent link.In the end you would have to re-do it at some point anyway, or never use it but that's a general hoarding problem. Maybe could even have them fade with time, not just with use.

I do not have the game theory in my brain now to math it game out full idea with numbers, but I think something in that direction could work. And then transfers could cost you additional uses, and doing scans as decker gains you more uses.

I would prefer an expiry time (like 12-24 months) for a scan rather than a limited number of uses. I think that making a limit to the number of scan uses will make hoarding worse. But both would make things more difficult rather than easier.
Just going to pile more onto the plate here, good morning

Digital currency transactions, traceable (unique IDs). Having not yet tried this, it might already exist IC sort of. But I am saying like payment from the layman's grid term. The SIC Chip's ID connects to the bank account connects to the grid connects to the user login (maybe unless you are using somebody else's login I guess and then that breaks my whole idea because I do like shared logins). Hmm. Hmmmmmm.

More on topic but…. Maybe this is a game mechanic that we can test in a rampagemoo? Unlimited transfers of a thing you scan, and then see how that can go wrong or go right?
I realized maybe the idea of persistent access is the problem here. Same thing on the flip side on an IC thing actually. So maybe the solution to both just needs to exist….a counter-hack that can get into the system with the scanned term/device and break the term's ice and remove the scanned devices/locations.

Could also build a parent-child thread where transfers of a parent scan will slowly atrophy over time if the parent scan gets removed from the device.

Or if that is too much, could just make it so that the original counter-hack program can be I dunno gonna just say words now daemonized and run across a list of terms that may or may not exist IC. Like a wiper. Only as good as your list of known devices though.

Lists. Yeah, the ability to attack a list of devices all at once within a program. Need & want.

You can already do a list of devices, 1 per command.

As for the issue of scans, the reason terms are horded is because scans are forever. If they expired or could be rotated manually in the case of corporate/personal devices by a decker, then there's no need to hord terms as the thing you're hording it for will expire anyway.

This probably won't stop people buying all the terms and then using one per scan or something, but having to go out and scan more could result in more terms being stolen and making their way back into the market.

Having zero skin in the actual decking game and not knowing the ins and outs behind it all, I'm looking at the problem from a game design perspective so I'm going to offer the following idea blind.

Allow scans to transfer, but also allow a decker / security specialist the ability to "scrub" a device, or essentially in non-hacker hacker language reset the IP of its location on The Grid. It would turn the device off for a not insignificant time while it reboots but once it came back online any scanned terms that runs code to remotely access the item kicks back a *womp womp* version of hacker language saying device cannot be located or accessed.

This way scans can be still be valid of an indeterminate amount of time, but transferred so as not to hoard quickterms. And they also can't be held forever because eventually someone (secure tech specialists) can come around and reset the device. The downside is that you can't just scrub devices willy nilly because of the extended downtime of the system being inoperable. A security switchboard may have a trace on it, but resetting it to scrub the hack will make a corp tower's cameras go dark for 2 hours. Is it worth it?