Custom Save locations and other Qs

[Seeker1728]

Yesterday I had an instance where a deep article got obliterated by RW freezing up on me and because I didn't make saving as I go a habit (that's on me), lesson learned, back up/saving a local copy should be a routine necessity.

I have a SSD that holds my OS and a collection of other programs that I need stored there, but typically I install games, data collections, and other assorted software on a high capacity performance HD. I had installed RW on my main HD for this sort of thing, so when I found that all my RW files were being backed to C:\Users\name\Documents\Realm Works\Backups instead of the RW folder installed on my HD, I started looking in the various manuals to find instructions on creating custom save locations. Sadly I was unable to find what I was looking for.

I'm hoping I'm not being dense here, but I'm just not finding anything in the manuals on this. Admittedly, after going through two of them line by line, I was less patient in scanning the others so my apologies if its in the manuals and I just missed it. If it is in a manual a quick referral to which one would be appreciated. :) (or if you're feeling generous, instructions here in this thread ;))

On a related note: is there a ability to instruct RW to autosave regularly for me? I understand that the way its set up is to not store anything unless you tell it to, but I was hoping that there would also be a toggle that would let you dictate regular auto-saves. Part of the reason I had that article go off into digital heaven on me is because most of my work so far has been in MS-Office which does have that ability and think it would be a positive asset if it doesn't exist yet.

[Farling]

You can't manually choose where the realmworks database is stored (it always goes under %AppData%).

However I have a similar set up to you, except that my user folders are all on the D: drive, so realmworks automatically puts its database on the D: drive too.

Ctrl-S will save a page for you. Realmworks saves when you hit the save button on the topic, or finish editting; so it is only when half way through creating a topic that you might want to hit the button.

In general (at least in the past), massive long topics aren't an efficient way to use realmworks. Wouldn't breaking up a topic into smaller topics make the information more searchable?

[Exmortis]

I want to second Farling's good advice. I often break up large topics, if it is more than 1.5 screens to 2 screens long (scrolling) I will break it into two or more topics.

I think its cleaner, and little easier for you in the long run.

However, keeping your database on an SSD has its advantages for loading and saving.

I no longer use convention drives in anything but my NAS, even when working with videos.

Anything I store I send to my NAS, or my Onedrive.

[AEIOU]

If you use tables, it helps immensely if you break the table up into smaller chunks. I have lists of NPCs for each city/town with general information about people. These tend to be long as I don't create full profiles for everyone but I want to be able to remember names that I've mentioned and to have names, occupation and maybe their prime stats at my fingertips. For cities, I break them into tables for each district because one large table makes RW sluggish.

[rob]

@Seeker1728: There is no current way to specify the directories you want RW to use. However, you CAN move just about any directory on your computer to another drive by creating a symbolic link instead of a normal directory.

There is also no auto-save. That's a feature that some users would love and others (more?) would hate. If changes are auto-saved, then there has to be an undo of everything. Providing an undo of everything within RW would be incredibly complex, so that's not something practical until we get other more critical features into place. And without undo, auto-save will likely cause more problems for users than it solves.

Saving it tied to the <ctrl+S> keyboard shortcut. So you might consider starting the practice of pressing <ctrl+S> occasionally while you're entering large chunks of material. :)

[Avi]

@Rob - does the db you use support transactions?
Theoretically you can
BEGIN TRAN
work....
COMMIT on save
or
ROLLBACK on UNDO

[Silveras]

@Rob - does the db you use support transactions?
Theoretically you can
BEGIN TRAN
work....
COMMIT on save
or
ROLLBACK on UNDO

I'm not sure that's relevant. As it is now, multiple changes can be made while editing, and abandoned without saving ("Abandon accrued changes"). That's pretty much what a per-tab transaction would do, anyway. The changes are not saved to the db until you click "Save' now.

The "Undo" being discussed here would be more like abandon/undo 1 of X actions performed while editing, I think. An Undo History would track all of the actions... each edit to each snippet, and allow undoing each in reverse sequence. That sort of thing is more generally applicable to a file-based document than to a database.. especially "undo" after saving the change, if the user changes his/her mind.

[Seeker1728]

Thank you all for your replies;

