Well, that's just, like, your opinion, man.

Of course it's an opinion.

Point is that "futzed up the lore and supporting mechanics" is subjective. I don't think that they futzed up the Lore OR the mechanics. *shrug*
Not that they couldn't have been cleaner than they were, to be sure. (IMG:style_emoticons/default/smile.gif)

Entry requirement cost is not bad, no, I just will not likely be able to afford it any time soon. (IMG:style_emoticons/default/frown.gif)

Devices typically either cease operation while updating firmware, or require a reboot afterwards. Who the heck would be stupid enough to allow this to happen during a run/patrol/mission/duty shift? Even legal users would need to be able to refuse or schedule automatic updates, especially for military-grade gear. And Shadowrunenrs are SINless. They are not legal customers. Their gear is black market, unlicensed, and possibly being used to cause material and financial harm to the manufacturer.

Again, even a legal customer using gear in the field would schedule these for downtime, or on-demand.

Shadowrunners really, REALLY do not want this. Expect the gear to be black market, cracked, and reporting to nobody. Legal customers like black ops and military, even the police, might also object to confidential and possibly classified information being sent back in real time. Corporations might also be uncomfortable about rival companies being able to get hold of this data. Intercepting individual matrix packets may be difficult and expensive, but even a suspicion that the the Mega-Corps might have the resources and manpower to do it would make any corp think twice.

again, a Shadowrunner would most likely have a cracked black market version that no longer reports to the corporation.

Try playing an MMO over a wireless connection to your router, and measure your latency. Now use a cable connection to the router instead. Much less latency, simply because of the processing time wireless needs at both sender and receiver to handle the extra encryption on the wireless packets.

Now consider that the whole point of wired reflexes is to remove every single extra microsecond out of your reaction time, to let you shoot before the enemy can shoot you. Users pay through the nose for a better model of wired reflexes that makes them just a fraction of a second faster than the cheaper model.

If some of the required software is kept online, not in the cyberware, then that would mean that every single nerve impulse being accelerated by the cyberware is being processed by that software, in the cloud. Transmitting the signal to your commlink is already, at the very best, the same amount of time as it would take to get the signal to whatever would have processed the original nerve impulse.
Now add the time to

1. encrypt the data packet
2. upload it
3. route it through the matrix
4. process it in the cloud-hosted software, creating a new data packet
5. encrypt the return data packet
6. upload it to the matrix
7. route it back to the original user's commlink (Including validation of said user's identity)
8. decrypt it
9. and finally get the packet to whatever would have processed the original nerve impulse. (Which we originally held off on by sending the signal to the commlink instead)

This additional delay would result in the gear being useless in any combat situation. Imagine fighting against a wired to the gills black ops specialist only to hear the street sam next to you scream "LAAAAAAAAAAAAAAAAAAG!"

Why do people always trot out the "but lag" argument? When has anything in Shadowrun ever been affected by lag?

Actually, you're completely missing the point. It has nothing to do with transmission speeds - allow me to diagram the sequence for you:

Local:

[Node 0 to Node 1]--[----------------------------Processing at Node 1------------------------------]--[Node 1 to Node 0]

Distributed:

[Node 0 to Node 1]--[Node 1 to Nodes 3-FFF]------[***]-----[Nodes 3-FFF to Node 1]--[Node 1 to Node 0]

It is not that the time to go from the smartgun to the commlink to the nodes in the area and back is in any way less. It is that the time to go from the smartgun to the commlink to the nodes in the area, do the processing and then back again is (for an algorithm that is sufficiently compute-intensive) less than to go from the smartgun to the commlink, process everything and back again because serious time-savings occur at the processing stage - large enough time savings to outweigh the time lost to transmission. What this allows, then, is for much more computationally complex algorithms to be used in the distributed version, which accounts for a great deal of the bonuses (I have NEVER claimed that this accounts for things like the extendable baton). Most if not all of the "action economy" ones seem to me like they should work just fine when you don't have actual Matrix access, but still have the wireless on.

