The Robot Handbook is Here!

Yeah, that's what I meant. Sorry if I wasn't clear!

Though while I've got you, page 23:
... The robot's rate of movement may be increased by one Speed Band at the expense of an additional 10% of slots...
Is that in addition to the base 25% requirement (so, 35%), which is then rounded up, or is it after the initial rounding? So the Size 1 robot I keep talking about, would that be 1 slot for base speed and all associated increases, or 1 slot for base, then 2 for the first increase, 3 for the second, and so on?

I'd understand if it was the latter, though I would mourn the loss of my Subsonic Grav-Rat™.
 
Ok, three more things:



1) does p.62 mean that I can install an autobar in my battledress? Sweet!

(Or the slightly more serious autochef for tasty meals in the field)



2) Some bots, for example the battle mule and medium Zhodani warbot, have a listed speed of ‘-‘ along with a speed band trait. Does this mean they are only capable of moving at vehicle speed, or are they assumed to also have the default movement of 5 m per move action? This would also affect duration.



3) Mining drones. Been meaning to ask about them for quite some time, and since they’re presented here in greater detail than ever before, I might as well do it here.

How many drones can one operator handle, and how closely must they be controlled? Is it enough to just tap the screen and say ‘dig here’ or is direct input needed for each maneuver?



With its impressive INT of 0 it feels like they need some help, but the control interface might be smart enough to handle much of it? And come to think of it, perhaps a swarm controller is assumed to be part of the package, so a single drone operator can give broad instructions to all the drones and then when needed assume direct control over one of them for detailed work?
 
Ok, three more things:



1) does p.62 mean that I can install an autobar in my battledress? Sweet!

(Or the slightly more serious autochef for tasty meals in the field)



2) Some bots, for example the battle mule and medium Zhodani warbot, have a listed speed of ‘-‘ along with a speed band trait. Does this mean they are only capable of moving at vehicle speed, or are they assumed to also have the default movement of 5 m per move action? This would also affect duration.



3) Mining drones. Been meaning to ask about them for quite some time, and since they’re presented here in greater detail than ever before, I might as well do it here.

How many drones can one operator handle, and how closely must they be controlled? Is it enough to just tap the screen and say ‘dig here’ or is direct input needed for each maneuver?



With its impressive INT of 0 it feels like they need some help, but the control interface might be smart enough to handle much of it? And come to think of it, perhaps a swarm controller is assumed to be part of the package, so a single drone operator can give broad instructions to all the drones and then when needed assume direct control over one of them for detailed work?
1) Sure, why not.

2) I was following the 'standard' for the old text block. You can move at any speed a vehicle can, so you're not limited to 5m per action, but to whatever the vehicle can move in a action (since distances get abstracted in vehicle movement, that's a little clunky, but that the game mechanic)

3) Technically 1 drone, but 'dig here' should be good enough, though you should keep an eye on the INT 0 thing because it will keep digging to China (or whatever is beneath your feet) until you tell it to stop. Hopefully a safety protocol will stop it from severing a gas line - consider that part of hardwired 'Mining Equipment'. Mining drones are expensive enough that a swarm controller per 10 ton bunch would be a reasonable assumption. The Core description is vague enough to support.
 
Apologies, I was too vague above. If bots with vehicle speed movement and regular movement ‘-‘ always move in ‘vehicle mode’ then they would always reduce their endurance to a quarter, regardless of how fast they actually move, assuming I interpret this correctly:

p.23:
Vehicle speed movement reduces a robot’s endurance by a factor of four when in use. Each further movement enhancement halves the robot remaining endurance.


Assuming vehicle mode is their only form of locomotion their endurance is drastically lowered, except when standing still. Whereas if they had a regular movement as well, they could move slowly/tactically without running out of juice too quickly.

Is that correct, and if so, is it intended?
 
Apologies, I was too vague above. If bots with vehicle speed movement and regular movement ‘-‘ always move in ‘vehicle mode’ then they would always reduce their endurance to a quarter, regardless of how fast they actually move, assuming I interpret this correctly:

p.23:
Vehicle speed movement reduces a robot’s endurance by a factor of four when in use. Each further movement enhancement halves the robot remaining endurance.


Assuming vehicle mode is their only form of locomotion their endurance is drastically lowered, except when standing still. Whereas if they had a regular movement as well, they could move slowly/tactically without running out of juice too quickly.

Is that correct, and if so, is it intended?
It's a bigger engine, so yes, that's intended. Imagine a big truck idling its giant engine vs. a small car with a V4 engine. If the robot had a secondary locomotion mode, then it could use that instead. They could both be grav, or the secondary could be, well, anything.
 