@Farling thanks for the reply about RW's backup location will always be on my C drive (and a quick nod to Exmortis, yes a NAS would be a grand solution, but I'm still a comparative dinosaur in many ways). Also I'm assuming when you said you create a duplicate copy of your user saves on your D drive its by using a "hardlink"? (similar to what's posted here by Acenoid (http://forums.wolflair.com/showthread.php?t=51227) giving a detailed answer how to set one up.) I'm tempted to do the same, but then I ran into other posts here and there that left me with the impression I risk database corruption by doing so. Am I being too paranoid? (probably but a quick reassurance hardlinks are ok would be welcome :o).

@Seeker1728: There is no current way to specify the directories you want RW to use. However, you CAN move just about any directory on your computer to another drive by creating a symbolic link instead of a normal directory.

There is also no auto-save. That's a feature that some users would love and others (more?) would hate. If changes are auto-saved, then there has to be an undo of everything. Providing an undo of everything within RW would be incredibly complex, so that's not something practical until we get other more critical features into place. And without undo, auto-save will likely cause more problems for users than it solves.

Saving it tied to the <ctrl+S> keyboard shortcut. So you might consider starting the practice of pressing <ctrl+S> occasionally while you're entering large chunks of material.)

Thanks for the answer to this Rob, would've noticed it sooner except I was busy scouring manuals/FAQs this afternoon. The explanation about undo and autosave making a mess if used together clears up that so I'll not post that in the user suggestion as originally planned. And yeah, I've gotten in a regular habit of using the ctrl+s since that event, I disheartened by the loss that day, but I got over it. Just had to adopt a new practice and FWIW, I'm seriously in love with RW.

Now I got a few Qs because RW is arguing with me about sharing my data with my buddies. Bear with me, this is going to take a bit to explain.

Generally, my group and I regularly hand over $$$ to LWD, in fact when I mentioned I had bought a GM version of RW, the other two immediately went and bought GM keys as well due to our love/faith in LWD. I’ve read Rob’s post here (http://forums.wolflair.com/showthread.php?t=52844) and believe I got the general gist of what he’s saying how LWD’s cloud is a different beast from using Dropbox, nor do I have any "paranoia" towards LWD's service or think it unfairly priced for what it does.

It's just to be blunt/uncouth about it, I got enough things dipping into my wallet already without tacking yet another subscription fee into the mix. The same thing goes for my buddies (they got it even tougher, they got harpies…errr…spouses to explain themselves to :rolleyes:).

Ok, to impinge on your patience a little less here are my Qs


From reading Rob’s post and the FAQ, its my understanding that in order for my buddies and I to see any of each other’s realm contents, we have to register for the cloud and since we all have GM keys, once we have a cloud account we should be able to view each other’s realms even without a cloud sub. Am I correct in this understanding?



RW is arguing with me saying that my buddies don’t exist (wonder if they know they’re just a figment of my imagination? :D) I’m assuming this is because unlike me, they haven’t registered a account with the cloud yet and that’s why RW won’t let me extend a invitation. Am I correct in this assumption?


Also from Rob’s post:

7. There will be two levels of web-access for players. There will be a free level that all players can access and the Player Edition. The free version will provide access to topics, maps, plots, and everything else. The difference is that the free version will only provide access to a subset of revealed information, while the Player Edition will provide access to the entire realm – just like it does on the desktop. The GM will be able to control what subset of information is made available to players through the free version, and it can morph as the game progresses. The focus is on something that casual players will find useful, and we expect this solution to work well for more than 50% of all players (based on our own experiences and the anecdotal data from numerous users).



This is where I'm most confused about. He says two levels, a free level and a "Player Edition". I bought a GM key. Is a Player's/GM key what Rob's calling a "Player Edition"?



I'm unclear as to what he means by "the free version provides access to topics/maps/plots/everything else" then goes on to say it will only provide access to a subset of revealed information. This is confusing to me, "everything else" vs "only a subset" seems contradictory :confused: either everything is ...well...everything...or its not. So what is meant by "A subset of revealed information"? (a example of this in action maybe?)

TIA to anyone who waded through all that.

[Silveras]

Ok, so, here we go...

A Realm can have only one "owner" (basically the GM). All others must be Players (read-only access). At least at the present. The GM "syncs" the Realm "up" to the cloud, and the Players sync "down" the updated version to their copies. They can now view all of the revealed content independently of the GM and each other.. but have no access to un-revealed content, cannot edit content, and cannot add content. And, at present, there is no other way for them to access your Realm.

Purchasing a GM version does not give you GM access to someone else's Realm. It gives you the ability to create and edit Realms of your own.

Your access to a Realm, regardless of which edition you are using, depends on how your account is set up in the Realm (and, before it gets there, if you are not the creator, it does need to be activated through the server). If you are the Owner/Creator, you have full control and editing privileges... though you need the GM edition of the software to do so. If you are invited into the Realm as a Player, you have read-only access to what has been revealed (in this case, your GM edition software acts like Player edition software).

As to what is to come in the web access.. the quoted post is a little old now, and the truth is that details have not been announced. The emphasis right now is on releasing the Content Market functionality.

The Content Market will allow you to share your content with your friends. However, that is not a communal editing situation. You can give them a COPY of your Realm, which then becomes theirs to edit as they wish. It is independent of your copy, and they could each change their copies in different ways, so if you give your Realm to 2 friends, after a while you would have 3 very different versions of that Realm.

Whether they can receive updates from your original version to their copies was mentioned briefly in early talks about how this could work, but nothing more concrete has been said about this in some time.

The more recent discussion of the "new approach" to the Content Market has talked about exporting your Realm and importing into someone else's copy of RealmWorks. While this may help you share more, it would be up to you and them to manage "versions" somehow. And it is not clear yet exactly how that would work, or what options you would have, exactly. Passing a Realm back and forth may update the matching copy if you re-import a Realm you exported, or it may create yet another separate Realm with the same name and much of the same content. We don't know those kinds of details yet, but hope to get them "soon".

I hope that dispels some of the confusion.

[Seeker1728]

Ok, so, here we go...

A Realm can have only one "owner" (basically the GM). All others must be Players (read-only access). At least at the present. The GM "syncs" the Realm "up" to the cloud, and the Players sync "down" the updated version to their copies. They can now view all of the revealed content independently of the GM and each other.. but have no access to un-revealed content, cannot edit content, and cannot add content. And, at present, there is no other way for them to access your Realm.

I see, thanks in particular for mentioning the part I bolded/italiced, as that was something I had meant to ask but forgot.

Purchasing a GM version does not give you GM access to someone else's Realm. It gives you the ability to create and edit Realms of your own.

If you are invited into the Realm as a Player, you have read-only access to what has been revealed (in this case, your GM edition software acts like Player edition software).

I see, so looking at the "Manage"/"Members" tab, one of my friends finally activated his invitation, so I see him in the Realm Members listing. There is a little arrow under the "Status" column and when I explored it, a mini menu next to the arrow opens upon clicking on it with the option with a "Active"/"Owner"/"Custom" choice.

So I'm assuming that if I highlight one of the members, open up that menu, and select "Owner" that means we're now co-owners of the Realm?

(btw-if anyone cares to mention what the custom choice is supposed to be there for with its progammer lingo of is less than/null/etc feel free to fire a answer my way).

The Content Market will allow you to share your content with your friends. However, that is not a communal editing situation. You can give them a COPY of your Realm, which then becomes theirs to edit as they wish. It is independent of your copy, and they could each change their copies in different ways, so if you give your Realm to 2 friends, after a while you would have 3 very different versions of that Realm.

Whether they can receive updates from your original version to their copies was mentioned briefly in early talks about how this could work, but nothing more concrete has been said about this in some time.

That makes for some interesting possibilities, but I imagine naming conventions and guarding against mistakes is going to be quite the tangled yarn ball to sort. Still, very much looking forward to that and thanks for going into that for me :)

I hope that dispels some of the confusion.

Thank you Silveras, your effort was greatly appreciated and did help.

[Silveras]

I see, so looking at the "Manage"/"Members" tab, one of my friends finally activated his invitation, so I see him in the Realm Members listing. There is a little arrow under the "Status" column and when I explored it, a mini menu next to the arrow opens upon clicking on it with the option with a "Active"/"Owner"/"Custom" choice.

So I'm assuming that if I highlight one of the members, open up that menu, and select "Owner" that means we're now co-owners of the Realm?


No, a Realm has exactly ONE owner. There are no "co-owners" (see the Feature Requests forum for discussions about this being requested).

I had to look myself to see what you were talking about. That menu filters the list, to show only "Active" (Player) accounts, the "Owner" account, "All" accounts, or a "Custom" filter (which has no functionality not covered by one of the other three choices, I think, and may be for use if you dis-invited a no-longer-welcome member, or something like that).

But, long story short, RealmWorks is not currently a collaborative authoring tool. It allows only a single "master" of a Realm.

[Farling]

Thank you all for your replies;

@Farling thanks for the reply about RW's backup location will always be on my C drive (and a quick nod to Exmortis, yes a NAS would be a grand solution, but I'm still a comparative dinosaur in many ways). Also I'm assuming when you said you create a duplicate copy of your user saves on your D drive its by using a "hardlink"? (similar to what's posted here by Acenoid (http://forums.wolflair.com/showthread.php?t=51227) giving a detailed answer how to set one up.) I'm tempted to do the same, but then I ran into other posts here and there that left me with the impression I risk database corruption by doing so. Am I being too paranoid? (probably but a quick reassurance hardlinks are ok would be welcome :o).

I don't use hard links. I tell Windows that all users accounts are on the D drive, so windows goes directly to D:\Users instead of C:\Users to access any account information.

I found how to do this on the web several years ago. When I bought my latest custom-built PC I got the builder to set it up this way.

[Seeker1728]

But, long story short, RealmWorks is not currently a collaborative authoring tool. It allows only a single "master" of a Realm.

Thanks Silveras, much appreciated.

I don't use hard links. I tell Windows that all users accounts are on the D drive, so windows goes directly to D:\Users instead of C:\Users to access any account information.

I found how to do this on the web several years ago. When I bought my latest custom-built PC I got the builder to set it up this way.

thanks Farling, I'm going to go look into that as that's the first I've heard of being able to do something like that. Much appreciated!!!

[rob]

First, a big THANK YOU to @Silveras for diving in here and helping out. :)