And I still don't know what kind of distributed processing an extendable baton needs.

Okay, okay, of everything that's been said in this thread, I can't stand for this delta-grade horse manure. It beggars belief that you'd be posting regularly on Dumpshock AND hold a legitimate claim to sanity in ANY form.

Sorry, Patrick, I have to call you out on this (IMG:style_emoticons/default/nyahnyah.gif)

/Joke

Back on topic:

As for the "distributed computing due to complex algorithms" issue... I'll program my own software for things like Extendable-anythings that don't require such a huge cloud investment. DNI->Datajack->(Commlink->)Baton can handle that, functional, elegant, non-bloated, and securely. I'll open-source it for anybody in the shadows, since I'm just that nice of a guy. Cyberware will cost a little more for that treatment, or a lot more if you're a corp-er.

Last I checked, the rules DID say you could program your own software, and it wouldn't need much to handle "(intGETVALUE A thru Z; if A > 0 AND [SUM B thru Z] < 1 THEN RUN[voidEXTEND_BATON]".

If I can do this today, I can do this in 2070. It would take a massive shift in physics to prevent this basic sort of programming from working.

If it still worked with wireless on in areas where there was no Matrix connectivity, it would actually be pretty trivial to explain the extended baton - wireless is needed, and the ONLY time a wireless connection is not also a Matrix connection is a dead zone, because that's just how the Matrix works in SR4 and 5.

When has the matrix worked at the same speeds as combat?

In general terms of "how many actions can you achieve", the Matrix in SR4 is actually faster than the fastest Street Sam - the one and only way to get 5 passes in SR4 is specific to Matrix passes. Lag is simply not a concern in the operation of the Matrix as it has already been presented.

And aside from that, "this problem has always existed" does not equate to "this problem is not a problem".

Because Physics is a bitch and she's wearing a sandpaper coated, barbed strap-on.

Actually, in SR4 working over commsats lowered your Matrix reaction because of lag.

Meaning: Lag only exists in highly unusual circumstances that would dramatically increase the transmission times over the norm.

Encryption adds only the tiniest bit, for the most part wireless problems occur because of the nature of being wireless: Shared medium, limited bandwidth, attenuation, noise...

@Rhat: Under your model, a runner could just strap five average commlinks to his back and get the same bonus (IMG:style_emoticons/default/wink.gif)

Not really, no. I get that it might intuitively seem that way, but it doesn't really work out.

Because...?

(In case your argument will be anything along the lines of "five dedicated devices don't make up for 50 shared devices", no problem, commlinks are small enough to be worn at the wrist. Add another ten or so)

That might involve cracking the security on the baton itself, since I'm pretty certain that it would have such measures. After all, after all this work, I doubt the corporations are willing to just let anyone write their own software for it. But, that being said, if you did? Excellent.

Because in Rhat's little world, the spare runtime and network bandwidth on a city block worth of toasters and coffee pots is somehow more powerful than a fucking cyberdeck.

This conversation's pretty pointless, the guy's willing to stretch to any lengths to declare that this stuff makes sense.




Where the hell does 'willing' come into it? That's the whole point of the existence of deckers. Willingness to have your stuff hacked has dick-all to do with what's actually going to happen to it once it gets out into the wild. (IMG:style_emoticons/default/smile.gif)

It's not so much about LETTING me do it. My first planned character for 5e, should I choose to accept, is going to be a decker/medic with the Anarchist Black Flag. My goal, specifically, is to develop tech to bypass all the cloud computing, whether through additional co-processor installation on gear, through modding the hardware, re-coding the software & firmware, or some combination thereof.

If the corp wants to put out bloated software? Me and mine will be making cleaner, faster code that doesn't devour system processes nearly so much while working just as well. Your hardware doesn't have enough processing power? Let's throw a few more co-processors, and hack the firmware to ONLY need your PAN, at worst, instead of the matrix.

