Just now, edwardavern said:

Could you clarify? From context, I wasn't sure what isn't completely ridiculous....

The idea that lots of time (and money) is "wasted" because a roll is failed, and the PC would not know it until the end of the specified time. That's not outside the realm of realism. But maybe I am misinterpreting the problem.

1 minute ago, Degenerate Mind said:

I can't tell if you're talking about alcohol, or using it as a metaphor for RPGs.

Alcohol in this case.

2 minutes ago, kaosoe said:

The idea that lots of time (and money) is "wasted" because a roll is failed, and the PC would not know it until the end of the specified time. That's not outside the realm of realism. But maybe I am misinterpreting the problem.

You're right - that's fine. That's how the rules SHOULD work. But that would mean rolling at the END of the time period...but then how do you make that time period shorter for extra successes rolled?

1 minute ago, edwardavern said:

Yeah, no, I get that. But let's assume the other players want to do something other than "we sit and wait for our technician for a week". Or let's assume that there are story events that I would like to happen within that time. Or that the ship will arrive at its destination and the PCs will have to respond. Or whatever.

Could you clarify? From context, I wasn't sure what isn't completely ridiculous....

If the technician is too busy to take a week off throm the plot, then he probably shouldn't have started working on that fancy new droid chassis. Alternatively, he can set the droid aside for a trip outside. Unless you nuke the mechanic's shop from orbit, his project should be right there waiting for him when he gets back.

1 hour ago, edwardavern said:

This is fine for a 2-hour item, but becomes a problem for a 56-hour droid (and, I assume, will be exacerbated in the vehicle-crafting rules). It's a rare campaign where a PC has 56 hours of uninterrupted downtime (or more, if the GM insists that the character has to get some sleep). Such a check could feasibly take weeks of in-game time. If the roll determines that they take that full period and fail the check, do you, the GM, then insist that they spend that time, knowing that it will be unsuccessful? Can't think of anything more likely to really annoy a player, or make the disillusioned with the system.

Like I said, it's not a difficult problem to fix...it just annoys me that it requires fixing. (And it's not an isolated example of ill-thought out rules. I really really like the core of this system a lot - the dice, the character-creation, the talent trees, the Force, the combat system...they're all great. That's why I play this game. But I've had to tweak so many little bits things that either weren't explained, were explained pooly, or just weren't thought through, and it really bugs me that that's necessary.)

What fix? How is this any different than life? I mean how much software is written completely and no one knows what a craptastic shitfest it is until it's beta tested?

The PC crafts the droid, does everything they think correctly, and when they flip the switch it can't conjugate verbs. You have to remember they aren't assembling a kit, they are making something from scratch. You can buy lumber, build a table, level it, and then realize you F-ed up a measurement and it doesn't fit in the corner where you wanted to put it.

There is nothing wrong with the rules.

1 minute ago, 2P51 said:

The PC crafts the droid, does everything they think correctly, and when they flip the switch it can't conjugate verbs. You have to remember they aren't assembling a kit, they are making something from scratch. You can buy lumber, build a table, level it, and then realize you F-ed up a measurement and it doesn't fit in the corner where you wanted to put it.

1

So...yeah, exactly...except for the "extra successes=time reduced" rule. If you make the check at the moment when you "flip the switch" (which is what I assume you're saying, and is also what I've been saying) then how do you reduce the time taken by 2 hours for each success? You can't. So you either have to roll at the beginning, or discard that rule.

I'm slightly concerned this thread has got a little out of hand - this is NOT a game-breaking problem. It's a tiny little problem that I can fix by just ignoring the rule. It's just...just a straw that's making my camel's back creak a little, is all.

Or just say it went faster than they had planned, and ask if the PC wanted to do something meaningful with the saved time , for example start another project , or just get drunk and shoot at stop signs. This isn't a small, big, or any problem with the rules.

7 minutes ago, edwardavern said:

So...yeah, exactly...except for the "extra successes=time reduced" rule. If you make the check at the moment when you "flip the switch" (which is what I assume you're saying, and is also what I've been saying) then how do you reduce the time taken by 2 hours for each success? You can't. So you either have to roll at the beginning, or discard that rule.

