Keep 3.5 Alive!

[Gabriel Penn]

Greetings!

This is a forum for anyone who in interested in using 3.5 d20SRD as a working definition. Its creator, Moon Wizard, is not supporting the project as fully as he used to be. I’m not pretending to fill his shoes (since I really can’t script worth a damn!), but over the last few months, I’ve managed to reverse engineer enough of his work to fix a few bugs and add a little functionality to the definition.

Here are a few of the fixes and features I’ve worked out:
- Fixed the Turn Undead feature (making it a button in the spells portion of the dice panel. Also, I hacked the 3.5 turn script so it works with the 3.5 d20SRD definition--so it actually works rather than displaying the “No Targets Selected” dialogue.)
- Added an Ammo table almost exactly like the one in the 3.0 def that ships with kLoOge 3.2.2
- Added a Weapon Style AC button for character sheets and the dice panel for a little added flexibility for high level fighters that pick up feats that can change their AC at certain times during combat. (I’m sure that many gamers will find some use for this.)
- Reworked the text files behind the spell powers and spells so they better support clerics and domain spells and granted powers. (I’ve also finished the data files, including KS1 expressions, for about half of the thirty-odd new domains in the FR campaign setting)
- And much more...

I resolved to start this topic after many frustrated nights of dealing with a buggy 3.5 d20SRD game. I always hoped to find a user community in the forums that supported this def (and its scripts and text files) but never really managed to. So… I’m starting one.

So, all of you 3.5 d20SRD masters out there? Please watch this topic from time to time and share some of your secrets. Newbies? Feel free to ask any questions you like. Hopefully, if we work together, we can all enjoy a functional kLoOge game using this def.

Regards,
Gabriel Penn

[Gabriel Penn]

Woo Hoo!

I've been trying to crack this problem for a while now, and I think I've finally figured out a quick and easy solution to the problem of Flat-Footed-AC actually being higher than it should be.

The Rules:
In D&D 3.0 and 3.5, Flat-Footed creatures don't receive Dexterity bonuses to their Armor Class. Dexterity penalties, however, still apply as normal.

The Problem:
As many of you have noticed, Flat-Footed AC is sometimes higher than it should be because it doesn't include Dexterity modifiers to AC. When you have an icon with a negative Dex modifier, its other AC's will account for this and be reduced as they should be. Unfortunately, in this case at least, the Flat-Footed AC field doesn't factor for Dexterity. Therefore the Flat-Footed AC for this icon will actually be higher because it is lacking a negative modifier. I've seen a few attempts at workarounds (and I've tried several myself) with the Dexterity Modifier fields. While some of these work to varying degrees, almost all of them have to be applied on an icon by icon basis. Furthermore, the workaround often has to be undone and redone when accounting for a spell effect that temporarily raises the Dexterity modifier to a positive number (like Cat's Grace, for instance). For me, a truly workable solution had to satisfy all these objectives:
1. It must be maintenance free. I shouldn't have to make constant character sheet adjustments on the fly.
2. It has to be standard for all icons. Basically, it has to work all the time or not at all.
3. It has to be definition flexible. While I use the 3.5-d20SRD, I wanted this solution to be universal enough to benefit all definitions with only slight modification.
4. It has to work with the available scripts. I think we can all mess with our def files without too much hassle. Scripting, on the other hand, is esoteric and confusing to me. Moreover, even if I was a scripting pro, changing scripts simply kills the possibility of uniform definitions that are useful to the community. Any solution that required script modification was right out.

The Solution:
By making two simple changes to the definition file, this problem can be fixed. I'll demonstrate with the 3.5-d20SRD (v3.6) definition:

Insert this "Flat-Footed Dexterity Penalty" section in the AC-mods portion of the definition file like this:

Code: Select all

            <table-row>
               <name>Spell Resistance:</name>
               <tag>spell-resistance</tag>
               <id>SPELL-RESISTANCE</id>
               <token-name>SR</token-name>
               <modifiers>
                  <modifier>SRtempMod</modifier>
               </modifiers>
            </table-row>
            <table-row>
               <name>Flat-Footed Dex Penalty:</name>
               <tag>flat-footed-dex-pen</tag>
               <id>FLAT-FOOTED-DEX-PEN</id>
               <default>$D:0</default>
               <token-name>FFDP</token-name>
            </table-row>
         </list-pair>
         <list-pair>
            <name>Saving Throws / Ability Checks</name>
            <id>SAVING_THROWS</id>
            <table-tag>saving-throws</table-tag>
            <first-column-size>50</first-column-size>
            <second-column-size>80</second-column-size>
            <table-row>


Then, just above this, change the "Flat-Footed AC" section to include the "$FFDP" value like this:

Code: Select all

            <table-row>
               <name>Flat-footed AC:</name>
               <tag>flat-footed-ac</tag>
               <id>FLAT-FOOTED-AC</id>
               <default>$A1$A2$A3$A5$A7$A6$FFDP</default>
               <modifiers>
                  <modifier>ACtempMod</modifier>
               </modifiers>
            </table-row>


Now everything should work fine--at least it has so far with my game. The Dexterity-AC mod remains unchanged and contributes to various target AC's like it should and used to. Now, however, the Flat-Footed AC subtracts negative Dexterity modifiers, but doesn't do anything with Dexterity bonuses!