As has been pointed out, each realm has only one owner. Players can currently only view what the GM has revealed, and it's a read-only situation for them. More importantly, you only need a PLAYER license to do this, so your players don't really need the full product. If they just purchased in the last 60 days, we can refund those purchases, then they can get the Player Edition instead.

That being said, though, the export/import logic coming in December will change things up a bit, so your players may actually want to KEEP the full product that they've already purchased. Here's why. Once you can export content, you can give that content to your players. You can perform an export of only the material you've revealed. Then your players can import that material into a realm of their own. Once they do that, they can freely edit and augment that material, adding their own notes whatnot. You can subsequently continue exporting your ever-growing realm as the campaign progresses. The players can then import those updates, and they will get all the new and revised content each time, with full edit capability!

There are two caveats to the above...

First, the players can edit the material you gave them, but they can NOT give that material back to you after editing it. Once they edit it, it's theirs alone. So this is not a viable work-around for collaborative development.

Second, the players will need to add their own stuff into SEPARATE snippets from the ones you've shared. Once they edit something, it becomes their own. Consequently, if you share a updated version of your realm with them, they will be forced to choose whether to keep their own changes or have your new updates overwrite their changes. As long as they add their own stuff into distinct snippets (on the same topics), all new material and revisions you share will be updated properly and never impact the player's changes.

And now for the caveat to the caveat...

If all you want is for your players to ADD new material, such as their own journals or whatnot, I think you MAY be able to fold those changes back into your realm. I honestly don't know if this is possible, since it's not something I thought about until just now. However, you MIGHT be able to have your player make his changes into separate topics, then have the player export those topics from his own realm. Those changes could be imported back into your realm, becoming part of the official canon. The absolute requirement of all this, though, would be that you could not subsequently edit the material you got from the players, for all the same reasons above. If you did, then your changes would become your own. If you exported those changes, the players would import them and now have TWO instances of everything you edited - their original one and your edited one. I guess this wouldn't be horrible, but it would be a limitation of the approach.

To repeat, I'm NOT sure whether this last idea is viable. It seems like it might work in concept, but there could be a wrinkle or two that I'm not thinking of right now - wrinkles that undermine the entire idea. So this is something that will need to be explored, but it's not something I can do right now. It will remain an unknown for the time being. :)

[Seeker1728]

Rob, interesting stuff about sharing, thank you for pointing those out as my co-GM and I were discussing some things as our familiarity with the program has been progressing. A couple more Q's if you (or someone?) wouldn't mind answering at leisure?


