If options aren't their own little program, why does RAW have us code them separately? I mean, in that case why not have each point of optimization add +1 to the threshold for coding a new program. It's written the same way every program, virus, agent, etc is coded. Typically, I consider them like a beneficial virus when I'm in doubt.

Per RAW, unless I've missed something, there's nothing to prevent a hacker from programming an option in his own node without attaching it to another program, or even having another program in the node at all. Yet something is created. The only logical way for me to resolve this is to put program options in the same class as viruses and trojans. It's a separate mini-program that acts through another program. Options just happen to be beneficial.

You code them separately *onto* existing programs. You're right, the given rules don't account for the case of programming a new program and options at the same time. They give rules for the program, and then options (*each* separate, so it could be several tests total). Given that some of the intervals match up, it's barely different from doing program+options in one (longer) test.

I don't recall anything like that in the RAW.

You don't recall *anything* like that?

"If a character wishes to upgrade software he already has with new program options, he must possess the source code."

As far as I can find, there are only two ways to get options on programs: this, and buying them with options installed. I'm not claiming this is ironclad evidence of what I've presented as my understanding of the rules, but don't act like I'm coming out of left field with the crazy idea.

Hey, what about Open Source Software that you can...

Oh, right, 6th World, silly me.

Sixth World has OSS. Optionally.

Hehe. Anyway, there are a couple possibilities here:

1. Programs must be purchased with options, or have options coded into them in a source-code state (open source, cracked, self-coded). I take this side because it seems less open to abuse, more logical, and more in keeping with the fact that you can't buy options separately, but only as a preloaded part of programs.

2. Options can be coded separately and mix-n-matched onto any programs in a source-code state. This means you can code, but not buy, options (why? *shrug*), and that you can dupe them as much as you like. It *could* also mean they degrade over time, although the rules for this don't mention options at all; if so, it's another level of bookkeeping (luckily, you can just dupe them?). It's possible, on the other hand, that options are uniquely immune to degrading, which makes duping even nicer.

I feel like #1 has more merit. Neither is clearly the intent (or fact) of the RAW, AFAIK.

--
A separate question: what do you guys do when a program degrades to the point that it's no longer allowed to have all installed options (half rating, round down)? This would matter crucially at the Rating 6/Rating 5 threshold, obviously. Disable an option at random until it's patched up again?

No, I mean I literally can't recall because my computer with all my PDFs is dead and so I have no way to check. Recall is all I have for...probably the next month until I can afford a new computer.

And I'm specifically referring to something requiring you to code program options onto an existing program.

And yeah, there's an optional rule for open source software in Unwired. It's, well, not bad but I can't recall any good reason to use OS given how cheap pirated options are.

Edited for Y:
Why wouldn't options degrade in the same manner as everything else?

I agree that having options as part of the program, rather than their own code, would be more logical in some cases. For example, it makes sense that an optimization option in a Stealth program shouldn't work in a Blackout program but it doesn't make much sense that a Targetting (+2 to hit) option on an Attack Program wouldn't work on a Blackout program.

As for abuse, I'm torn. If the option is an integral part of the program than the ability to code a R10 Stealth program with Optimization 4 is clearly RAI even if the RAW gets a little buggy. On the other hand, if the option is in a source code state, then that seems to make far too valuable for the cost.

Udoshi quoted that line on page 1 of the thread, actually, but I'm just teasing. How about something that specifically says you *can* program options standalone and modular? We don't have either.

I do feel like that passage implies that you start with a program (source) and program options onto it, but obviously it's not explicit. :/ We *do* know that you can't add options (pre-made or otherwise) to non-source programs; I take this as another (very mild) point of support for my theory, though. Viruses specifically infect non-source programs, after all.

So running with that RAI, there's nothing to stop someone from building a very simple nexus with their starting cash/first job and start programming their R10 stealth with Optimization.