Will the corps like it? No. But if I start small enough, and work my contacts, then there'll be a slow trickle of military and CorpSec professionals that'll come to me for modding, for updates, for the basic necessities of gear functionality in their professions. If I just gave the designs and specs to the UCAS Military? Heck, even post mortem that'd stick it to "The Man" (in this case, corps) by breaking one of it's holds over the military and government. Everybody runs for different reasons, and an anti-corp ideologue taking over the market share (or giving it to a military) because corps are too stuck up each others rear ends would be just the right kind of havoc to bring the house of cards toppling down. If they switch back to the old protocols and offer the same as me? Well, runners, we just made the biggest titans bend down to our level; we made them CONCEDE! Even post-mortem, that'd be win-win.

This Algorithm doesn't prevent premature baton extension. That's a MAJOR problem (even in 2070) for both end user adoption, as well as end user satisfaction.

Most metahuman studies seem to indicate that premature baton extension is the number one reason that another baton is ultimately selected for active service.

-Wired_SR_AEGIS

Once again see you can see more on this in recent history with the tragic Baton Bashup of '68 when the Radical Ions scriptkiddie gang sold second-rate batons out of Prague utilizing their own gimped software, resulting in a series of accidents due to malfunctions in the extension/retraction software with injuries ranging from broken fingers and wrists to at least 3 cases of blunt force trauma to the groin region when local toughs carried the baton tucked in the front of their synthleather jeans.


When will the madness end!! Always get your software from approved HackerHouse™ suppliers of fine software and decking accessories everywhere.

Right! (IMG:style_emoticons/default/smile.gif)

Though, in all seriousness, if I had a player that was adamant about removing the distributed computing safety mechanisms from their baton, I'd probably let them with an understanding that without the analysis offered by distributed computing, they may find their baton incorrectly interpreting their intent and both extending (and collapsing!) at inappropriate times.

Perhaps this could be somewhat mitigated by an adequate number of successes on the appropriate coding/integration tests. Maybe with additional considerations for if it were ever used by an individual other than who it was designed for, by an individual of another metatype, etc.

-Wired_SR_AEGIS

There's also medication and treatment to help with that.

Wait... are we still talking about the same thing...?

As for the Baton extension thing, the A>0 is for an active mental command over a direct-PAN link, the "SUM(B thru Z)<0" is a simplified "safety" check; if any of the conditions that flag B thru Z (or whatever the total number of variables is), then the baton won't extend. It's an incredibly oversimplified code, but one that wouldn't take up more than a small fraction of a TB of processing power. It could, also, potentially be "Spoofed" for the Baton. It works well into the "Gear is hackable" and "gear is transmitting signals," via the PAN instead of the entire Matrix, without "the gear is leaving a footprint on the local matrix for everybody and their mother to track down" issue. We haven't even addressed if every Grid is "On the Matrix," since they ARE segregated and may not play nice. I'd like to avoid such idiocy and pedantry, personally.

PAN should be fine for most, while still leaving a creative "Spoof" or "Attack" effective. My variance would even give people an option of either connect to the PAN via std matrix signals, or slave it and give up any independent protections (save for against a Spoof). If it's about distributed computing, there's always going to be a number of dedicated devices that can substitute that processing power more efficiently over a PAN than over a secured, encrypted, remote connection to several different devices. Unless, of course, physics has shifted too dramatically. And, once again, PAN still leaves you susceptible to hacking and spoofing.

This isn't an "all or nothing" discussion; there's room for concessions on either side. If you REALLY want gear to be hackable, give us a better explanation, or work with us to make one. I've already given a couple, personally.

Heheheh.



Absolutely. Iterating through an array of flags is super lightweight (provided, I suppose, there aren't like a bajillion flags).

The issue in question is not the difficulty associated with that sort of a task. Once all the numbers have been crunched, the data has been processed, the signal has been interpreted, running a final check prior to execution is trivial.

The problem, operating inside the framework of your algorithm, is not the complexity of checking flags but the complexity of correctly setting flags. It is the analysis and interpretation that carries the most overhead, not the final check for execution.

-Wired_SR_AEGIS