With HL, I can open multiple instances and do work on each one separately. I often did authoring this way as one instance would have the default rules/code in place, and the other was the user ruleset I was developing (and sometimes I'd even have 3 instances open of mine/buddy/core rules). I don't seem to be able to do that with RW or simply haven't figured out how to just yet. Is there any way to open more than one instance of RW?

The caveats mentioned are obviously not suited for collaboration on creating a game world that can be co-developed. Is this something that will be a ambition for RW in the future?

[Silveras]

I can't speak to RealmWorks' future, but for now, it is one-instance at a time. Of course, within that one instance, you can have different tabs opened.. one to a World Almanac (Story) subject you want to edit, and another to a Mechanics (Rules) item you want to read.

Currently, how best to use the Mechanics is up for debate. Putting ALL of the rules in can lead to multiple "false matches" for suggested links (for example, a "Stairs" location in an adventure might prompt for links to "stairs" the rules topic.. or, a sentence like "under cover of night, they infiltrate" might lead to suggested matches on "Cover".

The suggested use of special padding characters (such as [Cover] to differentiate the rules about Cover from other uses of the word "Cover") do not appeal to me.. they seem to undermine the point of auto-linking being intended to make life easier. If I have to re-write all my rules entries to mask them from detection, then re-write all of the content where I *do* want a match, that doesn't seem like a good solution to me.

Anyway, remember that RealmWorks is opening a file that contains all of your topics in all of your Realms. The expectation with HeroLab is that you won't be editing the same file in each copy. RealmWorks only has one database to work from.

[rob]

With HL, I can open multiple instances and do work on each one separately. I often did authoring this way as one instance would have the default rules/code in place, and the other was the user ruleset I was developing (and sometimes I'd even have 3 instances open of mine/buddy/core rules). I don't seem to be able to do that with RW or simply haven't figured out how to just yet. Is there any way to open more than one instance of RW?

Realm Works is a single instance. Within that instance, you can have multiple tabs open and be actively editing different content at the same time. And all of those topics can have cross-references to each other while you're editing. Managing all those cross-references while everything is in flux is quite complicated within a single instance. Doing that across different instances of the product, like Hero Lab, would be vastly more complicated.

Based on your example, it sounds like all you need to do is open up multiple tabs with the different content that you want to switch between. :)

The caveats mentioned are obviously not suited for collaboration on creating a game world that can be co-developed. Is this something that will be a ambition for RW in the future?

It's definitely something that we've mapped out for the future. However, it's not something that we'll realistically have in place relatively soon. We'll be doing another user survey a little while after the Content Market rolls out, at which point we'll be seeking user feedback on what capabilities are most important for us to focus on next.

[rob]

Currently, how best to use the Mechanics is up for debate. Putting ALL of the rules in can lead to multiple "false matches" for suggested links (for example, a "Stairs" location in an adventure might prompt for links to "stairs" the rules topic.. or, a sentence like "under cover of night, they infiltrate" might lead to suggested matches on "Cover".

The suggested use of special padding characters (such as [Cover] to differentiate the rules about Cover from other uses of the word "Cover") do not appeal to me.. they seem to undermine the point of auto-linking being intended to make life easier. If I have to re-write all my rules entries to mask them from detection, then re-write all of the content where I *do* want a match, that doesn't seem like a good solution to me.

The above limitations and workarounds are LONG out-dated. Over a year ago, we introduced extensive control over the behavior of automatic link detection that can be readily employed to avoid the examples you cite.

It's trivial to mark a given topic, or an individual name for a topic, to be ignored during auto-detection. So a common room like "Stairs" or "Kitchen" can simply be designated as non-matching.

For a rule entry, such as "Cover", you can designate it to be ignored unless the case matches. So a reference to "under cover of night" will be skipped, while a reference to "See the Cover rules for details" would match.

Lots of other control exists over the rules for name detection. So it's now quite easy to handle the vast majority of cases where the generalized logic could get a bit annoying.

We're making extensive use of all the extensions to automatic detection with content we're working on in-house. And it's all working quite well. So I urge to take a closer look and see how you can leverage it for yourself!

[Silveras]

The above limitations and workarounds are LONG out-dated. Over a year ago, we introduced extensive control over the behavior of automatic link detection that can be readily employed to avoid the examples you cite.

It's trivial to mark a given topic, or an individual name for a topic, to be ignored during auto-detection. So a common room like "Stairs" or "Kitchen" can simply be designated as non-matching.

For a rule entry, such as "Cover", you can designate it to be ignored unless the case matches. So a reference to "under cover of night" will be skipped, while a reference to "See the Cover rules for details" would match.

Lots of other control exists over the rules for name detection. So it's now quite easy to handle the vast majority of cases where the generalized logic could get a bit annoying.

We're making extensive use of all the extensions to automatic detection with content we're working on in-house. And it's all working quite well. So I urge to take a closer look and see how you can leverage it for yourself!

Granted, there are now controls over case-senstivity, to allow "Cover" not to match "cover", for example. And being able to prevent common terms from being suggested at all is also very helpful.

The problems come in when you want "sometimes", instead of "always" or "never".

It makes me wonder whether an inherent difference between the Story and Mechanics topics should be that Mechanics topics only scan for links to other mechanics topics. That would reduce some of those, anyway. Story should still auto-suggest either. I think it is far more likely that Story will rely on Mechanics, than the other way around. Being able to create links manually for the fewer instances of Mechanics articles that need to link to Story may be acceptable (perhaps a question for a future survey?).

[rob]

The problems come in when you want "sometimes", instead of "always" or "never".

It makes me wonder whether an inherent difference between the Story and Mechanics topics should be that Mechanics topics only scan for links to other mechanics topics. That would reduce some of those, anyway. Story should still auto-suggest either. I think it is far more likely that Story will rely on Mechanics, than the other way around. Being able to create links manually for the fewer instances of Mechanics articles that need to link to Story may be acceptable (perhaps a question for a future survey?).

If the material being linked fails to use any consistent pattern, then I would argue that's probably a reflection on the content creator. The vast majority of content I've seen coming from substantive publishers in recent years is pretty good in that department. Is it all perfect? Certainly not. But it's pretty darn good and consistent. And with that consistency comes the ability to establish reliable rules for automatic handling.

Consequently, I won't argue with your statement that problems arise when you want "sometimes". However, I WILL argue that "sometimes" is actually very uncommon within the games most people are playing these days. As such, the "sometimes" contention feels like a "straw man" argument to me that only arises rarely, in which case the few exceptions are worth dealing with manually to gain the benefits of automatic linking the vast majority of the time.

I think the question of auto-linking across the Story vs. Mechanics boundary is probably a very subjective matter. Lots of users have commented (here on the forums and elsewhere) that they can't wait to have the rules linked from all the story content that references them. It can be incredibly useful to just click on the mechanic name within the story content and view the appropriate rules. If we were to adopt your proposal, that capability would not exist. And I've got a feeling that lots of users would complain very loudly about that.

I'm not opposed to making this something that users can configure to their tastes, but it's definitely not a change to be made wholesale. And the question then becomes how many users feel the same as you on this matter, since that drives how to prioritize this relative to the zillion other things on our todo list. :)

[AEIOU]

I do want to embed mechanics in story content. That way skill checks, spells and mobs are identified as having information available.

If we can get a different color for mechanics links, that would be super-duper helpful. That way we could discern the two types of content.

Even better would be customizable link colors as I'd love mobs and NPCs to be the same color.

[Silveras]

I think the question of auto-linking across the Story vs. Mechanics boundary is probably a very subjective matter. Lots of users have commented (here on the forums and elsewhere) that they can't wait to have the rules linked from all the story content that references them. It can be incredibly useful to just click on the mechanic name within the story content and view the appropriate rules. If we were to adopt your proposal, that capability would not exist. And I've got a feeling that lots of users would complain very loudly about that.

I'm not opposed to making this something that users can configure to their tastes, but it's definitely not a change to be made wholesale. And the question then becomes how many users feel the same as you on this matter, since that drives how to prioritize this relative to the zillion other things on our todo list. :)


I think you misunderstood my point. I was saying that there is likely more need for Story to link to Mechanics ("that Story will rely on Mechanics" is how I phrased it originally) than the other way around. There are very few, if any, use cases I can see for Mechanics to need to link to Story content.. but many the other way around.

[rob]

I think you misunderstood my point. I was saying that there is likely more need for Story to link to Mechanics ("that Story will rely on Mechanics" is how I phrased it originally) than the other way around. There are very few, if any, use cases I can see for Mechanics to need to link to Story content.. but many the other way around.

Based on our experience with content entry thus far, there are very few (if any) instances where Mechanics articles are getting tripped up on terms used within Story topics. The terminology is just so different. So limiting Mechanics articles to only scan other Mechanics articles will yield no appreciable difference in behavior. At least, that's based on the content we've been working with on our end. I guess it's possible that other game systems may blur the lines more, but I'm not able to think of any examples that make any sense in this regard.

[Seeker1728]

It's definitely something that we've mapped out for the future. However, it's not something that we'll realistically have in place relatively soon. We'll be doing another user survey a little while after the Content Market rolls out, at which point we'll be seeking user feedback on what capabilities are most important for us to focus on next.

Yes, I've noticed that using the tabs to flip back and forth on my content for comparison/editing was fluid and good. But what I was trying to portray was in HL a base set of system content that you don't want to (or often can't) change and leave alone, but that a 2nd instance of HL holding the modified bit of content that has its own data file.

I.E. using Pathfinder core files, looking at how the core system does something, then loading up the editor and creating a user specific set of files that get loaded into a player's HL file with the .user extension.

But from what I take from your reply is that RW is basically a different animal all together since each realm is a custom creation from the word go. It does make me wonder how the content market interacts then, however if I understand everything I've read on it is that once imported, one adds custom snippets and now that content becomes your unique content with one's custom spins not having any effect on the file hosted on the content market. Which is really cool stuff btw, looking forward to seeing it.

(also, i got to ask, does LWD plan on creating future RW content that they acquire licenses for such as Golarion or Shadowrun world setting, etc? that one can purchase, intergrate into one's master-realm file and then customize?)

As for the future of collaboration. I understand, get one thing down and working smoothly first and then build on it, and I'll definitely be looking forward to seeing it go live. Just sometimes i want my toys now darnnit! ;)

I do want to embed mechanics in story content. That way skill checks, spells and mobs are identified as having information available.

If we can get a different color for mechanics links, that would be super-duper helpful. That way we could discern the two types of content.

Even better would be customizable link colors as I'd love mobs and NPCs to be the same color.

I do the same thing as Aeiou does, perhaps I'm a little OCD here but my masterfile is a growing data base of system info, particularly since HL doesn't have an Exalted data-pack. This lets me integrate any errata that comes out and puts it all into one library of data so my players don't have to hunt through errata docs. I've been digging into customizing the links via case sensitivity and when it builds link to reduce the number of links in one article going to the same place due to grammar rules being in play, I've learned a thing or two about the menu of choices when building links. All cool stuff.

And briefly, I'd heartily welcome color coding to link, while custom coloring would of course be nice, I'd be happy with just general colors such as Blue leads to the World Almanac, Green = Story Almanac, Red = Mechanic Ref, just so that with a mere glance you know where those links have their containers.

Other Q's
I do seem however, to be operating under a flawed assumption with topic titles and link detection.

My assumption is that every character in the topic title helps make it a unique thing. I.E. Terrestrial vs Terrestrial-, vs Terrestrial-Breeding. Each as a separate topic title/article will have the auto-link detection pick up on the differences. But this is turning out not to be the case, or perhaps it would be but I'm not using the settings correctly.

Right now, if I let the links create by themselves, RW makes no distinction between them, all 3 point at the same thing and it doesn't even offer me a choice of which container to choose from, it points at the alias of "Terrestrial" es the only option. I have to create a custom link to the article I want the link pointing to.

So my question would be this: Does RW notice the difference in link detection with certain characters or even letter casing within a topic as separate thinks to link to?

A current example:
Topic Title = "Terrestrial" (used as an alias to the topic Dragon-Blooded, case matching = sensitive, Priority = normal) Any text that uses "Terestrial" links to the Dragon-Blooded topic automatically upon approval (this is as I wish it to).
Topic Title = "Terrestrial-" (with the hyphen) Is desired to link to a different topic containing the hypen in the topic title, but instead links to article on Dragon-Blooded, the link created sees and marks as blue the word "Terrestrial" but ignores the hyphen forcing me to customize where it points at
Topic Title = "TerrestrialX" Is desired to auto-link to a yet another different topic containing the capital X on the end, instead it connects to the topic Dragon-Blooded just like it does with a hyphen on the end. No choices pop up to choose between "Terrestrial" or "TerrestrialX"

Up till now, I thought case sensitive assigned via F7 "Manage Names would do the trick, for both the use of a hyphen (or any other symbol for that matter) or using upper case characters in the topic title, but this doesn't seem to be the case. What would be the recommend best practice for handling something like this?

Quick Note: My use of these terms is based on the desire to have Dragon-Blooded as a topic, Terrestrial as an alias to Dragon-Blooded, and a merit that a given Dragon-Blooded can buy called Terrestrial Breeding that grants specific enhancements depending on the investment. I like to keep all the merits of the game, regardless of race, under the topic container of "Merits". So putting this under a snippet in the Dragon-Blooded article goes counter to this intent.

[Silveras]

For the hyphen, I know that at least some punctuation is ignored so that parenthesized entries without spaces between the term and the parentheses, for example, would work. There were persistent issues for people where the Topic "The Shadow" would not link if the text was like "Lamont Cranston (The Shadow) made his way... ".

A single trailing "X" may be treated like a punctuation mark.. an extraneous character that is being ignored as "not different enough" (though that's just a guess). Have you tried making it "TerrestrialXXX" instead of "TerrestrialX", or something equally different?

[rob]

But from what I take from your reply is that RW is basically a different animal all together since each realm is a custom creation from the word go. It does make me wonder how the content market interacts then, however if I understand everything I've read on it is that once imported, one adds custom snippets and now that content becomes your unique content with one's custom spins not having any effect on the file hosted on the content market. Which is really cool stuff btw, looking forward to seeing it.

An important aspect of the December release will be the ability to export content and then import it back in. So you'll be able to create Realm1 as effectively a "master" realm. Then you can export it and import it into Realm2. You can then modify Realm2 independently of Realm1. You can also give your exported content to other users, and they can import it into their own realms. This approach becomes similar to you example of having a Hero Lab ".user" file that gets created and then used by others within Hero Lab.

(also, i got to ask, does LWD plan on creating future RW content that they acquire licenses for such as Golarion or Shadowrun world setting, etc? that one can purchase, intergrate into one's master-realm file and then customize?)

Absolutely! When we launch the Content Market in December, we'll have an assortment of material from a variety of publishers. We have a license in place with Paizo, so we'll definitely be releasing Pathfinder material. We're working on a license with other publishers, as well.

And briefly, I'd heartily welcome color coding to link, while custom coloring would of course be nice, I'd be happy with just general colors such as Blue leads to the World Almanac, Green = Story Almanac, Red = Mechanic Ref, just so that with a mere glance you know where those links have their containers.

Just in case there's any confusion, any content that exists within the Story Almanac automatically exists within the World Almanac. The World Almanac is ALL of your story content, while the Story Almanac is a subset of that material. :)

I'll tackle the linking issues in a separate reply, since this will otherwise be an overly big reply. :)

[rob]

My assumption is that every character in the topic title helps make it a unique thing. I.E. Terrestrial vs Terrestrial-, vs Terrestrial-Breeding. Each as a separate topic title/article will have the auto-link detection pick up on the differences. But this is turning out not to be the case, or perhaps it would be but I'm not using the settings correctly.

Right now, if I let the links create by themselves, RW makes no distinction between them, all 3 point at the same thing and it doesn't even offer me a choice of which container to choose from, it points at the alias of "Terrestrial" es the only option. I have to create a custom link to the article I want the link pointing to.

So my question would be this: Does RW notice the difference in link detection with certain characters or even letter casing within a topic as separate thinks to link to?

A current example:
Topic Title = "Terrestrial" (used as an alias to the topic Dragon-Blooded, case matching = sensitive, Priority = normal) Any text that uses "Terestrial" links to the Dragon-Blooded topic automatically upon approval (this is as I wish it to).
Topic Title = "Terrestrial-" (with the hyphen) Is desired to link to a different topic containing the hypen in the topic title, but instead links to article on Dragon-Blooded, the link created sees and marks as blue the word "Terrestrial" but ignores the hyphen forcing me to customize where it points at
Topic Title = "TerrestrialX" Is desired to auto-link to a yet another different topic containing the capital X on the end, instead it connects to the topic Dragon-Blooded just like it does with a hyphen on the end. No choices pop up to choose between "Terrestrial" or "TerrestrialX"

Up till now, I thought case sensitive assigned via F7 "Manage Names would do the trick, for both the use of a hyphen (or any other symbol for that matter) or using upper case characters in the topic title, but this doesn't seem to be the case. What would be the recommend best practice for handling something like this?

Quick Note: My use of these terms is based on the desire to have Dragon-Blooded as a topic, Terrestrial as an alias to Dragon-Blooded, and a merit that a given Dragon-Blooded can buy called Terrestrial Breeding that grants specific enhancements depending on the investment. I like to keep all the merits of the game, regardless of race, under the topic container of "Merits". So putting this under a snippet in the Dragon-Blooded article goes counter to this intent.

There are certain characters that get handled specially by Realm Works. Specifically, these characters are various types of punctuation that get used in complicated ways within content. The hyphen is a perfect example of this, since the use of hyphens is problematic. Periods, commas, quotes, and parenthesis are other prominent examples of punctuation that need special handling.

Publishers are typically pretty consistent about their use of hyphens, but users rarely are. Consequently, the use of hyphens is treated more like a suggestion than a concrete rule. If you put hyphens in a name, then those hyphens will not be required to achieve a match. In general, this works well, since hyphenated terms don't usually appear without the hyphens and mean something different. For example, using the term "Dragon-Blooded", it really doesn't matter whether the text in a snippet is "dragon-blooded" or "dragon blooded". You won't usually find those two words together where they mean something other than the term "dragon-blooded". So this behavior accommodates the occasional imprecision of user-entered text without usually introducing any problems.

Punctuation like quotes, periods, and commas require special handling, as well. Users will frequently type "Dr Brown" when they should have typed "Dr. Brown" (with the period). The same applies for commas, such as "Fred Jones MD" vs. "Fred Jones, MD". Regular quotes are often used within content that comes out of published material and word processors that auto-convert, but users rarely take the time to properly enter them. In addition, we had lots of users treating quotes as more like suggestions, especially when nicknames are involved. So we ultimately decided to treat quotes as optional, matching whether or not the quotes are included, either within the topic name or the snippet text.

Parentheses are another big gotcha, since a fair bit of published content seems to be inconsistent with their handling. Consequently, we also treat parentheses (and square brackets and curly braces) specially. In general, these characters are considered optional for matching.

So that should address the behaviors you're seeing with the hyphen, as well as explain similar non-obvious behaviors you may encounter with further experimentation. But that doesn't explain the "Terrestrial" vs. "TerrestrialX" behavior, which sounds like a bug. In some very quick tests, though, I was not able to reproduce anything like this. So my obligatory question has to be whether you fully saved the name changes before attempting to resolve links to the names. Assuming you did, then I'd need to see your database to figure out what's going sideways. That means you'll need to open a support ticket and then send us your realm database. And it's critical that you include detailed instructions of what topics are involved and what steps you're taking that are yielding wrong results. I don't know what could be going wrong for you, and the only way to figure that out is to actually see the data for myself. :)

[Vargr]

Read Rob's explanation about the linking and the handling of "odd" situations with interest. Good explanation.

So I went and did a little test.

I am entering the history of my world into RW, using the category "Incident" for each year of interest. My topic names are simply the year in question plus the abbreviation of the calendar system. For example

-64 AII
-24 AII
0 AII
5 AII
10 AII

Now, I also have a topic called AII.

All that is picked up is the AII when scanning for links - I would have expected to be given a choice of - say - "-64 AII" and "AII".

I can understand from Rob's explanation that it might be "by design" that the "-64" is ignored - and for a lot of good reasons.

I was wondering if it could be possible to somehow include years in the linking process, maybe by setting it up specially in the name function (CTRL + SHIFT + A).

If it is already possible to do so, please let me know how as I tried playing around and didn't find a way to do it.

LATER ADDITION:

Well, it seems to work fine if I select Auto Accept - otherwise it doesn't work - a tad odd, but it works :-)
I can live with that :-)

Now, if only we could batch edit things like that - and have RW bring the coffee... :-)

[AEIOU]

For hyphens, you may consider an en-dash or em-dash instead. For an em-dash, hold down ALT and type 0151. If you don't have a lot of the hyphenated words this might be a workaround.

[Seeker1728]

An important aspect of the December release will be the ability to export content and then import it back in. So you'll be able to create Realm1 as effectively a "master" realm. Then you can export it and import it into Realm2. You can then modify Realm2 independently of Realm1. You can also give your exported content to other users, and they can import it into their own realms. This approach becomes similar to you example of having a Hero Lab ".user" file that gets created and then used by others within Hero Lab.



Absolutely! When we launch the Content Market in December, we'll have an assortment of material from a variety of publishers. We have a license in place with Paizo, so we'll definitely be releasing Pathfinder material. We're working on a license with other publishers, as well.

Oh my, both of these points have me a bit giddy. While I may not be as into PF as I once was, I still love dinking about with its world/content as well as Shadowrun and your first point gives me a great deal of ideas going forward that I'll be eager to explore once it goes live.

There are certain characters that get handled specially by Realm Works. Specifically, these characters are various types of punctuation that get used in complicated ways within content. The hyphen is a perfect example of this<snip>

Rob, first a hearty a thank you for taking the time to explain how RW handles punctuation, that shed light on a whole host of possible Qs that were floating around in my head and i totally get now why things are coded this way.

As for the possibility of a bug, unfortunately when i ran into the capital letter not being recognized (I.E. TerrestrialX) I dropped it from my data base figuring it didn't make the difference I had hoped. I'll be dinking around with other naming conventions as a alternative to the use of a hyphen or even off capital use.


Now, if only we could batch edit things like that - and have RW bring the coffee... :-)

I think my copy of RW would start telling me I should lighten up on the coffee loads :rolleyes:

For hyphens, you may consider an en-dash or em-dash instead. For an em-dash, hold down ALT and type 0151. If you don't have a lot of the hyphenated words this might be a workaround.

Sadly, because I was under the mistaken impression that a hyphen would be seen as a totally different character I got a bit more than a few. I'm going to clean that up now that I understand more of the effects of punctuation. I tried your code but all I get is Win7 giving me 'don't do that' pings. I've tried highlighting the hyphen and Alt+0151 and at a blinking cursor on a editable field and get the same result. Typically it opens up a set of short cuts using the alt button instead.

However it did give me a idea I got curious to explore when I get more time today. I'm thinking of trying out symbols in the topic titles, specifically using the Tahoma font's symbol collection such as Ǎ ¦ È Է among others.

I'm a bit OCD about consistency so maintaining their use throughout the work wouldn't be a issue for me, but I've noticed that I can't make use of symbols via the create topic button or Cntrl+Q, however I can highlight the text and Cntrl+Q and it'll insert the symbol into the topic title (or at least, it appears to, I haven't tried that and building links yet). I'll experiment with this later on tonight and get back with some results, unless there's some feedback to this idea to discourage its use or any caveats I should be aware of.