A few important caveats:
1. Always backup your definition file before making any changes! Nuff said!
2. Make sure you include the "Flat-Footed Dexterity Penalty" field after after the "Spell Resistance" section. In both the 3.0 and 3.5 definitions, there are scripts that rely on static indexes in the Armor table. While changing these script indexes is not particularly difficult (in fact it's about as easy as changing a script ever gets), I said this solution wouldn't require script modification. So there you have it.
3. PCGen output sheets will not include this value unless you make modifications to it similar to those in step 2 above.
4. I am a hasty and rash individual who has only tested this in combat for a couple hours. If there are any problems or wierd behavior with this modification, please let me know.

I hope this helps someone.

Regards,
Gabe

[Tarkin]

I'll help out as much as I can. I've been spending some time trying to figure out why the PRE(touch) spells no longer work. I used to program a long time ago, but not with java. So there is a significant learning curve ahead for me. Not to mention the inability to "step" through the scripts makes debugging rather difficult.

Anyways, glad to see someone stepping up to keep 3.5 alive. My thanks.

Tarkin

[Gabriel Penn]

I've noticed that...

Let me know what you've figured out. I've caught up on your other posts on the topic, but let me know if you've learned anything new.

After playing around with it for a bit, I've learned that once a session is started, I can make the Client spells involving PRE expressions work against a hostile icon if I open the hostile's character sheet, replace the Touch AC field with some random integer, then change it back to its previous tokens. If I go through that, Clients can cast PRE expressions against that icon for the remainder of the playing session. Pretty lame, I know, but at least its something. I opened the spell_save script and I double checked the indexes (as if that were the problem). I tried to look around a little further, but my head almost exploded. I wish I were better at scripting. And yet... I wonder if the script is the problem. Everything seems to work fine on the host machine. Perhaps moon-wizard was trying to apply a script that worked fine with an older addition to a newer kLoOge that simply behaves differently. Maybe the program itself isn't sending the data to the client machine without being prompted somehow (like what I did above). Or maybe the attack from the client machine doesn't look in the right place without being prompted by a change in Master. Maybe that is script related. Anyway, that's what I've managed to learn. Maybe it'll trigger an epiphany in someone better at scripting than I am.

Thanks for your help.

Regards,
Gabe

[Tarkin]

My current working theory is that it has something to do with the fact that KWScript.adjustHP function states

Code: Select all

adjustHP

public static final void adjustHP(java.lang.Object o, int[] delta, int dmr)

Adjust the current hit points for the specified Icon.
Clients can only call this routine on Icons that they are allowed to make hit point adjustments to.

Thats why it seems to run fine on the master side, but not for a client. Though how this is also connected with tokens in the Touch AC column is beyond me.

I've tried using the addPendingDamage function, but it doesn't seem to do anything at all.

[Gabriel Penn]

Hey Tarkin!

Do you know what the last version of kLoOge was where the PRE expression actually worked? Everything worked back with 3.0.3. I took a year-and-a-half haitus from gaming, then when I came back, kLoOge was at version 3.3.2 (where everything except for 4th edition seems to have gone straight to hell! ) Anyway, I'm considering rolling back my kLoOge version, and I was curious when you started noticing this wierd bug.

I actually didn't think this was going to be a huge problem at first. But now one of my spellcasting players is afraid to do anything with his icon, because it will probably not work correctly. I end up having to cast many of his spells for him, and I can tell he's getting irritated. Anyway, thanks for your help.

Regards,
Gabriel

[Tarkin]

I looked back and it seems that the loss of functionality pretty much happened with the introduction of 3.1.

So if you have an old version of Klooge 3.0.3 and the old def file v3.2 you are golden, but you will lose a good deal of chrome when you roll back.

Please let me know if your role back works. I might consider it too, atleast till the apply pending damage function bug gets fixed.

Tarkin

[Gabriel Penn]

Hey Tarkin!

Well, I’ve decided what I’m going to do… for the time being at least. I think I’m going to try and stick with 3.3.2 for now. Besides the small bugs (like initiative lists disappearing and so on), there are two main “this-screws-my-game-all-to-hell” bugs that I have issues with: the PRE(X) addPendingDamage bug, and the completely broken post-scripts. I can ignore the small bugs… for now. As for the two big bugs, I’m trying to come up with workarounds.

As for the PRE(X) bug, I’ve thought of two things that might work:

1. I remember reading in a script somewhere two similar lines of code. The one that was currently used applied all spell damage immediately. The other was commented out, but would have set all spell damage to a pending state (like weapon damage). I’m going to see if I can apply this code to the KS1 handler and see if setting spell damage to “pending” might have more relaxed client permissions. (Let me know if you have already tried this. I think I might be in for a bit of work.)

2. If the above trick doesn’t work (and I really don’t have high hopes that it will), I’m going to attempt to modify my definition file. After going over the 3.0 definition, I think I can reason out how to add spell damage expression columns (KS1’s) to weapon rows. In addition to the obvious benefits of being able to handle items like a Hammer of Stunning without the use of consumables, I think it might prove to be a usable (if irritatingly cumbersome) solution to the PRE(X) dilemma. Basically, you would add a frequently used spell, like Inflict Moderate Wounds, as a weapon. This would handle the PRE(TOUCH) aspect of the spell, since you just roll a “weapon” attack versus an icon’s Touch AC. Assuming you hit, you would roll the spell expression associated with the “weapon” to check for a Will save and apply the appropriate damage and/or effects. The only reason that I would even consider this solution is because of the other magic weapon benefits. And since my party only has one spellcaster (a sorcerer), it would not be too difficult to add the necessary “spell weapons” so that he can make his own rolls and doesn’t feel like his character never gets to do anything. If I manage to modify my definition successfully, I’ll post the code change.

As for the attack post-script bug, I am really at a loss. Do you have this problem of kLoOge never checking for miss chances? The post-script always used to check for effects, abilities, and feats and roll for miss chances automatically. Anyway… I’m just going to have to type a bunch of custom expressions for one of my DMBuddies to roll so I can check for these. Hopefully, I can remember to roll them.

Anyway, that is the conclusion for now. I set up so much of my game and my definition to use the 3.3.2 features, that the idea of rolling back exhausts me at the thought of the work involved and depresses me at the thought of losing the new features. It’s still on the table, but I guess I’m just not quite irritated enough to go with the nuclear option… yet.

Regards,
Gabriel

[Tarkin]

I think you are refering to these lines of code in the D20SRD_spell_save script

Code: Select all

// Disabled apply pending damage, since it doesn't seem to be working   
//KWScript.addPendingDamage(target, caster, diceExpression, final_dmg);
KWScript.adjustHP(target, new int[] { -final_dmg }, 0);


I've tried playing around with the addPendingDamage call, but I can't seem to get it working. Maybe someone else could do better.

I'm pretty sure that the bug is coming from the fact that in the scripting docs it specifically states that the adjustHP call can only be done by clients if they are allowed to make HP adjustements to that icon. Though even if I give them that ability, if the icon is hostile it still does not work.

[Gabriel Penn]

Hey Tarkin,

Having bumbled my way through another playing session, I've noticed a few more things that don't work. One example is that Client spells that edit a hostile icon's effects are really buggy. A player of mine who is sorcerer cast color spray on some hostile icons, and only the the first of three effects were applied. The other two got lost in the ether somewhere. In fact, about 80% of the bugs with the 3.5D20SRD definition seem to be related to Clients not being able to attack/damage/edit/affect hostile icons in any reliable way.

Anyway, here are some workarounds for this:

"The DM Likes To Play With Himself", or the easiest way (and incidentally, the easiest way to completely disenfranchise your players )

Just cast all of the spells as the Master. That is, ask your spellcasting players to target their enemies and ask them what they want to cast, then cast the spell as the master.

Pros: It always works and it is the easiest way around this.
Cons: It sucks for them. I wouldn't take their dice away in a tabletop game, and I won't in a VT game. As a serious DM, I could never seriously consider this option.

"The Kansas City Shuffle", or the tedious way

Just before the client casts the spell, convert the targeted icons to "NPC (friendly)". The spell should then work as normal. Then convert the icons back to "NPC (hostile)".

Pros: This can be accomplished as easily as selecting all the targets, right clicking on one of them, navigating to the "Modify" list, and select "NPC (friendly)"... and of course changing them back again. The players get to have some sense of control over the interface.
Cons: It is a pain to have to do this so often and for so many spells. It can slow down combats significantly, especially with multiple combatants or at higher levels.

The "Frankenstein's Monstrous Weapon Table" way

This is for guys, like me, who enjoy and are not afraid to drastically modify their definition file (and possibly a few scripts ). Basically, I added "special/magical weapon effect" columns to my weapons table. This was done quite effectively in the 3.0 def that ships with version 3.2.2. So look there for ideas. If anyone wants to see how I did this for the 3.5D20SRD, just ask and I can post the code or email it to you.

It's essentially just a way to "cast a spell" from the weapons table. Mine uses two slightly modified scripts, very similar to the ones MoonWizard set up to handle spells and consumable magic items. To show how this can be useful as a workaround, I'll use inflict light wounds as an example. You would simply add this spell as a "weapon" named "Inflict Light Wounds" and set the "attack" column for whatever the character would use for the initial touch attack, then you put the relevant spell data in the new fields almost exactly like it is in the spells tab. Just DELETE the portion of the spell expression that says "PRE(TOUCH)". Now when the Client casts the spell, and it doesn't work, as usual; he can switch to his weapons, and roll a "weapon attack" vs touch AC. If that hits, he can use the spell expression button, and... voila! It works!

Pros: This gives a maximum amount of control to a player, and requires absolutely no DM intervention to make it work properly. It doesn't slow down combat much at all (It's just one more click.)
Cons: Well, you will have to modify your definition file and probably a couple of scripts as well. Though, I must admit I would have done this anyway, as a magical/poison/disease/whatever option for weapons is ridiculously useful. Also, you will need to add the spell "weapons" for your players to their weapons tables. Not so bad if you have one sorcerer... but a bit more keystroke heavy if you have three high-level priests! Lastly, you really have to trust your players not to abuse this since it is not really feasible to limit the usage of such "spell weapons".

