Noted. Thanks.
Printable View
Noted. Thanks.
This is fixed nowQuote:
Originally Posted by Speculi
Issue with innate spellcasting automation in the combat tracker.
For example. The Lich (5.5E/2024 Monster Manual).
It says it uses the Level 5 version of fireball in the statblock. And that is recorded in the NPC record. But when you add it to the combat tracker, the dice are for the Level 3 version of the spell. I get this might be a tricky thing to make correct (and I think you can just edit the number of dice in place manually after adding it) but there's no indication in the combat tracker at all that the version of the spell the statblock uses is upcast.
Would be nice if:
A) It could automatically do the upcast for you.
B) failing being able to do that (since I get that it might be too difficult for the parser to figure it out all the time for every spell that can be upcast in every 5E flavor), show in the combat tracker that you need to upcast it. Stuff like Hold Person, which increases the number of targets when upcast, would still need some sort of indicator.
I'm doing a conversion of a module that has a statblock or two that includes upcast versions of spells, and I'm looking at the lich as an example on how to do it, so I'll follow its language templates for that, so hopefully when this gets resolved, my conversion will work the same.
There is no mechanism for automatically upcasting spells. What you can do is add the spells to the NPC sheet (right click -> parse spell actions) and then edit the dice in the spell description to show the upcasted amount.
Will you be doing the same then in the official books (like the monster manual for 2024)?Quote:
Originally Posted by Zacchaeus
Probably not. The way that the spells are set up in the books such as the MM is so that the spells can be pulled from whatever source the user has rather than pinning it to a particular source. I reread your post and realised that you were talking about a conversion you were doing. My advice was for you, as a DM, when preparing for a session involving such an NPC. If you are doing a conversion then leave things as they are printed in the book you are converting. The DM can always drag, right click to add dice, and drop damage strings to get the correct dice roll, or as noted edit the NPC directly.Quote:
Originally Posted by drempel
I will say as a DM (I run a lot of games using FG), unless I go study the statblock, without any indication that the spell that got inserted is wrong, I won't know I need to modify anything, and just assume it's right.Quote:
Originally Posted by Zacchaeus
All I'm really asking for at a bare minimum is a way in the combat tracker to show that the spell is meant to be upcast instead of that information being stripped when the monster is added.
DM's kinda rely on what's in the combat tracker a lot, and if it's wrong, the monster is probably going to be nerfed.
Fair enough, but this isn’t a bug report more a feature request.
Sure, I'll concede it could be considered a feature. The statblock in the combat tracker doesn't match the NPC record (even with official WotC content), but it could be looked at either way.Quote:
Originally Posted by Zacchaeus
MotM, Quickling Skill: Perception
Perception +5 s/b just Perception +5
Noted, thanks.
2024 DMG, Treasure Tables, Extra Items created in parcels when the old 2014 DMG is open
Technically, this is not a bug - but rather an unexpected interaction between the 2014 DMG, the 2024 DMG magic item tables and forged items in the 2024 DMG that causes some items to be doubled up in parcels generated by the 2024 DMG tables.
Individual magic items created by the Forge have the weapon name, then the template name surrounded by square brackets, a coma, and any magic bonus. If you search magic items using "[" in the new 2024 DMG you will find 5 pages of magic items build this way. The way forged items are named is what is creating the interaction.
An example is the first item on the search list: Sickle [Defender], +3. If you go to the "Random Defender Weapon" table in the 2024 DMG and roll on it with the 2014 DMG open you will get two defender items in a parcel. The first item with show the DMG 2024 item name created with the forge with [Defender] in it's name. The second item will show an item without the square brackets.
This is the unexpected interaction, the parcel has two defender items: one from the new DMG and one from the old DMG. What is happening is [Defender] in first item name calls the Defender table in the old DMG since [string] in a table calls the table of the string's name. Since the forge names items consistently and the tables in the old DMG are also named consistently, this is going to happen whenever a forged weapon is generated in a treasure parcel and the old DMG is open.
My suggestion would be that you mass change all the new DMG item names with "[" and "]" removing the brackets and then do the same for the treasure tables.
I'll need to think about that one.
You could just take the brackets out of the treasure table entries or change them to parenthesis, still linking to the items with brackets in the names - that would solve it as well. The fact the old DMG didn't use brackets in item names is why I suggested it.
Yeah, sounds like a global search replace would solve the issue but it'll depend on how many other square brackets there are in other places.Quote:
Originally Posted by Griogre
Depending on your editor, you should be able to limit the mass replace to just part of your XML file like in the items.
Minor typo noted: 'A bga containing 100 gp.'
Noted.
Vecna Adventure - Tomb of Wayward Souls Map
- Room T3 - H wall is supposed to be an illusory wall but not wall provided in walls layer
Area in front of entrance has no lighting.
I'll take a look when I have a moment.
Journeys Through the Radiant Citadel ch. 4
Paloma's stat block should IMO include the Gnome Cunning trait, as she is a gnome. Also, IMO, her Notes section should include the fact that she has sereno with 3 levels of exhaustion when she is first encountered. Or perhaps this should go in another trait.
The Revolutionary stat block does include the Dwarven Resilience trait, but should have poison resistance in the Dmg Resist section.
Also, Itzmin's stat block includes the Hellish Resistance trait, but it should have fire resistance in the Dmg Resist section.
Thanks, I'll let the developer know.
Also, Itzmin's stat block includes the Hellish Resistance trait, but it should have fire resistance in the Dmg Resist section.Quote:
Originally Posted by mdrichey
I added that to your post above.Quote:
Originally Posted by mdrichey
Hi mdrichey. Thank you for reporting the issues. I have fixed the issues and have checked in the fix. The fixed version will be in the LIVE system after Tuesday's update.
After the last update in the battle tracker, the "token size" and "range" fields have become inactive. Is it possible to make them active again in order to change the size and reach manually?
You can no longer change these manually; they are fully controlled by the size specified on the PC/NPC sheet and by any SIZE effects.
For example, creatures specified as Medium size on their sheets are Size 5 and Reach 5, Large is Size 10 and Reach 10, and so on. Also, an additional custom size has been added for Colossal (Size 30 and Reach 30).
For effects, If you add an effect of "SIZE: 1" to a Medium creature, it will automatically adjust the Space/Reach to 10/10, and adjust any linked token on a map to match. This works for negative values as well.
If you need to adjust; there are effects for ADDSPACE and ADDREACH.
If you need to specify an arbitrary size; you can use effects for SPACE and REACH to override default size category processing.
Regards,
JPG
Turn of Fortune's Wheel (Planescape adventure)
In Chapter 5 (Automata), on the Inverse Hideout map (5.1):
* When the door to the hideout is opened, it still blocks movement and LOS.
* The description of the room specifies that Kythkyr is on the ground floor near the spiral staircase- the encounter places it up on the balcony.
* Nothing in the room description suggests that the exposed machinery should be blocking LOS, but it does.
Thanks, I've fixed points one and two. I've left the terrain occluders on the machinery since whilst it doesn't say that this blocks line of sight it doesn't say that it doesn't block it either. So for DM's that feel it shouldn't they can remove those occluders rather than having to put them in. Personally I feel that since a big deal is made of the machinery they should block LoS.Quote:
Originally Posted by Madman Across the Water
The reason I feel they shouldn't block LOS is this: the map has two levels, the main floor and a balcony, 15' above the northern part of the room. The implementation of the map does a clever thing where the room's northern wall doesn't block LOS, so the balcony is visible to the players. Unfortunately, the placement of the central piece of exposed machinery means that from the doorway, where players are likely to be when initiative is rolled, you can't see primary enemy up on the balcony. The machinery blocking the view of the level its on is reasonable, but since there's no way to let it block its floor but not the balcony 15' above, it's my contention that it shouldn't block LOS.
That said, if you still disagree I will yield to your greater experience- I've made my pitch. :)
Madman makes a good point, but as Zacchaeus noted, it's easier to remove walls you don't want, than to add them if you do.
Really, this means we just need a new LOS type "half walls" or "obstacles" :)
I see what you are saying, and it's a problem where the map has height or levels and we don't have occluder types that can deal with it all that well. Whilst the characters might not see the enemies on the balcony it's also the case that those on the balcony can't see the PCs either; so there's advantage and disadvantage on both sides. I still think leaving the occluders is the way to go and leave the DM to switch them off if they feel that is the better option.Quote:
Originally Posted by Madman Across the Water
The Archmage NPC in SRD 5.1.0 has the Armor Class with and without mage armor reversed (should be AC 12, 15 with mage armor).
I did that deliberately since it seems inconceivable that the archmage would go into battle without Mage Armour already cast (I think in fact it says somewhere that's exactly what they do). Since that would mean the DM changing the AC (assuming they noticed) it seemed like a better idea to make the AC 15 including their Mage Armour.Quote:
Originally Posted by digimatt
Perhaps change the wording to (includes Mage Armor) or something, as right now it implies the AC drops to 12 when it's cast.
Right I see what you're saying. I just didn't change the wording to without.Quote:
Originally Posted by digimatt