I'm slightly concerned this thread has got a little out of hand - this is NOT a game-breaking problem. It's a tiny little problem that I can fix by just ignoring the rule. It's just...just a straw that's making my camel's back creak a little, is all.

The roll doesn't correspond to a specific point in the process. Player declares he wants to do X, you say okay, he rolled the dice. Based on the result, you tell him how it went, both in terms of time spent & the quality of the finished product. The player character continues to be the unwitting pawn of the cruel & capricious dice gods who rule over the universe.

OK...well, maybe it's not a problem for anyone else. Maybe it's just a thing that annoys me. Anyway, thanks for your replies. I appreciate it.

Stay tuned for the next scintillating installment of Minor Rules Inconsistencies and the Unnecessarily Large Amount of Time I Spend Worrying About Them .

1 hour ago, edwardavern said:

This is fine for a 2-hour item, but becomes a problem for a 56-hour droid (and, I assume, will be exacerbated in the vehicle-crafting rules). It's a rare campaign where a PC has 56 hours of uninterrupted downtime (or more, if the GM insists that the character has to get some sleep). Such a check could feasibly take weeks of in-game time.

2hrs, 56 hrs, Size matters not. You roll, you know it'll take 48 hours instead of 56. So over the next few sessions you or your player describe them working on it whenever they have free time. 16 hours on their flight to cloud city, carry the droid parts in a bundle on your back, work on it another 6 hours while stuck in a prison cell. etc... You just work on it when you can. When you role play it a bit it is more enjoyable than "I rolled success, okay I crafted it".

Alternatively if what they are building will take a lot of time the burden is on the GM to create that downtime...on a related note Hyperspace can take quite a while, especially if you use it to move at the "speed of plot"

1 hour ago, edwardavern said:

If the roll determines that they take that full period and fail the check, do you, the GM, then insist that they spend that time, knowing that it will be unsuccessful? Can't think of anything more likely to really annoy a player, or make the disillusioned with the system.

Yes. You're worrying too much about the metagame. I will agree that if it was going to take 56 hours and you rolled and knew it would fail, and then took weeks/several sessions to resolve that would suck. The player would definitely have a hard time not meta-gaming and thinking "well I am in town and should pick up new parts to try again, even though technically I haven't failed yet because I have 12 hours left of work to be done".

This is exactly why rolling before/upfront is beneficial. Again, the solution here is the GM. If you know they fail you can make sure to give them a large bulk of that time without other things going on. A failed roll shouldn't end up being resolved over 4+sessions.

Also, the same as above goes for failure, be a little creative. Yes technically you know you failed when you roll upfront. But with a little role play it can turn into "I finally finished!" *turns on droid, motivator explodes* "oh no! I must have been distracted when I was installing it after we had just gotten away from the Nightsisters riding Rancors.

Also, I know this is counter to what I just said, but if you just cant get past the idea of failing a roll and then having to wait the full time...

There are technically two costs to failure, time and money. As the GM you can say that perhaps the cost of new parts and Half the time is sufficient on a failed roll. You can role play this to be right before they need to switch to something else describe it as "you break the delicate part as you come out of hyperspace and are attacked by pirates jostling the ship". So technically you know half way though you've failed. I would only use this method if the crafting was going to take days instead of hours and would significantly interrupt the game timetable.

12 hours ago, 2P51 said:

What fix? How is this any different than life? I mean how much software is written completely and no one knows what a craptastic shitfest it is until it's beta tested?

The PC crafts the droid, does everything they think correctly, and when they flip the switch it can't conjugate verbs. You have to remember they aren't assembling a kit, they are making something from scratch. You can buy lumber, build a table, level it, and then realize you F-ed up a measurement and it doesn't fit in the corner where you wanted to put it.

There is nothing wrong with the rules.

