Senior Member
Join Date: May 2013
Posts: 1,458
|
Quote:
Now, it would be nice to have a command line interface for the database export so it can be scripted and scheduled. You could put that in the feature request. Heck, maybe I will. |
|
#31 |
Senior Member
Join Date: Oct 2011
Posts: 865
|
I was thinking close to the same thing that EightBitz is saying. Since there is an export (and sync), I would like to see an auto-export/sync option. (Perhaps even based on time). I think ill put in the feature request.
Last edited by mirtos; April 14th, 2014 at 07:28 AM. |
#32 |
Senior Member
Lone Wolf Staff
Join Date: Jun 2011
Posts: 1,090
|
Quote:
|
|
#33 |
Senior Member
Join Date: Nov 2010
Location: Metairie, LA, USA
Posts: 1,819
|
Quote:
Lenny Zimmermann Metairie, LA, USA Data files authored (please let me know if you see any issues with any of these if you have/use them): Official (In the downloader) 50 Fathoms, Deadlands: Hell On Earth, Deadlands: Noir, East Texas University, Necessary Evil (requires Super Powers Companion), Pirates of the Spanish Main, Space 1889 (original file by Erich), Tour of Darkness, Weird War II, Weird Wars: Rome Coming Eventually Evernight (LWD has completed their review but I have some fixes to make first... although Pinnacle mentioned this might get an overhaul to SWADE so I may just wait for that first. If you just HAVE to have this now, though, just PM me) |
|
#34 |
Senior Member
Lone Wolf Staff
Join Date: Jun 2011
Posts: 1,090
|
A request to the cloud server to get an ID used to generate ID's offline would be required in this case. This request doesn't require a cloud subscription and is needed so that if you ever do decide to sync to the server, there won't be any problems with ID's colliding with anyone else's ID's. That is the only purpose and it is not intended as a DRM mechanism in any fashion.
|
#35 |
Junior Member
Join Date: Feb 2014
Posts: 11
|
Quote:
*Backup the database to wherever, when Realm Works is closed. *<failure occurs/restore is needed> *Restore that same copy of the database to the new/repaired computer *Connect online to generate a new ID Correct? |
|
#36 |
Senior Member
Lone Wolf Staff
Join Date: Jun 2011
Posts: 1,090
|
Quote:
|
|
#37 |
Junior Member
Join Date: Feb 2014
Posts: 11
|
Awesome. Thanks David! And thanks again to zarlor/Lenny.
That is more or less the behavior I would expect, and not what the FAQ appears to say. I'm guessing that's intended to be the PR-speak for "don't do this", so I won't complain too much about it. That being said, I guess I need to go buy this now Because I can't help but push my luck, what would happen if I did keep it on the network drive, and used two different computers to access it, as long as I'm only accessing the database from one computer at a time, presumably updating the ID as needed? (Again, all the usual caveats about how I know this is a bad idea, but I'm curious anyway) |
#38 |
Senior Member
Join Date: Nov 2010
Location: Metairie, LA, USA
Posts: 1,819
|
You're welcome. Glad I could provide some useful info.
Lenny Zimmermann Metairie, LA, USA Data files authored (please let me know if you see any issues with any of these if you have/use them): Official (In the downloader) 50 Fathoms, Deadlands: Hell On Earth, Deadlands: Noir, East Texas University, Necessary Evil (requires Super Powers Companion), Pirates of the Spanish Main, Space 1889 (original file by Erich), Tour of Darkness, Weird War II, Weird Wars: Rome Coming Eventually Evernight (LWD has completed their review but I have some fixes to make first... although Pinnacle mentioned this might get an overhaul to SWADE so I may just wait for that first. If you just HAVE to have this now, though, just PM me) |
#39 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 8,232
|
First of all, a big THANK YOU to all of the techies here who have taken the time to accurately explain the complexities of what we've already done and why putting the database on a network drive for multi-user access would be a disaster trying to happen.
Now, to clarify the concerns about the database being tied to local hardware. If you have a database on ComputerA and back it up, you can take that backup to ComputerB and restore, with NO ILL EFFECTS. If you've already logged into your account on ComputerB before doing this, everything works immediately. If ComputerB is a brand new installation that has never talked to our server, the very first thing ComputerB will require you to do is login to our server. That way, it can automatically fixup the few details that reference ComputerA in the database to now reference ComputerB - something that's done implicitly if ComputerB has already connected to our server. Once that's done, you're off and running. As for the technical details behind this, remember that we have to be able to let users create content on multiple computers INDEPENDENTLY and OFFLINE. And we have to do this in a way that GUARANTEES that all content created on ComputerA can NEVER have an id that conflicts with content created on ComputerB. This requires that we uniquely identify each computer and coordinate that identity with our server to guarantee uniqueness. Once that's done, all new ids generated on a given computer are safely ensured to satisfy those requirements. We key on a variety of variables to uniquely identify a given computer. If those variables change, the computer will need to contact our server to get a new "identity" value before new content can be created. Obviously, this occurs when you switch computers. However, this behavior will also occur if you're using the same machine and simply replace the network card, for example. Once the new identity is coordinated with the server, a few quick fixups are made and then you're running smoothly again, but nothing can be changed until a new "machine identity" is coordinated with the server. There is absolutely nothing here motivated by DRM or control over how you access stuff, and it's personally very frustrating when that's the reaction many consumers have had to this architecture. In reality, it's all dictated by the desire to let users have MAXIMUM FLEXIBILITY in how and when they access their content, but we have to also guarantee that all that flexibility NEVER yields a conflict that will CORRUPT their data. It's a very difficult task that we could have simply solved by requiring users to always be online. But that wasn't our objective, and I'm very confident that allowing users to work offline is a huge benefit offered by Realm Works. The problem is that the flexibility has a trivial (IMO) cost, which is that we have to lock the client databases to specific machines in order to ensure everything works correctly. I hope this all makes sense and helps alleviate the concerns over DRM and control. |
#40 |
|
|