So:
4 skill, +6 cyber, +5 programming suite +7 Logic +3 Feng Shui lifestyle will consistently get you around 8 hits on a test, which will get you a R8 stealth program in 2 attempts and the optimization in 1. If you're willing to drop 2 edge into the tests to reroll failures and rush the job on the Stealth you can probably get Stealth 10 in two weeks and the option in another 1-2 (can't recall if interval is 2 weeks or 1 month). I'm sure there's other ways to increase that dice pool but yeah, under that interpretation, the Techno stealth advantage will disappear by the time the Techno starts submerging.

Yep, the programming rules remain a mess: too slow for real players, too fast for munchkins. Personally, 7+ is military, period.

Can you use Edge twice on a given test, if it's Extended? Regardless of the answer, it's not like you're losing anything as your Edge refreshes. The only silver lining of balance is that you have to constantly patch your programs, which has a minimum time cost, multiplied by the many various programs you might want (kicking things back from overpowered to underpowered, nothing in between). Sigh.

How does the option debate affect this at all, though?

Well put.

The biggest reason is that OSS is Free and Cracked Software is not... Pretty good reason to me...

The biggest reason is that OSS is Free and Cracked Software is not... Pretty good reason to me...
You could potentially obtain OSS with Options (and it would still be free), as it is all GM fiat anyways...

