VBAM Second Edition Errata
- japridemor
- Lieutenant
- Posts: 39
- Joined: Sat Oct 06, 2007 1:43 am
- Location: Orlando, FL
Re: VBAM Second Edition Errata
This still leaves a question in my mind for ULF.
If the base calculation for flights/minefields is
(ISD-3000)/24*2
and for ULF we subtract two(2), then the result at ISD=3000 is:
(3000-3000)/24*2 -2 or 0/24*2 -2 = -2
So my base design at the beginning of a campaign is 3-2 or only 1 CP?
Take ISD 3006 for example:
(3006-3000)/24*2 is the base advancement in CP for flight/minefield
rounding to the nearest whole number gives a result of one (1).
If MF is the base and we add and/or subtract one from there that give me:
CP results
ULF = 3+(-1)
LF = 4+0
MF = 5+1
HF = 6+2
SHF = 7+3
If the base calculation for flights/minefields is
(ISD-3000)/24*2
and for ULF we subtract two(2), then the result at ISD=3000 is:
(3000-3000)/24*2 -2 or 0/24*2 -2 = -2
So my base design at the beginning of a campaign is 3-2 or only 1 CP?
Take ISD 3006 for example:
(3006-3000)/24*2 is the base advancement in CP for flight/minefield
rounding to the nearest whole number gives a result of one (1).
If MF is the base and we add and/or subtract one from there that give me:
CP results
ULF = 3+(-1)
LF = 4+0
MF = 5+1
HF = 6+2
SHF = 7+3
- Tyrel Lohr
- Vice Admiral
- Posts: 1466
- Joined: Thu Oct 04, 2007 3:48 am
- Location: Lusk, WY
- Contact:
Re: VBAM Second Edition Errata
You would look up the ULF's base CP on the Flight/Minefield Table, which is 3, then apply the tech bonus from its In-Service Date. If you're at Year 3000 then you're at the base Tech Year and there isn't a tech bonus. If you're at Year 3006, then the calculation would be:
(3006-3000)/24*2 = +0.5 which rounds to +1 CP. This bonus is applied to the ULF, which gives it 4 CP at that point (3 CP base + 1 CP tech bonus).
The LF is now at 5 CP, MF at 6 CP, HF at 7 CP and SHF at 8 CP. They've all gained +1 CP at that Tech Year, and the +1 CP is applied uniformly because all of the archetypes.
This is why the rules try to point out that the flights are all growing at a steady rate versus the variable rate that the ship/base templates increase based on their Construction Costs.
(3006-3000)/24*2 = +0.5 which rounds to +1 CP. This bonus is applied to the ULF, which gives it 4 CP at that point (3 CP base + 1 CP tech bonus).
The LF is now at 5 CP, MF at 6 CP, HF at 7 CP and SHF at 8 CP. They've all gained +1 CP at that Tech Year, and the +1 CP is applied uniformly because all of the archetypes.
This is why the rules try to point out that the flights are all growing at a steady rate versus the variable rate that the ship/base templates increase based on their Construction Costs.
[i]"Touch not the pylons, for they are the messengers!"[/i]
- Tyrel Lohr
- Vice Admiral
- Posts: 1466
- Joined: Thu Oct 04, 2007 3:48 am
- Location: Lusk, WY
- Contact:
Re: VBAM Second Edition Errata
If it helps, think of it this way: the Medium Fighter is the "standard" size/configuration of a flight. The steps above and below that are just a case of you either cramming more equipment onboard (increasing the cost) or stripping them down (to save money and decrease the cost). And that standard Medium Fighter has a tech curve that matches that of the Corvette, even if it starts with the same amount of CP as a Gunboat.
I toyed with having the flight CP actually match that of a GB (instead of a CT), but didn't allow for meaningful flight development during a typical campaign.
I toyed with having the flight CP actually match that of a GB (instead of a CT), but didn't allow for meaningful flight development during a typical campaign.
[i]"Touch not the pylons, for they are the messengers!"[/i]
- japridemor
- Lieutenant
- Posts: 39
- Joined: Sat Oct 06, 2007 1:43 am
- Location: Orlando, FL
Re: VBAM Second Edition Errata
By this example the ULF is the base, not the MF, with each size above it getting a +1 CP.
Tyrel Lohr wrote:You would look up the ULF's base CP on the Flight/Minefield Table, which is 3, then apply the tech bonus from its In-Service Date. If you're at Year 3000 then you're at the base Tech Year and there isn't a tech bonus. If you're at Year 3006, then the calculation would be:
(3006-3000)/24*2 = +0.5 which rounds to +1 CP. This bonus is applied to the ULF, which gives it 4 CP at that point (3 CP base + 1 CP tech bonus).
The LF is now at 5 CP, MF at 6 CP, HF at 7 CP and SHF at 8 CP. They've all gained +1 CP at that Tech Year, and the +1 CP is applied uniformly because all of the archetypes.
This is why the rules try to point out that the flights are all growing at a steady rate versus the variable rate that the ship/base templates increase based on their Construction Costs.
- Tyrel Lohr
- Vice Admiral
- Posts: 1466
- Joined: Thu Oct 04, 2007 3:48 am
- Location: Lusk, WY
- Contact:
Re: VBAM Second Edition Errata
It's a case of semantic, but the rules use the MF as the baseline (5 CP) with -2 ULF, -1 LF, +1 HF, +2 SHF, so that it is a +-2 range from the baseline. The tech bonus is fixed for all flights/minefields regardless of size.japridemor wrote:By this example the ULF is the base, not the MF, with each size above it getting a +1 CP.
We are talking in circles as far as baselines are concerned, as the result is the same.
[i]"Touch not the pylons, for they are the messengers!"[/i]
Re: VBAM Second Edition Errata
Question about the Ground Force quality 'Robotic.'
Right now, it says the cap on the number of Robotic units built per turn is equal to a system's Utilized Productivity and that they don't count towards 'normal production limits'. The cap on the construction of normal units is Census. However, Utilized Productivity is either Census or Productivity - whichever is lower.
If that's the case, a system with Census 4 and Productivity 9 would have Utilized Productivity 4. It could produce 4 robotic units....or 4 normal and 4 robotic units. BUT the System's total Construction Capacity is equal to its UP * Raw, which makes it unlikely that most systems will be less than able to use this advantage to produce extra robotic units, unless they have very high raw ratings.
It seems the intent that Robotic units instead are "extra" - that is, if my empire is totally flush with cash, I can build 4 regular units (my Census cap of 4) and 4 robotic units that same turn?
That seems like a small advantage to make up for Robotic unit's increased maintenance, one only useful when you are already totally rolling in cash and Census and Raw on certain planets.
Is that really the only advantage of Robotic units? Were they intended to use raw Productivity rather than Utilized Productivity, so that heavily industrialized planets can produce tons of robots regardless of their human population?
In situation like this, the UP of a planet might be 2 or 3 (a planet with low census but high productivity), but they would use the planet's high Productivity to produce robotic soldiers. Alternatively, Robotic count for less of a planet's Construction Capacity? So where I could produce one normal ground unit for one of my planet's construction capacity, I could instead produce two Robotic units?
Sorry, I have cinematic visions of empires which use automated factories churning out robots for most of their ground forces after most of their population was lost in brutal planetary bombardments. I know it's a bit off-the-wall as an errata question.
Right now, it says the cap on the number of Robotic units built per turn is equal to a system's Utilized Productivity and that they don't count towards 'normal production limits'. The cap on the construction of normal units is Census. However, Utilized Productivity is either Census or Productivity - whichever is lower.
If that's the case, a system with Census 4 and Productivity 9 would have Utilized Productivity 4. It could produce 4 robotic units....or 4 normal and 4 robotic units. BUT the System's total Construction Capacity is equal to its UP * Raw, which makes it unlikely that most systems will be less than able to use this advantage to produce extra robotic units, unless they have very high raw ratings.
It seems the intent that Robotic units instead are "extra" - that is, if my empire is totally flush with cash, I can build 4 regular units (my Census cap of 4) and 4 robotic units that same turn?
That seems like a small advantage to make up for Robotic unit's increased maintenance, one only useful when you are already totally rolling in cash and Census and Raw on certain planets.
Is that really the only advantage of Robotic units? Were they intended to use raw Productivity rather than Utilized Productivity, so that heavily industrialized planets can produce tons of robots regardless of their human population?
In situation like this, the UP of a planet might be 2 or 3 (a planet with low census but high productivity), but they would use the planet's high Productivity to produce robotic soldiers. Alternatively, Robotic count for less of a planet's Construction Capacity? So where I could produce one normal ground unit for one of my planet's construction capacity, I could instead produce two Robotic units?
Sorry, I have cinematic visions of empires which use automated factories churning out robots for most of their ground forces after most of their population was lost in brutal planetary bombardments. I know it's a bit off-the-wall as an errata question.
- Tyrel Lohr
- Vice Admiral
- Posts: 1466
- Joined: Thu Oct 04, 2007 3:48 am
- Location: Lusk, WY
- Contact:
Re: VBAM Second Edition Errata
It's a good question, and this might be a case of the scale of the game shifting during the final year of development. I think Utilized Productivity is the intended stat, because any Productivity that doesn't have a Census to run it is sitting idle and can't do anything. The though with Robotic is that it allows you to churn out troops regardless of the planet's Census value. As it stands, the maximum number of ground forces that can be under construction at one time is equal to the system's Census value. If you're building several more expensive ground forces, you can quickly run out of manpower. At one point ground forces didn't count against construction capacity limits, and I think that change didn't get pushed to this Robotic ability like it should have.
I think you're right that Robotic probably needs to be updated to give a better accounting for itself based on its current cost. The option that I think might be best is to have the Robotic unit's Construction Cost not count against the system's construction capacity. That would fit the bill of letting a system churn out mass quantities of these troops without affecting other production. This also makes the fewest changes to the existing rules.
What do you think?
I think you're right that Robotic probably needs to be updated to give a better accounting for itself based on its current cost. The option that I think might be best is to have the Robotic unit's Construction Cost not count against the system's construction capacity. That would fit the bill of letting a system churn out mass quantities of these troops without affecting other production. This also makes the fewest changes to the existing rules.
What do you think?
[i]"Touch not the pylons, for they are the messengers!"[/i]
Re: VBAM Second Edition Errata
Tyrel, I think not counting Robotic units against the Construction Capacity gets right at what I was thinking about. An additional maintenance cost needs to be worth something more than it was - though of course I've got no rigorous playtesting behind my intuition here, allowing rapid build-up of Robotic forces in that way seems to help us get our money's worth from them.
- Tyrel Lohr
- Vice Admiral
- Posts: 1466
- Joined: Thu Oct 04, 2007 3:48 am
- Location: Lusk, WY
- Contact:
Re: VBAM Second Edition Errata
Give it a playtest and let me know how it turns out, BroAdso! I'll do the same on this side. Then if the results are good I'll officially add it to the errata here, and get a semi-final (to this point) errata sheet posted to the website.
[i]"Touch not the pylons, for they are the messengers!"[/i]
Re: VBAM Second Edition Errata
Read through my copy of 2e today and had a question:
In 3.4.1 Intel
It says that "If a system loses Census, the maximum amount of Intel that it can support will also decrease. Any points . . . in excess of its new census value are lost. These spies were killed in whatever catastrophic event"
Question I would have though is what about Colony Fleets? If the owning empire of that world lowers the census by having it board ships, would those spies still be lost? Or would that intel point move with the census, potentially perpetuating spies throughout an empire? The example seems to only account for a violent reduction in census.
In 3.4.1 Intel
It says that "If a system loses Census, the maximum amount of Intel that it can support will also decrease. Any points . . . in excess of its new census value are lost. These spies were killed in whatever catastrophic event"
Question I would have though is what about Colony Fleets? If the owning empire of that world lowers the census by having it board ships, would those spies still be lost? Or would that intel point move with the census, potentially perpetuating spies throughout an empire? The example seems to only account for a violent reduction in census.
- Tyrel Lohr
- Vice Admiral
- Posts: 1466
- Joined: Thu Oct 04, 2007 3:48 am
- Location: Lusk, WY
- Contact:
Re: VBAM Second Edition Errata
I think this question came up once before, and the spot rule for now (which needs to be codified in errata) was to have the Intel point move with its associated Census. Tracking that becomes a bit messy, but it might be the only way to ensure that the Intel isn't zooming across the map on its own. The alternative, which is easier to track, would be to have the Intel move to the next closest system -- but that opens up another can of worms entirely.
[i]"Touch not the pylons, for they are the messengers!"[/i]
Re: VBAM Second Edition Errata
Or could just be that you refund 50% of the investment cost as the local intel is forcible downsized. Can cite that they weren't able to pass the screening required for the colony ship.
- murtalianconfederacy
- Captain
- Posts: 363
- Joined: Sat Oct 06, 2007 9:17 am
- Location: Aboard the MCS Bavoralkin
Re: VBAM Second Edition Errata
You could make an argument that the Census point isn't being lost, it's simply being transferred... [ALERT: THIS UNIT REQUIRES MORE COFFEE ]
But I'm of the opinion that it would make sense to transfer the Intel point along with the Census. After all, if you've got a big enough intelligence section in a system that Intel is equal to Census, your intel chiefs/police force/peacekeeping force etc. are probably going to want to have some of their assets keep track of the new colony to ensure no criminals, dissidents, rebels etc., make the journey and are able to either set up an underground network or spread seditious thoughts amongst the populace.
But I'm of the opinion that it would make sense to transfer the Intel point along with the Census. After all, if you've got a big enough intelligence section in a system that Intel is equal to Census, your intel chiefs/police force/peacekeeping force etc. are probably going to want to have some of their assets keep track of the new colony to ensure no criminals, dissidents, rebels etc., make the journey and are able to either set up an underground network or spread seditious thoughts amongst the populace.
Not every laser dot has a loaded gun at the end of it
Re: VBAM Second Edition Errata
Not errata per se, but one thing I might recommend is not numbering the cover page for the PDF version of the rulebook. They do this for Battletech, the front and rear cover I believe are both assigned letters like A, B or something like that instead of 1,2 etcetera. The benefit of this is when you look at the index the pages in the index will match those of the PDF. Currently if I want to get to page 54 I have to type 55 into the page box in the interface. Probably don't need it for the rear page if you keep it at the back (some PDFs move it after the first cover for some reason)
It's a minor thing but I think it does add a lot of polish if the software you have allows for it.
It's a minor thing but I think it does add a lot of polish if the software you have allows for it.