The "DMBuddies" way

In another of my topics, I've outlined the concept for "DMBuddies". Once my life slows down a little, I'll try to clean them up and post them to kLoOge.info. But for now, you can create your own. This DMBuddy is different because it is not an item, but rather an NPC that is a "clone" of a PC. For example, I have a spellcaster named "Luther". Before a playing session, I would make a copy of his icon and set its type to NPC (friendly) (so that it doesn't show up in the PC well) and make it invisible. Then I would edit the spells, removing all the "|PRE(XXXXX)|" components. Finally, I would add two weapons to the original Luther PC: a melee touch weapon, and a ranged touch weapon. Now, when Luther casts a verboten spell, like Ray of Frost, he targets the enemy (and so does the invisible LutherClone), he makes a ranged touch attack, and if he hits, he casts the spell (and as he is casting his spell, so does LutherClone). Everything worked out fine.

Pros: This only requires a little prep-work the first time. After that I just add spells (and modify them) to the clone as required. Some players will not mind and be happy that everything "felt" normal.
Cons: It's just not very feasible at higher levels or with multiple PC spellcasters. I've only used this in one gaming session. After that, I started using the modded weapon table option above. Now, I use a combination of the modded weapon table and the "Kansas City Shuffle".

No doubt, Tarkin, you are already using one or more of these, but I thought I would post them for the good of the community and any newbies that might be making the grueling choice between kLoOge or one of the other VT's out there.
Note to Newbies: "Just hang in there! Stick with kLoOge, and we'll get it fixed for ya!"
Note to Kurris: "Parsing...is...too...tight! ... Can't...breathe! (gasp!) ... Need...update!"

Regards,
Gabriel

[Nighteagle]

So, is anyone still trying to "keep 3.5 alive?" I'm asking because my group has just started (on our 3rd game) using Klooge to play 3.5 using the Pathfinder upgrade (like 3.75, because it changes all the things I want changed). I've become familiar with the definition file, I've been able to change to dead-point to the negative Con score instead of -10, as Pathfinder has implemented this change. However, every time I try to understand the scripts, I'm completely lost. The only thing I've managed to learn so far is that // is used to make a comment.
I'm asking because it appears that the scripts for 3.5 (like d20SRD_attack_check.kws) are not actually working. the d20SRD_attack_check.kws script is supposed to check things like range modifiers for ranged weapons based on measuring distance from attacker to target (as far as I understand it). However, I've dried moving icons around at different ranges and I never get any penalty for range added. Same thing with the script that is supposed to check for Point Blank Shot. So, my question is, are these scripts just broken now because of the 3.2.2 upgrade that doesn't like Moon Wizard's 3.5 SRD definition? Has anyone else noticed that these scripts seem not to do much of anything?

I guess I'm just wondering how much mental energy I should put into learning java in order to script; or should I just give up because the scripts aren't working with the 3.5 definition file and the 3.2.2 version of Klooge.

This is all so very confusing...I've set all my NPC's to friendly so that my players can successfully attack them and I've ignored that fact that men, women, children, and dragons all scream like a man when they are damaged. However, it seems like most of the official (Klooge employee) resources and unofficial (game user) time and energy are going to support a 4th edition definition file, and I'm sorry, I own the books, I've tried to use it, but I really can't stand 4th edition. I like Pathfinder's upgrade to 3.5 a lot though and really hope to make it work with Klooge
Pam

[GMJames]

Nighteagle - I posted elsewhere in the forum that I started to examine the failures experienced by players with the scripts. I ran into a little trouble with the spell script failure because I am not able to reproduce the failure consistently. I can create HOSTILE NPC icons and attack them and have damaged registered. I can also create those that will not register. So I have more looking to do. But I do have a script writer who is willing to help me now.

I asked that for those failing scripts you are experiencing, if you would carefully write out, step-by-step, the actions you take to consistently experience a failure, I will attempt to repeat them so that I may have a better understanding.

Finally, please ensure that your scripts are in the Contents/lib/scripts/3.5-d20SRD folder if you are using a PC as the MASTER. If you are using an Apple Computer then they should be in the Application's Resource fork. You get there by right-clicking the kLoOge.Werks application and selecting Show Package Contents. Then go to Contents/Resources/scripts/3.5-d20SRD.

If the automation is harming your game, then use the 3.5E Def file that comes with kLoOge.Werks. It contains almost nothing that automates the game. So you can play a table top game just like at home. You'll need to adjudicate and apply the Pathfinder rules exactly as if you were sitting behind the GM screen.

[GMJames]

Nighteagle - Would it be possible to have you start up your game some time in the evening and let me join? I need to see the trouble you are having and maybe work it with you real time.

I cannot recreate the script failures you are having. I can do all spells I have tried and melee and ranged attacks. It would be helpful if I could work directly with something that is failing.

contact me via PM or e-mail and let me know when you will be up.