Nope. 500% as expensive as Pirated, 50% as expensive as Cracked (assuming you're doing it yourself).

Open Source also has the option (Alternatively) of being Free, if you are part of a Warez group, maintain a Warez Contact, and contribute to the group... Think of it as a Magical Group for Mundane Hackers. Therefore, it potentially costs you nothing...

If you're contributing, it's not free. Anyway, my point is that, along with the *other* suggestions about Open Source, certainly don't make it better than pirated; probably not better than cracking, either, if you want anything good.

Its just time though, nothing more...

And, as long as you only need basic levels of Programs (Rating 4 or lower), then open Source is okay...

Time is money. Duh. You're right, as I said before. Let's restate it properly, again: 'if you only need crappy programs, Open Source might be better than cracking retail programs'.

Here's where you're wrong.

The source code for an option is not part of a program. Its its own source code.

An option is not made for each program, its the other way around: Programs are made for options. They have slots for them, but aren't obligated to use them.

Hell, the 'upgrading your own programs with options' rules basically specifically says you can copy an option to all of your programs by cracking it, or designing your source code. It also specifically says program coding is handled like any other software test(no special restrictions). The beginning of the program option section even says options are modular designs that are supposed to flexible addons and patches.

While some of the intervals DO match up, its definitely not "barely different from doing program+options in one (longer) test."
And thats because Patching is a week long test. Coding tests are invariably one-month-plus tests.
Rolling them together would more or less raise the time you need to apply one option to multiple programs by a factor of at least 4.

You mean, "here's where Udoshi disagrees".

That doesn't really make sense. There's no real reason that Options have source code at all (in rules terms; obviously, they have source conceptually); that is, the rules never appear to make a source code distinction for Options. Neither do the rules support (or deny, as I've said) your concept of "An option is not made for each program, its the other way around".

It does *not* "basically specifically says you can copy an option to all of your programs by cracking it, or designing your source code". I think you're mixing up the sentence's references to programs vs. options. There's no evidence that you can (or need to) crack any option at all, let alone copy it to other programs. I've already addressed the 'modular' bit, but to repeat: it seems to merely mean that options are *possible* at all, nothing else.

I don't understand your patching/interval point. Coding Options have intervals broadly similar to coding Programs. Patching is not involved, unless you're using the theory that you already have options premade. You can't assume *that*, because that's the central focus of this argument.

--
… Do you think anyone minds how far we are from 'technomancer vs. mundane hacker'?

Going back to the early question of 'can you code a R10 program on a R6 commlink/nexus?' (Personally, I wouldn't allow military-grade at all without some kind of extra penalty, but that's another issue; the question is the same as 'can you code a R6 program on a R3 commlink?').

People agree that RAW seems to be a simple 'no'.

There's a possible vagueness of what 'potentially run' means, but that's pretty minor. However, there are certainly some simple house rules to allow this:

One option could be to simply double all intervals if you're using inadequate hardware, or, if you'd prefer a scale, multiply the intervals by 10% (or, 25+%?) per 'missing' Rating of the commlink/nexus?

Another option could be DP penalties (use the existing Inadequate Tools rules?); if you use 'mandatory' diminishing Extended Test DPs, this would hurt more. :/

A third is to increase the chance of glitches (and therefore bugs) in a direct way, as opposed to simple DP penalties. This constitutes a slow-down, because you have to debug.

Any/all of these could satisfy the balance between trying *not* to flatly disallow things, while also providing appropriate sacrifice/penalties. I'm sure other people have other ideas?

Inadequate Tools is the one that I typically prefer... It is simple and relatively hassle free in that you don't need multiple rules to cover it. Hit 'em with the inadequate tools penalty and just move along... It is indeed painful with the Diminishing Extended Pool... we have used both over the last year or two...

I'm mostly worried the -2 simply isn't enough, by itself.

How?

If the Optimization option is a part of the code itself, and not just an added option. then there's nothing to stop you from coding the option and then coding the program. It's basically just one program split into two tests. If optimization is a seperate entity then a R10 program isn't potentially runable but if the optimization is part of the code, it isn't just potentially runable, it is runable without any mods. All you need to do is code the option beforehand and then cope the option itself.

I think you're trying to have it both ways to prevent two kinds of (what you think of as) abuse. If the program option is external to the program, you can mix and match it to any program you want. If it's internal to the program, there's no good reason you couldn't code up an optimized R10 program on an R6 or R5 node.

Personally, I can't understand why you think modular options are such an abuse. Every Hacker pirates all his porgrams any, now he just pirates options as part of them and and even the most expensive will only increase the cost by about 1000.

It is typically a granularity issue... If you have characters who craft their own software and comlink/Nexus hardware, they are typically devoting some significant time and expense towards the endeavors. AS long as they invest in a Shop (My character's minimum standard for such endeavors) then the -2 is appropriate for the discrepency between the shop and the facility. However, if they are trying this without the benefits of the shop, they end up with a -6 to the attempts, as I cannot see a "Kit" existing for such endeavors, and the discrepency is so large that they SHOULD be hampered significantly.

In the game I play in, the character I play actually has both a Shop for Electronics (Hardware ) and for Programming. Though I tend to use the Facilities provided by renting a Programming Environment, as well as the programming Suite that is available, to avoid any unnecessary penalties to the endeavors. Considering that the character still spends Anywhere from a couple of Weeks to Several Months to complete a project, this is still a significant time devoted to Hardware and Software development.

It is also a Flavor thing. Anyone can ALways PURCHASSE the requisite equipment and programs, but it takes a special sort of character to design/build/program what is needed to perform your duties. I like the feeling of having something that the Character accomplished, rather than the stuff that is commercially available, even if the end result is still the same.

PoliteMan, I simply don't see how or why you *could* program the Optimization first. To use your terms, it's neither separate nor part of the code itself; it's a modification added to the existing code. You can't modify something that doesn't exist yet. Abuse doesn't enter into it at this point. (Personally, I had never encountered the 'potentially run' issue before, and don't care about it. )

Tymeaus, that's what I was concerned about: having the penalty scale appropriately for more-inadequate tools.

Ok, lets take back up a bit.

We're talking about modifying a program. Now consider if we were building a gun and we wanted to give it the extra ammo modification. It should be even easier to make the modification if we were building the gun from scratch. Same with vehicle construction or anything else. Why in the world should it be more difficult to modify something while you're building it than after it is completed? I don't understand why we'd say that we cannot modify this program while we're coding it. If anything, it should be easier.

Now RAW isn't easy to work with here, mostly because the RAW for building anything is, well, less than well designed. But lets be clear, this sin't trying to find a loophole around RAW, this is trying to get RAW to work for something that should be possible and RAW just models it very poorly. The easiest way I can think to get around this is to start coding the option and the program at the same time.

And honestly, I like this. There are very few good reasons for a hacker to code up their own stuff as long as pirated software was around. Now there's something worthwhile for hackers to code and it's worth their time. And personally I love the idea of hackers desinging their own code, it's the defining trait of Fastjack and many of the named characters have had at least one program to their name. It's easy for the GM to manage progression, because they set the amount of downtime between missions.

I agree: there's not *great* reason that the RAW fails to have a 'one giant programming test' option. I'm just saying that we're 100% sure it *doesn't*; there's no question of post-modfication being 'more difficult', because there *is* no 'during' option at all. Given that, it seems like post-modification is the only valid choice. I certainly agree that a house rule here would be smoother.

Some people like to make the smallest possible tweaks (which is how I characterize my earlier suggestions), while others like big changes (creating some kind of unified 'big programming test'). The way the mechanic works, one big test is desirable for time consumed, Edge use, and other reasons, so it's important to keep that in mind. As we said earlier, there *is* abuse of the programming rules when specialized-optimized characters are involved, nevermind the fact that they're also getting R12 programs which (by some arguments) never degrade either. I guess that's one good thing WAR! did, mandatory R7+ degradation.

Again, personally, this basically doesn't matter to me. I don't generally allow military-grade (7+) to just pop out of Joe Runner at all. It could be an issue for a R3 commlink making R6 software, but 'get a better comm' is such an easier fix. I just like working through the rules/balance/design side with you folks.

I think you raise an interesting point of comparison to weapon/vehicle mods. First, there *is* no weapon/vehicle design in SR4. There are only mods. Again, you can't compare 'build+mod' against 'one whole thing from scratch', because latter isn't an option at all. In SR4 vehicle/weapons, you can't even buy things with mods installed (only in the sense that mods have standalone Avail/Cost, I mean). All the mods are post-mods. You could possibly pre-buy the parts for some of the mods, but not without knowing exactly which weapon or vehicle they're meant for. In the spirit of being *similar* to these existing rules, you'd expect Program Options to act this way: post-mod only. They don't even have the options of buying ahead.

I guess it burns down to "it depends with which interpretations of the rules" you are playing.

If threading takes no action at all and your technomancer is able to thread up his attack form three times before hitting somone in the face with it, it is wise to choose a technomancer.

If your hacker is able to write his own (never degrading) rating 12 prog. in about two month, well I guess it is best to fly with the hacker.

I'd say that playstyles would be a factor. Do you like planning, bookkeeping and preparing ahead of time? Play a hacker. Do you like flying by the seat of your pants like a Digital Cowboy? Play a Technomancer.

Because the rules don't say that you can't.

Okay, now that we're ignoring what the rules say, because, as we've both already agreed, they're ridiculous, how about something less ridiculous... like building the program with Optimization at the same time since you can make sure that each step in the modular programing process is efficiently operating and as many redundancies and wasted cycles as possible are removed.

Does.. Does that sound reasonable?

Heretic!
Trying to make the Matrix Rules Reasonable!
Die!


uh.. mmm

I would think that Program Options should be built into the program when it's being built.
Or, coded INTO the program as part of a re-write.
So lets say I have Attack 4. I want to make it ergonomic.
I have 3 options
1) I buy Attack 4 w/ Ergonomic from a legit software company
2) I program my own version of attack 4 w/ Ergonomic, adding the ratings together, etc for my etst.
3) I buy attack 4, crack it, then code in ergonomic as a patch.

They don't say you *can* either, Saint Sithney. That's our whole problem.

I do agree with you and sabs, of course, when it comes to house ruling it: no premade/standalone Options, but it's fine to code a given program+options if the end result would work on your node. After all, this makes the coding take longer, which is as it should be. It *does* still benefit munchkin coders, but we can't build the game worrying about them all the time. In almost all cases, the 'mother program' has a longer Interval anyway, so you're usually (possibly) losing on the deal. Which is also probably as it should be.

AFAIK, sabs' options 1 and 3 are RAW (the only RAW, by my unsupportable interpretation).