Thank you all for your many contributions and answers, you have collectively been a huge asset to me with your replies. :D

[kbs666]

I think my copy of RW would start telling me I should lighten up on the coffee loads :rolleyes:

Better that than asking if you'd like to play a game or telling you its changed its name to SkyNet.

[Parody]

I tried your code but all I get is Win7 giving me 'don't do that' pings. I've tried highlighting the hyphen and Alt+0151 and at a blinking cursor on a editable field and get the same result. Typically it opens up a set of short cuts using the alt button instead.
You have to type the numbers on the numeric keypad while holding down Alt the entire time: [Hold Alt][Num0][Num1][Num5][Num1][Release Alt] = —.

If you don't have a numeric keypad you can't enter special characters this way. You can still use Format/Symbol in Realm Works to insert special characters in Text Snippets or copy/paste characters out of a Text Snippet, the Character Map (a program that comes with Windows), your favorite word processor (which likely has its own method of inserting special characters), or your chosen browser.

Note that some laptop/compact keyboards provide numeric keypad keys while holding down [Fn], but that may not work for this. All you can do is try it and see. :(

[AEIOU]

Thank you for the clarification, Parody. The secret is to hold the ALT key down while you press the four numbers, then let go and the symbol magically appears. I use 0151, 049 and 076 all the time.

— <-- this is what the em-dash looks like. It's slightly longer (wider?) than a standard dash as it's the size of a capital M. You should be able to copy/paste this to your work if the ALT+0151 isn't possible for you..

[kbs666]

You cannot use HTML entities for things like the EM Dash or any other special symbol. Just in case anyone else tries.

[Silveras]

An old application that is still on Windows is "Character Map"

You can use this to find special characters and their codes. You can also use it to copy the selected characer(s) to the clipboard.

[rob]

Read Rob's explanation about the linking and the handling of "odd" situations with interest. Good explanation.

So I went and did a little test.

I am entering the history of my world into RW, using the category "Incident" for each year of interest. My topic names are simply the year in question plus the abbreviation of the calendar system. For example

-64 AII
-24 AII
0 AII
5 AII
10 AII

Now, I also have a topic called AII.

All that is picked up is the AII when scanning for links - I would have expected to be given a choice of - say - "-64 AII" and "AII".

I can understand from Rob's explanation that it might be "by design" that the "-64" is ignored - and for a lot of good reasons.

I was wondering if it could be possible to somehow include years in the linking process, maybe by setting it up specially in the name function (CTRL + SHIFT + A).

If it is already possible to do so, please let me know how as I tried playing around and didn't find a way to do it.

LATER ADDITION:

Well, it seems to work fine if I select Auto Accept - otherwise it doesn't work - a tad odd, but it works :-)
I can live with that :-)

