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 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 ).

@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 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 ).

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? ) 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 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 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 ).

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.