Loading ...
Sorry, an error occurred while loading the content.

Re: [PCGenListFileHelp] [No Bug] Re: Increasing base speed

Expand Messages
  • Ainvar G
    OK, for those following along, this was not a corruption issue on the user s machine and reinstalling that version of PCGen twice had no effect. The ultimate
    Message 1 of 14 , May 20, 2010
    • 0 Attachment
      OK, for those following along, this was not a corruption issue on the user's machine and reinstalling that version of PCGen twice had no effect. The ultimate issue was with an apparently antiquated format I was using for a PREVAR for the ability in question (and several others in the same dataset). That's what I get for pulling code from outdated datasets, I guess.

      Thanks to Andrew for staying with the issue and helping me get to the bottom of it.




      ________________________________
      From: Andrew Maitland <drew0500@...>
      To: PCGenListFileHelp@yahoogroups.com
      Sent: Wed, May 19, 2010 11:46:28 PM
      Subject: Re: [PCGenListFileHelp] [No Bug] Re: Increasing base speed


      Hi Folks,

      Okay, I tested 5.17.3(build 11891); 5.16.1, then rebuilt to 5.16.2. In
      each case the Barbarian Fast Move is working as intended.

      I am unable to duplicate this issue. Also, I added the Barbarian Test
      deal to Bob, but BarJack should have been having failures if the Fast
      Move wasn't working.

      Need more input from the user as this sounds like possibly a corruption
      on the users machine.

      On 5/19/2010 9:27 PM, Andrew Maitland wrote:
      > Hi Folks,
      >
      > Doing a few quick tests, this isn't a bug in the 5.17 line (Updated Bob
      > works fine).
      >
      > I'll have to look at the 5.16 and see if there is anything acting up
      > there. But if we do find anything, will we be releasing a 5.16.3?
      > Otherwise, if this is a bug, it's already been fixed in the next version(s).
      >
      >
      > On 5/19/2010 2:21 PM, thpr wrote:
      >
      >> Either way, I think we have a bug if it doesn't work in Barbarian.
      >>
      >> TP.
      >>
      >> --- In PCGenListFileHelp@yahoogroups.com, Ainvar G<ainvarg@...> wrote:
      >>
      >>
      >>> Well, now I can't make it work in 5.17.1, either. I was about to say that I don't understand why it works in the barbarian base class and not in my prestige class, but I realized I _was_ overlooking something obvious -- I hadn't verified that it was actually working in the barbarian class. So I did a little testing -- and as near as I can tell, the speed increase from Fast Movement is not working there, either. This was adding barbarian as a second class, please note.
      >>>
      >>> I confirmed that in both 5.16.2 and 5.17.1, a first-level human barbarian has a base speed of 40 feet, so that is working. Is it possible that the speed increases are only taking effect for a first-level character, so my FTR5/PrC1 isn't getting the option?
      >>>
      >>> AinvarG
      >>>
      >>>
      >>>
      >>>
      >>> ________________________________
      >>> From: Ainvar G<ainvarg@...>
      >>> To: PCGenListFileHelp@yahoogroups.com
      >>> Sent: Wed, May 19, 2010 1:16:37 PM
      >>> Subject: Re: [PCGenListFileHelp] Re: Increasing base speed
      >>>
      >>>
      >>> Ah. So, for the meantime, it would seem like I should be able to mimic the code for the barbarian class, whatever form that code takes, even though it does not match the docs. Initial attempts to do so are not working, but I have an idea.
      >>>
      >>> Would it make a difference (not _should_ it, but _could_ it make a difference) if the value being passed into the BONUS is a literal as opposed to a variable? My code is trying to use a variable so I can increase it as the character goes up in level, but the barbarian uses a literal because it's a one-time increase.
      >>>
      >>> Note: My testing in 5.16.2 indicates that it doesn't work in either case. My testing in 5.17.1 indicates that the literal works in Preview, but not on the first tab of the PCGen interface, while variables don't appear to be working anywhere.
      >>>
      >>> I'm off to do some more testing because I have the nagging feeling that I'm overlooking something obvious.
      >>>
      >>> ________________________________
      >>> From: thpr<thpr@...>
      >>> To: PCGenListFileHelp@yahoogroups.com
      >>> Sent: Wed, May 19, 2010 12:52:50 PM
      >>> Subject: [PCGenListFileHelp] Re: Increasing base speed
      >>>
      >>> No. It shouldn't always be anything, unfortunately.
      >>>
      >>> We are in a transition between two systems used to load data from the LST files. Those that have made the transition (90%+ of the tokens) will recognize either TYPE= or TYPE. (with - I think - one or two exceptions) but will always write TYPE= (with the same exceptions).
      >>>
      >>> The problem we have is that NEITHER TYPE. nor TYPE= can be used universally... so "settling" on one is a result of being able to re-architect tokens around the current design problems. It is one of many things on the list.
      >>>
      >>> As a note, BONUS happens to be one of the tokens still in the "old" system, so its behavior is less well defined.
      >>>
      >>> My concern was simply that the TYPE= TYPE. distinction is confusing. People say TYPE= is for assignment, but precisely what is "assignment"? The problem is what we use TYPE in different places to mean different things (thinking specifically of TYPE= on the end of BONUS tokens as a second use case). We need to fix that and not reuse magical words... we just need control over the BONUS token before we can do it.
      >>>
      >>> TP.
      >>>
      >>> --- In PCGenListFileHelp@yahoogroups.com, Ainvar G<ainvarg@> wrote:
      >>>
      >>>
      >>>> Still need to test my data in 5.17.1, but it doesn't appear to be wrong though it fails in 5.16.2.
      >>>>
      >>>> By this remark, are you saying that it should always be "TYPE="?
      >>>>
      >>>> AinvarG
      >>>>
      >>>>
      >>>>
      >>>>
      >>>>
      >>>> ________________________________
      >>>> From: thpr<thpr@>
      >>>> To: PCGenListFileHelp@yahoogroups.com
      >>>> Sent: Tue, May 18, 2010 6:04:39 PM
      >>>> Subject: [PCGenListFileHelp] Re: Increasing base speed
      >>>>
      >>>>
      >>>>
      >>>>
      >>>> --- In PCGenListFileHelp@yahoogroups.com, Andrew Maitland<drew0500@> wrote:
      >>>>
      >>>>
      >>>>> TYPE= is supposed to me you are assigning that "TYPE"
      >>>>> TYPE. is supposed to use the calling of that type.
      >>>>>
      >>>>>
      >>>> This is IMHO confusing and shouldn't be quoted, nor is it consistent with how the code outputs tokens. The converter will now write out TYPE= in all cases where the "new" tokens control input/output. There is only one token where this will not work, but I forget which at the moment. Something with weaponprofs...
      >>>>
      >>>>
      >>>>
      >>>>> This is something we should probably address soon.
      >>>>>
      >>>>>
      >>>> We will address it as soon as we have 100% control in the new token system, which may take a while to get through the BONUS tokens.
      >>>>
      >>>> TP.
      >>>>
      >>>>
      >>>>
      >>>>
      >>>>
      >>>>
      >>>>
      >>>> [Non-text portions of this message have been removed]
      >>>>
      >>>>
      >>>>
      >>> [Non-text portions of this message have been removed]
      >>>
      >>>
      >>>
      >>>
      >>>
      >>>
      >>>
      >>> [Non-text portions of this message have been removed]
      >>>
      >>>
      >>>
      >>
      >>
      >> ------------------------------------
      >>
      >> Yahoo! Groups Links
      >>
      >>
      >>
      >>
      >>
      >>
      >

      --
      Andrew Maitland

      [Non-text portions of this message have been removed]







      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.