Now, if only we could batch edit things like that - and have RW bring the coffee... :-)

This sounds like a bug. There should be NO difference between auto-accept and normal link detection, except for not bothering you with the prompt. Please open a support ticket and report this situation with all the details you've provided above (and anything else you think might be helpful).

Beyond that, I have to question whether it's all that useful to have a topic named with a calendar year. With the published content we're entering, we use the actual incident as the name. For example, the topic names would be "Time of Darkness", "Great Flood", "Awakening of the Ancients", etc. Then we assign the calendar year as the prefix. The net result is that the events all get properly shown in chronological order (assuming you're sorting by prefix) and all references to one of the events (e.g. "Great Flood") throughout the text get auto-detected and linked up.

Based on the above usage that we've adopted, I'm honestly not sure if we've ever actually tested with topic names being driven by numbers. So (a) this may be a bug and (b) this may not be the best way of modeling the situation within your realms. :)

[rob]

For hyphens, you may consider an en-dash or em-dash instead. For an em-dash, hold down ALT and type 0151. If you don't have a lot of the hyphenated words this might be a workaround.

I don't remember for sure, but we may treat all three types of "dash" the same during link auto-detection for some of the same reasons cited above. So this suggestion might not yield the desired results.

[rob]

You cannot use HTML entities for things like the EM Dash or any other special symbol. Just in case anyone else tries.

RW is a Windows application, so everything in the UI operates using Rich Text. When the material is saved out, we convert it to HTML, and vice versa. Consequently, anything you enter into the UI is going to be treated as literal text. So entering and HTML entity like "&gt;" will ultimately be saved out as the HTML "&amp;gt;".

[Vargr]

This sounds like a bug. There should be NO difference between auto-accept and normal link detection, except for not bothering you with the prompt. Please open a support ticket and report this situation with all the details you've provided above (and anything else you think might be helpful).

Beyond that, I have to question whether it's all that useful to have a topic named with a calendar year. With the published content we're entering, we use the actual incident as the name. For example, the topic names would be "Time of Darkness", "Great Flood", "Awakening of the Ancients", etc. Then we assign the calendar year as the prefix. The net result is that the events all get properly shown in chronological order (assuming you're sorting by prefix) and all references to one of the events (e.g. "Great Flood") throughout the text get auto-detected and linked up.

Based on the above usage that we've adopted, I'm honestly not sure if we've ever actually tested with topic names being driven by numbers. So (a) this may be a bug and (b) this may not be the best way of modeling the situation within your realms. :)

Bug report sent in.

I prefer the "by year" approach as most of the entries (topics) does not have names.

If I note for a NPC that he was born in 512 AII the year will be linked and I can go and read what happened that year (be it nation-shattering or just trivia).

Also, one year (topic) might detail many events happening all over the empire and outside of the known world (for the PCs).

From a world creation and management aspect this seems the right approach :-)

[kbs666]

Bug report sent in.

I prefer the "by year" approach as most of the entries (topics) does not have names.

If I note for a NPC that he was born in 512 AII the year will be linked and I can go and read what happened that year (be it nation-shattering or just trivia).

Also, one year (topic) might detail many events happening all over the empire and outside of the known world (for the PCs).

From a world creation and management aspect this seems the right approach :-)
I will point out that this makes more sense from the way things like Wikipedia does articles on years. Major events in a year may get their own article but the year itself has its own article.

