Multiplayer?

[Havear]

Unfortunately we never got to the point where that might be an issue. It was a clean turn, nobody was doing anything, nothing out of the normal except for the three clients open.

[fflaguna]

What are you using to sync the file? I am not convinced that Dropbox's (or any other sync service's) file sync method is appropriate for handling an internet Aurora game.

I had multiplayer internet Aurora working successfully in my post above. We had two people both accessing the *same* Stevefire.mdb file at the same time from two separate clients, each designing a ship and SMing it into existence and then battling each other until one side won, with no database errors or corruption issues. See my post above for how we did it, involving setting up a VM with a VNC inside on the computer where the Aurora database file is stored. It's actually a very simple process.

Ask questions if you have any, as I'd love to help.

[JSilvanus]

I think I'd go with llaguna's view; Dropbox is unable to sync the file in the instantaneous manner required for simultaenous database access.  But with "turn-based" view it might work.  I'm bound to try it in a few weeks!

[Havear]

It was two VMs with clients open on my computer, while I had my client open natively. All three were using the same DB, albeit through shared folders through the VirtualBox VMs.

[sloanjh]

I imagine the database doesn't employ locks, so if Player1 was designing some component that relies on a number of related entries at the same time as Player2 then the @@identity could be getting messed up.

It's probably even worse than that.  A year or so ago I wrote a "SF Assistant Assistant" (not really what I called it) .NET app that allowed me to manipulate the SFA DB while running SFA (things like generating new officers through a GUI).  I ended up with a corrupt DB even though I would only interact with the SFA or SFAA interfaces sequentially.  Apparently manipulating an SFA DB that an instance of SFA is running on can corrupt the DB, even if nothing is happening in the SFA instance.

IIRC compacting the DB solved the corruption, but it kinda ruins the flow of the game

John

PS - It took a while for the corruption to happen - it wasn't a high probability event.

[fflaguna]

It was two VMs with clients open on my computer, while I had my client open natively. All three were using the same DB, albeit through shared folders through the VirtualBox VMs.

Weird, that sounds exactly like what we were doing. One client open natively, and one client open on the VM running on the same computer. We were two different races (in the same system), so none of the database read/writes overrode one another. The only issue we had was that sensor contacts would only update on the client who clicked the "progress time" button, since that was a function that only runs in the game client's RAM and is never saved as a database entry.

I don't know why it's not working for you. We were able to create ships and spawn them and fight to the death with no game corruption.

The method we were using was some sort of Windows home group file sharing thing using a network-mapped folder. Even though it's a rather simple thing to implement in theory, it was really awkward and it was difficult to set up in the first place.