alt.binaries.e-book.rpgShow header Prev. Next
Re: TSR Initiative: Battle System Box Set (1st Ed) - "Battle System Box Set (1E).pdf" (00/14) 4.0 MBytes yEnc
Vreejack (homeless.beggar@internet.crossroads.usa) 2015/12/13 21:55

On Sun, 13 Dec 2015 23:52:09 -0500, Vreejack
<homeless.beggar@internet.crossroads.usa> wrote:

>On Sat, 12 Dec 2015 16:32:01 -0500, Spanky The Man
><SpankyTheMan@gmail.com> wrote:
>
>>As most of us probably know, Dungeons & Dragons was birthed from
>>miniature war-gaming; TSR in fact once stood for "Tactical Studies
>>Rules", reflecting these origins. And in its earliest revisions, D&D
>>was quite noticably just an expansion to miniature wargaming; in fact,
>>for its first few iterations, whenever combat mechanics were required,
>>players were expected to refer to the miniature rules to resolve the
>>conflict. But as the system evolved, D&D slowly distanced itself from
>>its roots and became it's own unique - and profitable - thing.
>>
>>But TSR never quite gave up on minature war-gaming, and eventaually
>>they created their own updated rules: TSR 1019 Battle System Fantasy
>>Combat Supplement. And TSR went big with their introduction of the
>>system, releasing it in a double-sized boxed-set that included maps,
>>cardboard cutouts for 3D objects and terrain, counters and cut-outs
>>for the armies, and even two metal miniatures. But for all that effort
>>- and a generally favorable critical reception -  Battle System never
>>really caught on, although TSR made effort to include scenarios for
>>the system in some of its AD&D modules.
>>
>>This box-set is not complete. In fact, it is possibly one of the least
>>complete D&D boxed sets in my collection. Although it has all the
>>rulebooks (OCRd and bookmarked, as usual), it has none of the cutouts
>>or counters (these are incredibly hard to find because - obviously -
>>everyone cut them out to use in the game). Well, at east it gives you
>>an idea of how the game is played even if it doesn't come with any of
>>the fun accessories.
>
>
>All the threads I can see below this (a dozen?) are threading and
>collating properly, btw. So no manual join necessary. I need to figure
>out why. I guess I can split them back up and examine the headers.

It looks like the reason is this: In the current sets you have a file
name in quotes before the (x/y) iterator. The last batch did not have
a filename and so my reader treated them as 300 seperate messages.

Follow-ups:12
Next Prev. Article List         Favorite