[Greebo]

I will point out that this makes more sense from the way things like Wikipedia does articles on years. Major events in a year may get their own article but the year itself has its own article.

That is, why I do it this way also.

[AEIOU]

I'm glad to see the ongoing discussion on dates, events and linkages between them. I've struggled with it for almost two years and every time I just give up. This is frustrating because that means a lot of history is not being recorded or linked very well in my campaign....

What I think I want is events as articles and a simple way to quickly add date info to anything with a timeline that pulls those dates together to create a big picture view and also allows filtering out duplicates. If something is important enough to warrant a date, it should have an article. The stumbling block with this is the inability to just type a date quickly but rather having to use the date-picker which is just tooooooo time consuming when you use dates that span millenia. And the need for timeline refinement.

[kbs666]

Ultimately a timeline would be useful as a visual tool. The more visual tools the better in my mind.

[Silveras]

There is a timeline view in RealmWorks.

It sorts date values, including start and end dates of Time Periods, so that, for example,

Jan 1 2001 12:00:00 AM - Start of 2001
Feb 28 2001 6:00:00 PM - [in-game event 1 defined]
March 10 2001 9:30:00 AM - NPC 1 death date
Dec 31, 2001 11:59:59 PM - End of 2001

Where these are three Topics ... a Year 2001 TimeSpan topic with begin and end dates defined as Jan 1 2001 12:00:00 AM and Dec 31 2001 11:59:59 PM... an Incident topic with a date time of Feb 28 2001 6:00:00 PM... and an Individual Topic with the date of death filled in as March 10 2001 9:30:00 AM.

