Test Release v3.2.0

[Trenloe]

Oh, and I don't know if this is the right thread for it, but is there any way to sneak in an option to get HP damage counters to count DOWN instead of up in 5e? This still causes confusion with my players, even the veterans occasionally.

This would actually be a big change as a lot of underlying code is effected. Damage would have to count down, healing would have to count up, colour coding for damage would have to be changed, etc., etc..

Keep smacking your players around the head until they get it. ;-)

EDIT: But, you may also want to add this to the FG wishlist so the devs can at least consider the option for future inclusion. https://fg2app.idea.informer.com/

[chillman0122]

This would actually be a big change as a lot of underlying code is effected. Damage would have to count down, healing would have to count up, colour coding for damage would have to be changed, etc., etc..

Keep smacking your players around the head until they get it. ;-)

EDIT: But, you may also want to add this to the FG wishlist so the devs can at least consider the option for future inclusion. https://fg2app.idea.informer.com/

Thanks for the link. I was thinking making the option toggle between current usage and displaying some sort of "holder" value that's (HPmax - damage). You wouldn't have to change the program itself, just make the output to the boxes where current HP is displayed (character sheet, party sheet, combat tracker). The change would be superficial only and not effect how the rest of the program works, i.e. color coding, healing, etc.

Of course, I have no idea how this program is written, so I don't know how hard it would be to add a variable like that, keep track of it for each player/npc (in the combat tracker), and swap out the displayed values in all the places where damage is shown. I've done a little programming, so I know that even a superficial change can mean months of work

[Trenloe]

Thanks for the link. I was thinking making the option toggle between current usage and displaying some sort of "holder" value that's (HPmax - damage). You wouldn't have to change the program itself, just make the output to the boxes where current HP is displayed (character sheet, party sheet, combat tracker). The change would be superficial only and not effect how the rest of the program works, i.e. color coding, healing, etc.

I had thought myself that maybe there was a way to make the change would be superficial, but then the expectation from most FG users is that wounds/healing would be dragged to this new "holder", which would then require the code changes I mentioned above. So, a lot of FG users would lose functionality they're used to, and/or get confused when they couldn't do what they've done before.

And, yes, a lot of FG users do drag/drop damage/healing onto the wounds field. Discussed very recently here: https://www.fantasygrounds.com/forum...l=1#post290882

With Fantasy Grounds being around for 10 years it can sometimes be an issue when making seemingly minor, superficial changes from a user experience perspective, a coding perspective and a community development perspective (breaking people's extensions).

Anyway, as mentioned, add it to the wishlist and let the devs make the decision on how difficult this would be to implement, what the impact would be to existing use and code, and whether they wish to consider it for a future release.

[chillman0122]

I had thought myself that maybe there was a way to make the change would be superficial, but then the expectation from most FG users is that wounds/healing would be dragged to this new "holder", which would then require the code changes I mentioned above. So, a lot of FG users would lose functionality they're used to, and/or get confused when they couldn't do what they've done before.

Anyway, as mentioned, add it to the wishlist and let the devs make the decision on how difficult this would be to implement, what the impact would be to existing use and code, and whether they wish to consider it for a future release.

That's why I was thinking you could put a toggle in the Options to switch displayed value... either way, I put it on the wishlist, we'll see if it gets any traction.

[Trenloe]

That's why I was thinking you could put a toggle in the Options to switch displayed value...

I understand what you're saying about adding the option - but doing this would require drag/drop functionality to be maintained for both options and that is where all of the coding has to be updated for the new option. You can't just change the interface without impacting underlying code and functionality. Anyway, thanks for adding to the wishlist.

[Zacchaeus]

I was using the Forge in 5e, though, and I couldn't get magic items to drop into the magic item side... they'd pop into the equipment side (which of course meant the Forge wouldn't do anything with them).

You put magic item templates into the right hand side. If you drop a magic item it will go, correctly, into the left side since the Forge is expecting you to add something to that magic item via a template.

[chillman0122]

You put magic item templates into the right hand side. If you drop a magic item it will go, correctly, into the left side since the Forge is expecting you to add something to that magic item via a template.

Yeah, I don't know what I was thinking. Thanks!

[dulux-oz]

OK, something "broke" on the FG Client-side in the latest update re:

DB.addHandler("mynode.*","onAdd",fpDealWithNewNode);

Under FGv3.1.7 a FG Client will run fpDealWithNewNode() without problem. Under FGv2.0 only the FG Host runs the function. Also, onChildAdded is also "failing" in the same way.

Is this a "feature" or a bug - because either way its gone and broken a sh!tload of code. If its a "feature" what is now the process to get an FG Client to run a function on a (public) node being added? If it is a bug, then at least we now know about it

Looking forward to getting this one resolved ASAP (talk about a massive speedhump )

Cheers

[Moon Wizard]

Okay, lots of good feedback. Here is feedback, updates and questions through Sep. 21 posts. I'll post again later with Sep. 22 onward.

SW Sidebar Underlay Issue
Identified, and addressed in next push.

Pregens
Originally, this was brought up by Mortar, in regards to SW archetypes, but it is relevant to all systems which support pregens.

This is expected behavior right now for any record type, so it would need to be customized to do anything different for pregens/archetypes. (i.e. all records in player loaded modules are always visible to them, any records in GM loaded modules which are shared are also visible to them, otherwise GM loaded module data is not visible to players)

Or, possibly, the archetypes should be moved to the GM modules only, or presented differently, or ... It's unclear to me what the desired behavior should be.
* Should players be able to peruse archetypes and pregens, and select one that way?
* Should the GM control which archetypes are added to the Characters window, and the player shouldn't even see the Archetypes?
* and so on...

Script error when adding files to Images folder
I was able to recreate, and looking into this right now.

SW Race Links
WansumBeats (or anybody else who can recreate), can you send me a character with an incorrect race link?

Perhaps your links are different somehow, such as different display class or different fields? I used the common format in the SW Deluxe and other DLC modules.

Thanks,
JPG

[Talyn]

Well, <pregens> is a CoreRPG thing so don't ALL the rulesets support it?

<archetypes> are specific to Savage Worlds but they are sorta-kinda-really-but-not-really the same thing. LOL They're more frameworks to drop onto the Character window so a player can very quickly make his own character using that framework that is close enough to a "class" concept he had in mind. Whereas a pregen is just that - a fully developed character ready to play with no tweaking.

So yes, an Archetype will be listed in the Player's Guide (under any setting which has them) under the Character Creation chapter so players should definitely be able to see them. Pregens should remain as-is where the GM imports them to his campaign. If I'm allowed to make a "wish list" it's that the pregen window also showed the basic stats that the normal character window would show. (level, class for a level and class game, which Savage Worlds is not, so I'm hoping in the future "we" can get it to show rank at a minimum on the character window).

SW does support an old method of clicking pregens into the game, which I'm told was the inspiration for the new <pregens> code which is far superior. Either way, the CoreRPG <pregens> method has been repeatedly tested by myself and Mortar, possibly a few others and it works perfectly.