PDA

View Full Version : BSODs + Programming Oversights



NEPHiLiX
October 7th, 2010, 15:48
~I posted this in the House of Healing section where it was suggested that I re-post here~

First, I've been getting BSOD's like mad until I switched to the Beta version (2.7). It was fantastic! Got through 15 rounds of combat with multiple opponents and many books open and no crashes!! Thank you!!!

I did, however, notice a few problems. The first was the dice rolling: the d100 was strange. On the d100, the tens (the first number you read) is noted in "tens" (10, 20, 30 ,40 etc) on the die, while the # that follows is noted in single digits (5, 6, 7, 8, 9, 0, etc). On the program's dice, however, the "0" is noted as "10"). The problem occurs when you roll a "10" on the single-digit die. A roll of 80 + 10 should result in an "80" (80 + 0), not "90". Can I change this to the standard read (where a 00 is a 100)?

Second, the subtraction of rounds of Stun/No Parry/etc should only occur at the end of the next round. For example the program behaves this way:

~first round~
"Foe" swings...misses
"Opponent" strikes...hits, stuns foe for one round.

~next round~
"Foe" swings (because moving to the next round reduces that one round of stun even though "Foe" had already fully acted in round 1). In this instance, it is impossible for "Opponent" to stun "Foe" unless he stuns him for more than 1 round (giving the faster "Foe" a distinct advantage, 1 round of stun can prevent "Opponent" from ever acting, but 1 round of stun delivered to "Foe" will never do anything).

Otherwise, loving the automation!

StuartW
October 7th, 2010, 22:01
The d100 approach is built into FG, but could be overcome by some ruleset cunningness. We just weren't that cunning and thought the FG users were used to the protocol anyway. I think it would have been good to include a preference to change the behaviour (likewise for BRP too), but it isn't there.

The effects not responding to the correct action sequence is a mystery: I remember building the code (there is even a 'turncomplete' flag in the Lua script to track if an effect is applied before or after a player/NPC has completed its turn), but it seems not to have made it into the final code base - can't say how that might have happened, given the amount of RM community involvement this had.

Both items could be fixed, and perhaps should be swept up in a future update.

StuartW

NEPHiLiX
October 31st, 2010, 18:40
Another thing...I don't know why, but the token re-sizing hasn't been working for me since version 2.72. I used to use it all the time, and now I can't. It's very frustrating. I've done everything. CTRL + mousewheel on the combat tracker, unlocked the token scaling, tried re-sizing the token on the map itself, etc. Nothing works.

Any help?

GunnarGreybeard
November 1st, 2010, 03:06
Another thing...I don't know why, but the token re-sizing hasn't been working for me since version 2.72. I used to use it all the time, and now I can't. It's very frustrating. I've done everything. CTRL + mousewheel on the combat tracker, unlocked the token scaling, tried re-sizing the token on the map itself, etc. Nothing works. Hmm, mine was working in last Tuesday night's game. It did seem like the zone "if that's the correct term" where the hand/pointer had to be placed on the token itself seemed smaller but was working when I did it.

NEPHiLiX
November 2nd, 2010, 00:07
Thanks Gunnar...that's what it was. I guess I just kept missing that little zone.