- edited description
Creating NPC/PC actors with starting letters "T", "U", "V", "W", "X", "Y", "Z" breaks the sheet.
Technical info
Obsidian Character Sheet version: 4.2.3
Foundry version: 0.7.7
Game System: DnD5e - Fifth Edition System | version 1.1.1
Description
Quite unique problem I'm having. As stated, for me at least it seems that whenever I create an actor whos name starts with the last last seven letter of the alphabet "tuvwxyz" (capital and non capital letters), it seems to break the character sheet so it wont open.
The errors seem to reference to different type of problems, which seemingly do not relate to the problem (not an expert, but that's my guess).
When trying to open NPC sheet with this problem, error is following:
foundry.js:4481 TypeError: An error occurred while rendering ObsidianNPC 46: Cannot read property 'skills' of undefined
at ObsidianNPC.getData (npc.js:105)
at ObsidianNPC._render (foundry.js:4509)
at ObsidianNPC._render (foundry.js:5163)
at ObsidianNPC._render (foundry.js:16728)
at ObsidianNPC.render (foundry.js:4479)
at ObsidianNPC.render (foundry.js:5629)
at ObsidianNPC.render (npc.js:140)
at ActorDirectory._onClickEntityName (foundry.js:16209)
at ActorDirectory._onClickEntityName (foundry.js:25403)
at HTMLOListElement.dispatch (jquery.min.js:2)
When trying to open PC sheet, error is following:
TypeError: An error occurred while rendering Obsidian 45: Cannot read property 'itemsByType' of undefined
at Obsidian.getData (obsidian.js:181)
at Obsidian._render (foundry.js:4509)
at Obsidian._render (foundry.js:5163)
at Obsidian._render (foundry.js:16728)
at Obsidian._render (obsidian.js:413)
at Obsidian.render (foundry.js:4479)
at Obsidian.render (foundry.js:5629)
at Obsidian.render (obsidian.js:197)
at ActorDirectory._onClickEntityName (foundry.js:16209)
at ActorDirectory._onClickEntityName (foundry.js:25403)
I will attach the two test actors with this problem in case it might help.
How I replicated the problem
- Create a PC/NPC actor
- Give it a name with one of the seven letters mentioned before as a starting letter.
- Close the sheet
- Reload the application
- Attempt to open the sheet.
How to get past it
If you duplicate the sheet and then open it, it allows it and you can change the name to not have the problematic naming as stated. If you then reload application and try to open the duplicated and renamed sheet, it will open up.
Hopefully its just me, but if it isn't my anomaly, then maybe this info can help you out in solving the problem.
Comments (12)
-
reporter -
repo owner Wow, this is a fun one.
Perhaps unsurprisingly I was not able to reproduce this. I had no issues creating characters with names that started with any of those letters and opening their sheets before and after reloads. Also, I was able to import those test characters and open their sheets without a problem.
As to where to go from here: If you have any other modules enabled, disable them and see if the problem persists. Also, try checking for any errors further up the console either when the actor is first created or when the world is initially loading after a reload.
-
reporter Tested with disabling modules one by one and all but Obsidian one. Problem persists.
There is 1 error that is shown in console and that is the following:
bonuses.js:7 Uncaught (in promise) TypeError: Cannot read property 'walk' of undefined at applyBonuses (bonuses.js:7) at ObsidianActor.prepareDerivedData (actor.js:265) at ObsidianActor.prepareData (foundry.js:30615) at ObsidianActor.CONFIG.Actor.entityClass.prepareData (skl-customization.js:25) at data.js:59 at Array.forEach (<anonymous>) at loadSpellData (data.js:59)
There does not seem to be any additional log info indicating where this problem might originate. The error is given right after foundry compiled template
Foundry VTT | Rendering HeadsUpDisplay Foundry VTT | Retrieved and compiled template templates/hud/hud.html Uncaught (in promise) TypeError: Cannot read property 'walk' of undefined ...
-
repo owner There’s a
skl-customization.js
in that log which is definitely not an obsidian file. It might not be relevant, but worth noting in case it means anything to you.Are you able to verify that you still have the issue if you disable all other modules but obsidian and then try to create a new actor? If the issue occurs when creating the actor then disabling modules after the fact won’t affect it since the data will still be bad.
-
reporter Are you able to verify that you still have the issue if you disable all other modules but obsidian and then try to create a new actor?
Yeah, sadly the problem still persists. Only Obsidian as active module and still after creation and reloading app, the sheet wont open.
It does not seem that the problem occurs on creation. At least no problems show up in console and I can open/close/edit the file. The problem occurs when I reload app/open close it and then attempt to open the sheet. Then the error is shown and it wont open.There’s a
skl-customization.js
in that log which is definitely not an obsidian file.When going over my modules it seems to be a module called “Skill Customization for D&D5e”. (naming reference is too similar).
I did attempt to try create, reload and open with both Obsidian and this skill module active and without it. Both times same result. Only difference is, when I disabled the skill module, the initial error that is shown on start up changes slightly.Uncaught (in promise) TypeError: Cannot read property 'walk' of undefined at applyBonuses (bonuses.js:7) at ObsidianActor.prepareDerivedData (actor.js:265) at ObsidianActor.prepareData (foundry.js:30615) at data.js:59 at Array.forEach (<anonymous>) at loadSpellData (data.js:59)
The errors for opening NPC/PC sheet stay same no matter if the skill module is active or not.
This is very bizarre problem
.
-
repo owner Alright, it seems we can safely rule out module incompatibilities, which would have been my first guess.
That particular error suggests that the actor is not being prepared properly, so I would expect an error further up the console when the app first loads to explain why. I appreciate you’ve already said that there’s only one error but I just want to make absolutely sure that you scrolled up the entire console and there’s only one error in it when the app first loads.
-
reporter - attached Foundry_console_log.txt
Related to comment about only single error check in console.
-
reporter Sorry for long response time.
Yes it looks like there is only one error that is shown when the program fully loads up. I added a console log file as will in case there might be some kind of a hint for this bizarre bug.
(Updated to Obsidian version 4.2.4 and only this module as active one when tested the bug.) -
repo owner Just another thing to try, since I’m still unable to reproduce this, do you still have this problem if you create a fresh world and try to create some new actors there?
-
reporter Well, I think I managed to locate the problem. I decided to finally put my developer hat on and delve into the code itself for more deeper investigation.
It seems that I have an "type":"vehicle" actor that was causing this problem. Once I removed the actor from actor.db, the problem went away.I have managed with some testing now get the problem narrower to a point.
This makes little sense. At least for now and what little I know of Foundry and how its inner gears are turning.So the narrowed case is for me as follows:
If I make a Vehicle type of actor, then at least for me depending on the name of the vehicle actor, all the tokens that start with later letters in alphabet than the starting letter of the named vehicle actor, do not open anymore.
Its bizarre. Just shooting from the hip, could it be related to Unicode usage somehow? That is my totally wild guess, which probably is not the caseI asked a friend of mine to also make a vehicle token and he got the same problem on his foundry, so it does not seem to be unique to my foundry only.
Maybe this might be more accurate way to replicate the problem so that you might have a chance to give a more knowledgeable look into it (your module and all
).
-
repo owner - changed status to resolved
Thanks to those instructions I was finally able to reproduce it, and the issue turned out to be not that crazy in retrospect.
I’m sure you’re curious, so the explanation is that vehicle actors were throwing an error in the preparation phase, which meant that any actors after them did not get prepared correctly either, and therefore wouldn’t open. Since actors are prepared in alphabetical order, all actors who were prepared before the faulty one were fine.
I have pushed a fix for this in version 4.2.5. Thanks very much for your help.
-
reporter Glad to be of assistance.
Yes indeed, I was curious of the cause, so thank you for taking time for an explanation.Happy coding!
- Log in to comment