One take-away from this is that you don't need to create a specific Incident for everything... the dates you put on your other Topics will appear in the TimeLine view.

Attached is a view of the timeline from my Rise of the Runelords Realm ... with spoilers minimized:

[AEIOU]

If only it wasn't so tedious to actually record dates....

[Silveras]

If you are recording dates that are relatively close together, then it isn't so bad (hence my earlier suggestion of trying to "cluster" your date work)... but, if you're entering a list of historical dates in separate months or years, then, yes, it is really painful.

If you're actually tracking dates in-session for the world as they happen, presumably they're pretty close together, and usually sequential. It becomes more painful when you need to add a prior date into the history, of course, but things like a "campaign journal" in which you record events as they occur are not so bad.

[Vargr]

There is a timeline view in RealmWorks.

[SNIP]

Attached is a view of the timeline from my Rise of the Runelords Realm ... with spoilers minimized:

But those are not Gregorian dates, are they?

:confused:

[Silveras]

But those are not Gregorian dates, are they?

:confused:

The Realm where I had some dates to show is from my Rise of the Runelords campaign. It was created while the Beta users had access to the calendars, so it happens to have the Golarion calendar as its basis. Because all of the calendars use the same "core", all date/time values should work regardless of calendar used.

And here's one that is using the Gregorian calendar. I put this together just now.

[Vargr]

The Realm where I had some dates to show is from my Rise of the Runelords campaign. It was created while the Beta users had access to the calendars, so it happens to have the Golarion calendar as its basis. Because all of the calendars use the same "core", all date/time values should work regardless of calendar used.

OK - I got it.

Just wanted to make sure that I hadn't missed something :-)