That's what test driven development is for, i personally assume everything i code is wrong until it is thoroughly tested, just before the refactor i started my project had 97% lin coverage and the test code had 95% line coverage, it has a "quick" (about 2 minutes) set of tests that auto execute with every check in, and a much more rigorous (about 2 hours) set of nightly automated validation tests. On any day where theres a checkin, the code coverage is computed from a combination of the quick and nightly tests, cmake is the build system and ctest wrapped by Jenkins executes the tests, Jenkins wraps cmake wraps doxygen to autogenerate the documentation Web site with every checkin... it's a library not an application so doxygen is sufficient documentation (i.e. I don't have a gui to take screen shots and write a normal user manual for) getter and setter function names are descriptive and include units in the names, the categorization package said that there was 1 line of comment for every 3 lines of "code"... feedback from application programers trying to integrate it revealed issues with them trying to massage the data they had into the form my library needed so I created another library for "reference frame transformation made easy" and the currently in progress refactor is to integrate the reference frame transformation library and make other usability improvements. There should be over 10K lines of code after the refactoring is done, and the parent library's cake will configure and execute the child libraries' cake build harness etc, when I'm done. And I'm executing valgrind on the quick tests to ensure that there are no memory errors (with the refactor I had to use pointers to avoid polymorphic slicing, normally I use references where ever possible to equivalent speed without the chance of memory errors wherever possible), by the way the 3% of code without line coverage before i started the refactor was primarily run time error handling code that doesn't get executed because it doesn't encounter the errors (if have run time error handling code that should be unreachable if the library is performing as intended, and so far it is).

That said, I believe that the total number of (non trivial) programs in the universe without bugs is less than or equal to 1 at all times... my goal is to make it less than or equal to 2.

This is the process I use:

1) Schematic: Find by rarity, lost schematics are essentially dungeon loot.

2) Materials: Schematic will tell how many units of each material are needed. Rarity + Cost/Aquisition (Mining, Gathering, etc.). Excellent materials add Boosts, crap material or hard to use material adds setbacks to the pool.

3) Workshop + Tools: Go/No-Go for wrong stuff/no stuff. Blues for good Tools, Setbacks and Diff for bad tools or not right workshop

4) Assembly: Rolls for several major components and then final assembly is a roll. I allow them to spend Destiny Points on these rolls.

I have to agree with 2p51. If they roll after and reduce their time by say 12 hours let them start another project or build something else that would take that time. All it means is that they need some more parts which you could hand wave that they ended up procuring more raw materials than they needed and can start something new. Or they could take the time to polish it up and test it out and maybe add some mods.

Heck you could look at the advantages they are spending and say that those advantages took up the extra time in refining and modding and such.

As far as failures... Yeah you are in hyperspace and get stopped by an interdictor right at a pivitol point part way thru and blam. There goes the droid chassis. Or the crew member start bickering over who shot the most stormmies and it distracts you and blam. There goes the power pack for that rifle... luckily it doesnt destroy the whole rifle and he only needs to find a few more items to complete it.

IMO, doing the dice roll first when crafting something is the prudent move because it allows you to account for everything before any time is used, but it's true the Special Modifications book doesn't really say much about how failures, creation time, and materials should be handled. I find it highly unlikely that a remotely competent mechanic wouldn't be able to figure out that something would fail to function entirely until it's already been completely built. Besides, unless the thing instantly explodes one could find the source of the issue and fix that, thus the object would still be usable. I'd say a failure is just an outright failure, that it's become readily apparent that you've screwed up so badly making something there's nothing you can do to salvage the project or that what you're working with to make it isn't up to snuff, such as the metal you're building a droid out of being too brittle to work with, which should be apparent fairly early in the process and thus take up much less than the time and materials needed to create the object as a whole.

A proper mechanic would test each component of whatever it was they were building individually to the furthest extent that is practical before putting it all together specifically to avoid using up time and materials making something only to find out it doesn't work. The time to make an object would probably account for both raw building time and testing each of the components to begin with, which is why more successes reduce time to make something makes sense, as you're getting each part of whatever it is you're building to work correctly the first time around thus the testing process takes much less time. The affects of threat upon success already accounts for crafted objects that are shoddily built in some way but still operable as it is.

