-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Foundry loose integration
- Thread starter Farling
- Start date
Version 1.12 is out
Remove occurrences of secret sections having double the darkness applied to its background.
Fix an issue where section headings were set/not set with 'secret' which did not match that state of its contents.
Put GM Directions & Contents above GM Directions in the text editor menu, and remove Block: from those entry names.
Further reduce the amount of HTML generated for each journal entry (faster world loading!)
Ensure new text block names are less likely to conflict with other modules (internal to the code).
Add a new configuration Use 'secret' in Unrevealed Topics, which when ticked will do the normal topic generation, but if unticked then topics which are NOT revealed in RW will NOT have any secret sections in their corresponding Journal Entries. This is so that the journal entry doesn't end up with large portions of it using the secret (darker) background.
Remove occurrences of secret sections having double the darkness applied to its background.
Fix an issue where section headings were set/not set with 'secret' which did not match that state of its contents.
Put GM Directions & Contents above GM Directions in the text editor menu, and remove Block: from those entry names.
Further reduce the amount of HTML generated for each journal entry (faster world loading!)
Ensure new text block names are less likely to conflict with other modules (internal to the code).
Add a new configuration Use 'secret' in Unrevealed Topics, which when ticked will do the normal topic generation, but if unticked then topics which are NOT revealed in RW will NOT have any secret sections in their corresponding Journal Entries. This is so that the journal entry doesn't end up with large portions of it using the secret (darker) background.
Sword_of_Spirit
Well-known member
It looks like the box around the GM Directions is being drawn without the actual text inside it. This seems unlikely unless something is awry with the HTML that is stored for the journal entry.
As GM, is it possible for you to open the editor and view the HTML of the page (using the "<>" button in the editor) and find the part of the entry which contains the GM and non-GM text inside the corresponding sections. It should look a little like:
It would help me understand where something is appearing out of order.
Last edited:
Sword_of_Spirit
Well-known member
<section class="RWgmDirAndContents">
<section class="RWgmDirections">
<section class="secret">
<p>'GM Directions Secret about:</p>
</section>
</section>
<p>Player readeable content</p>
</section>
Is that the part you need? There's a lot of information in that editor, and I'm not sure which other parts to copy.
<section class="RWgmDirections">
<section class="secret">
<p>'GM Directions Secret about:</p>
</section>
</section>
<p>Player readeable content</p>
</section>
Is that the part you need? There's a lot of information in that editor, and I'm not sure which other parts to copy.
Yes, that is the section. I can see the problem - the "secret" section is inside the "RWgmDirections", rather than them being the same section (like in my example).
Did this occur after using the new "GM Directions" styles within the editor, or have you edited the topic since it was imported, rather than this being directly generated by the RW import process?
Ok, I can see that I can reproduce something similar by manually creating these entries.
Did this occur after using the new "GM Directions" styles within the editor, or have you edited the topic since it was imported, rather than this being directly generated by the RW import process?
Ok, I can see that I can reproduce something similar by manually creating these entries.
Last edited:
Version 1.14 is available
This provides a new style called "GM Directions (secret)" which will set the style properly with the correct presentation and marking it as "secret" at the same time.
The Player and GM styles have also been separated out in the editor to help users understand which styles will/will not be visible to players.
This provides a new style called "GM Directions (secret)" which will set the style properly with the correct presentation and marking it as "secret" at the same time.
The Player and GM styles have also been separated out in the editor to help users understand which styles will/will not be visible to players.
Sword_of_Spirit
Well-known member
That works. Is there any way to make the secret GM directions look different than the player-viewable GM directions on the GM's end?
From a RW point-of-view, players shouldn't ever see GM directions - that is why I've added into the README that the "GM Directions (secret)" should always be used. The style without "(secret)" is only made available in case you remove manually remove the Foundry secret from the GM directions.
Unfortunately, there isn't a way within Foundry for me to enforce the secret flag always remaining on the GM Directions style.
I will see if there is a way to indicate to a GM that he hasn't got secret selected for the GM directions.
Last edited:
Version 1.14.1 is available
The secret style is always added to GM Directions during import.
If the secret style is manually removed from a GM Directions paragraph then an inline warning will be displayed to the GM indicating that the GM directions might be visible to players.
To restore the situation, the user can manually deselect the "GM Directions (not secret)" on the paragraph(s) and then reselect "GM Directions (secret)" for them.
The secret style is always added to GM Directions during import.
If the secret style is manually removed from a GM Directions paragraph then an inline warning will be displayed to the GM indicating that the GM directions might be visible to players.
To restore the situation, the user can manually deselect the "GM Directions (not secret)" on the paragraph(s) and then reselect "GM Directions (secret)" for them.
Sword_of_Spirit
Well-known member
That works. I was more thinking of a visually distinct look to them, but this will do the job to make sure I don't accidentally leave my secrets un-secreted. Thanks!
I haven't followed the last few updates closely, so forgive if this was already adressed, but two things came to my mind:
a) Journal Entries do have a text and an image section. So far, everything in a RW topic goes in the text section. Any images are embedded in the text. This is totally fine! But I wish, if a topic has one or more images, the first image would also go to the image part of the Foundry Journal Entry. Because there I can click "Show Players".
For example, most of my NPCs do not have a statblock. Shop- and Innkeepers, Story-NPCs and such don't really need one. But they usually have an image that I want to show the players.
b) A minor issue: Initially everything imported went into a compendium. Now it just goes straight into the world. With my realm consisting of 2000+ topics, that makes Foundry load very slow. Especially for some of my players with low end hardware and sub-standard internet access.
Any chance of having a "put stuff in compendia" checkbox?
Apart from that I just want to reiterate: I can't thank you enough for your work!
a) Journal Entries do have a text and an image section. So far, everything in a RW topic goes in the text section. Any images are embedded in the text. This is totally fine! But I wish, if a topic has one or more images, the first image would also go to the image part of the Foundry Journal Entry. Because there I can click "Show Players".
For example, most of my NPCs do not have a statblock. Shop- and Innkeepers, Story-NPCs and such don't really need one. But they usually have an image that I want to show the players.
b) A minor issue: Initially everything imported went into a compendium. Now it just goes straight into the world. With my realm consisting of 2000+ topics, that makes Foundry load very slow. Especially for some of my players with low end hardware and sub-standard internet access.
Any chance of having a "put stuff in compendia" checkbox?
Apart from that I just want to reiterate: I can't thank you enough for your work!
Displaying the image inline is easy enough - replacing it or marking it as being the image for the journal entry is more complicated.
Is it possible to have Foundry only make the picture visible to players and not the journal entries?
The reason I moved from compendium to world was because of the additional linking support that was added for smart images. I don't remember the specific issue about what wouldn't work in compendiums, it may have been an issue with Foundry 0.7.x which isn't relevant to Foundry 0.8.x
Last edited:
Sword_of_Spirit
Well-known member
I think current Foundry still doesn't preserve content links in compendiums. At least as far as map notes and such.
There is supposedly a separate module which allows you to move things from world to compendium and maintain links - but I've never used it, and I don't know if it has limitations such as you suggest.
Sword_of_Spirit
Well-known member
Yeah, Scene Packer is supposed to allow you to do that. I haven't looked at it yet, but the impression I got was that it's a bit of an involved process, not just a matter of enabling a module and clicking some settings.
I saw some comment that Foundry v9 is going to allow templates to be created on a per-system basic for journal entries (like they are already doing for Actors and Items). This could cause issues for my nice generic import, we will have to wait and see.
Compendiums do not allow permissions to be set, so all the revealed information from the RW file would be lost.
Compendiums do not allow permissions to be set, so all the revealed information from the RW file would be lost.
Last edited:
Sword_of_Spirit
Well-known member
While it would of course be superior if we could keep everything in compendiums and still have it functional, given that I doubt that will be an option any time soon, I'd much rather have the current ability to keep the reveal state, than be able to keep it in compendiums.
With my 3000+ journal entries, and dozens of scenes, the scenes and journal databases are still clocking in at less than 10 MB total (thanks for that revision that reduced size!) Persistent scenes are normally going to be world maps rather than battle maps (at least in my case, I'm not sure if others do it differently). If I need to keep a bunch of battlemaps after use, I can stuff them in compendiums, because they won't need the level of linking and integration with journal entries and other maps that the world maps do. But I'm also new to Foundry, so I'm not sure where performance issues set in, though I was told that the sort of text-based journal entries I have aren't really a problem.
So all that's to say that I definitely wouldn't want to lose any current functionality from the importer to add additional functionality.
Last edited:
I think it is an optimisation that Foundry really needs to make internally.
Their current architecture has all the world's contents downloaded to the browser when you first log onto the game - this obviously requires, in your case, downloading all 3000 journal entries to any GM. I'm not sure if players get only the revealed journal entries or also get all 3000 sent to them!
It's a shame that they can't work on a download-on-first-use basis.
Their current architecture has all the world's contents downloaded to the browser when you first log onto the game - this obviously requires, in your case, downloading all 3000 journal entries to any GM. I'm not sure if players get only the revealed journal entries or also get all 3000 sent to them!
It's a shame that they can't work on a download-on-first-use basis.