It's a bigger engine, so yes, that's intended. Imagine a big truck idling its giant engine vs. a small car with a V4 engine. If the robot had a secondary locomotion mode, then it could use that instead. They could both be grav, or the secondary could be, well, anything.
Okay, I take all that back "when in use" is the key, and perhaps a split "5 / - " might be more appropriate.
I went back and looked at my creation spreadsheet (hey, its been a year since I turned this in, so I can't remember everything). You can take a tactical speed modification with the vehicle speed movement option so it only stands to reason that it works that way - plus, the spreadsheet is smart enough to put the quarter endurance in ( ). So tactical movement speed does not quarter endurance. - and no, there is no 'half speed' option unless you want to house rule it.
 
I've got some nitpicks on the Self-Destruct Systems, if'n you don't mind?
  • Offensive's damage is listed as Hits ÷ 2/3D, when the verbal explanation puts it at Hits x 2/3D. Utter nitpick, but it confused me the first read-through.
  • Offensive's damage also rounds down. Can I ask why this decision was made? It goes against convention, and it's another edge case with Size 1 robots; 0D damage. I was told that traditionally, 1D rounded down meant D3, so I'll probably implement that.
  • For Sizes 1-3, Defensive's Blast is greater than Offensive's, which feels a bit odd. Maybe Defensive's blast could be Size/2, rounded up?
  • I think Defensive & Offensive's damage listing in the table could be a bit clearer. Something like (Hits ÷ 6)D - Armour for Defensive, and (Hits x 2/3)D for Offensive?
Sorry for nattering on at you.
 
First nit has been noted and should be corrected.
Second, it wouldn't be 0 if we didn't fix the first nit.:unsure: It was done so that it wouldn't be so.. damaging...
Third... are you sure? Remember that a robot has inherent armour, unless you strip that when you're otherwise dismembering and gutting the robot.
Four... biggest problem other than the divide D that should be multiply D is the way it wraps
 
  1. Cheers!
  2. Fair enough, though I feel like packing an Offensive self-destruct option comes with an expectation of at least some damage. On that subject, what's your take on the D3 ruling?
  3. Pretty sure? Armour doesn't factor into Blast in Offensive or Defensive. It also depends on TL, not Size, so I'm not sure how the maths changes.
  4. Yeah, but the current table wraps awkwardly as well. I think the change fits it in. That, and the brackets. The lack of them tripped me up in the first read-through.
One more thing- I'm probably just ignorant of what's going on under the hood, but some paragraph breaks between the details on the Offensive, TDX, and Nuclear systems would improve readability. I think there's room, but again, ignorance.
 
I want to buy this, but holy moly the amount of errors being raised in this thread! Mongoose being Mongoose I guess, which isn't a good thing. Mongoose needs to overhaul their editing and reviewing process at a corporate level.

And add dates and versions to all PDF and hard copies of their products.
 
I want to buy this, but holy moly the amount of errors being raised in this thread! Mongoose being Mongoose I guess, which isn't a good thing. Mongoose needs to overhaul their editing and reviewing process at a corporate level.

And add dates and versions to all PDF and hard copies of their products.
Nah, we're just nattering about edge cases, here. For just about everything you're going to make, the rules work fine. It's well worth the money.

... Editing could use an overhaul, though. And dates/versions would be appreciated.
 
Nah, we're just nattering about edge cases, here. For just about everything you're going to make, the rules work fine. It's well worth the money.

... Editing could use an overhaul, though. And dates/versions would be appreciated.

I wish that were the case, but missing a whole table of data isn't nattering about edge cases. And this isn't the first time Mongoose dropped a table in their editing/reviewing. Fortunately it sounds like this instance has been caught in time for fixing the hard copies. My concern (as always with Mongoose) is if something that drastic can be messed up, then what else is there that won't be caught in time for the printers?
 
I wish that were the case, but missing a whole table of data isn't nattering about edge cases. And this isn't the first time Mongoose dropped a table in their editing/reviewing. Fortunately it sounds like this instance has been caught in time for fixing the hard copies. My concern (as always with Mongoose) is if something that drastic can be messed up, then what else is there that won't be caught in time for the printers?
That is one of the reasons I like buying the PDF early, then I can help catch mistakes before the send it to the printers. :)
 
I wish that were the case, but missing a whole table of data isn't nattering about edge cases. And this isn't the first time Mongoose dropped a table in their editing/reviewing. Fortunately it sounds like this instance has been caught in time for fixing the hard copies. My concern (as always with Mongoose) is if something that drastic can be messed up, then what else is there that won't be caught in time for the printers?
To be fair, that table was mostly fluff, I get why it was cut.
 
  1. Cheers!
  2. Fair enough, though I feel like packing an Offensive self-destruct option comes with an expectation of at least some damage. On that subject, what's your take on the D3 ruling?
  3. Pretty sure? Armour doesn't factor into Blast in Offensive or Defensive. It also depends on TL, not Size, so I'm not sure how the maths changes.
  4. Yeah, but the current table wraps awkwardly as well. I think the change fits it in. That, and the brackets. The lack of them tripped me up in the first read-through.
One more thing- I'm probably just ignorant of what's going on under the hood, but some paragraph breaks between the details on the Offensive, TDX, and Nuclear systems would improve readability. I think there's room, but again, ignorance.
1. Not 5 o'clock where I am yet, so no drinking, unfortunately.
2. If you want to do D3, go ahead, but I'm not sure it warrants the extra space, I think the book is near the limit without extra expense in the production process as it is.
3. Sorry, read it as damage, not blast, which was why I was confused. Yeah, annoying edge case, but not going to redo it - little debris flies farther but does less damage.
4. Fonts are what fonts are. Margins are what margins are.
5. See #2 and #4.
 
I want to buy this, but holy moly the amount of errors being raised in this thread! Mongoose being Mongoose I guess, which isn't a good thing. Mongoose needs to overhaul their editing and reviewing process at a corporate level.

And add dates and versions to all PDF and hard copies of their products.
You'll get a notice when it gets fixed. The pdf is out early so the stuff that snuck through can get fixed before the printed version. People are in a rush combing it to clarify and get the fixes in time.
 
I still think a team of volunteers before anything is even released on pdf would go a long way = I know a lot of peopple have issued with paying for playtest material but let's face it you are going to buy it anyway so doing some of the error checking behind closed doors so to speak may well help improve the quality of the products at zero cost to Mongoose. You would need trusted volunteers or protected files or both but it is doable.
 
I still think a team of volunteers before anything is even released on pdf would go a long way
While this is a really good idea, and probably necessary, it doesn't fix the issue of Mongoose's processes (in my opinion).

No amount of eyes are going to fix the issues that allow an already corrected error to be reintroduced into a new product, like what happened with the Core Rulebook 2022 release, where it reintroduced issues that were fixed in previous reissues of the original CRB. I find it crazy how that is possible.
 
Back
Top