I'm am currently working on a house rule for breaking down objects into crafting components. Using the different crafting charts we have from the other books for crafting droids, ranged and melee weapons, armor, and gadgets, I've tried to borrow heavily off those charts for coming up with the time it takes to break down objects into useful parts as well as how to spend Advantage, Triumphs, Threat, and Despair. I've created a separate post called Harvesting Components and I'm looking for opinions and suggestions from the community:

Can I suggest that if you want failures to happen faster, allow the mechanic to spend advantages on failure to reduce the time taken.

On 10/6/2017 at 10:03 AM, edwardavern said:

OK...well, maybe it's not a problem for anyone else. Maybe it's just a thing that annoys me. Anyway, thanks for your replies. I appreciate it.

Stay tuned for the next scintillating installment of Minor Rules Inconsistencies and the Unnecessarily Large Amount of Time I Spend Worrying About Them .

I'm a person who likes the crafting aspects of games. RPG, Video, or Tabletop, doesn't matter. I'm the type that @2P51 talks about, that decides "I want my gear to do X" Then crafts ad infinitum until I get it.

That's why it's not a minor rule inconsistency that a roll at the start of the craft ties you up. It's a choice to craft, there's a cost to it. Any time I spend crafting is time I'm not doing something else. If I could roll to make something and not worry about losing time if I fail, then there's no reason not to just check.

Me: I'm going to roll to craft uber-pistol

GM: Ok roll fails

Me: Ok then I'll go do something else then

I mean the GM is the one that's supposed to keep a person from trying to abuse the system like that, but holding the people to the time they commit to is the intended tool for that.

On 2017-10-06 at 4:34 PM, edwardavern said:

So...yeah, exactly...except for the "extra successes=time reduced" rule. If you make the check at the moment when you "flip the switch" (which is what I assume you're saying, and is also what I've been saying) then how do you reduce the time taken by 2 hours for each success? You can't. So you either have to roll at the beginning, or discard that rule.

I'm slightly concerned this thread has got a little out of hand - this is NOT a game-breaking problem. It's a tiny little problem that I can fix by just ignoring the rule. It's just...just a straw that's making my camel's back creak a little, is all.

Good points. I agree that for the reasons you stated, you should roll at the end, and that really messes up how you use extra successes, so how about instead you can reduce time on your next project, because maybe you manage to make so time saving innovations on your last project, such templates, jigs, half finished generic components?

Perhaps when you crafted that armor some ofter left over pieces of ultrachrome happens to only need some minor shaping to work as a casing for those macrobinoculars you were planning?

On 10/6/2017 at 10:34 AM, edwardavern said:

So...yeah, exactly...except for the "extra successes=time reduced" rule. If you make the check at the moment when you "flip the switch" (which is what I assume you're saying, and is also what I've been saying) then how do you reduce the time taken by 2 hours for each success? You can't. So you either have to roll at the beginning, or discard that rule.

I'm slightly concerned this thread has got a little out of hand - this is NOT a game-breaking problem. It's a tiny little problem that I can fix by just ignoring the rule. It's just...just a straw that's making my camel's back creak a little, is all.

I'd divorce the accumulation of crafting hours from the expenditure of crafting hours on specific devices. Treat crafting hours as earned XP, more or less, in that they aren't committed until it's time to acquire the talent or skill (or power). A few others have suggested something similar, I've noticed.

To elaborate, as circumstances allow during the campaign, the crafter may declare that they are spending time on crafting. You, as the GM, tell them how many hours of crafting time they manage to earn before campaign circumstances no longer allow it. Do NOT have them specify exactly what they are attempting to craft at that time. As hours accumulate, like earned XP, the PC may decide that they want to attempt to craft a new blaster pistol, for example, and makes the roll. If they have enough hours banked to afford the item, then huzzah! It's done and they just finished putting the final decorative touches on it. If they don't have enough hours banked, then they still need to earn the remaining hours before completion. So it'd be wise to save up hours until the character has a reasonable chance of completing it with the roll, but not mandatory. Any crafting hours that remain after the roll can still be used towards other projects, so successes aren't wasted.