Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: fflaguna
« on: July 26, 2012, 12:33:07 AM »

Quote from: Havear on July 25, 2012, 11:21:57 AM
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.
Posted by: sloanjh
« on: July 25, 2012, 11:58:58 PM »

Quote from: Beersatron on July 24, 2012, 10:51:45 PM
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.
Posted by: Havear
« on: July 25, 2012, 11:21:57 AM »

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.
Posted by: JSilvanus
« on: July 25, 2012, 10:03:20 AM »

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!
Posted by: fflaguna
« on: July 25, 2012, 09:44:52 AM »

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. :)
Posted by: Havear
« on: July 25, 2012, 12:01:58 AM »

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.
Posted by: Beersatron
« on: July 24, 2012, 10:51:45 PM »

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.
Posted by: Havear
« on: July 24, 2012, 08:07:28 PM »

Well we finally got everything setup and started playing. Aurora does NOT like having multiple clients accessing the DB at once apparently, as we managed one turn, got tons of desyncs (specifically the date not updating even with refreshes until one of the players opened game info and reselecting), followed by the database corrupting itself (which actually happened as that player selected the game again in game info).
Posted by: Havear
« on: July 23, 2012, 01:36:56 PM »

Here's something we're trying out right now in HazCom: I'm hosting a few VMs locally with Aurora being a shared folder. Each VM is in turn hosting a VNC connection with a unique password. Everyone connects and uses their own "client", and then when I have a consensus advance time on my own.
Posted by: sublight
« on: July 16, 2012, 12:09:31 PM »

Good news, Mutliplayer in Aurora is possible and is_being/has_been done. Hot-seat is easiest, but at least three games (including one I'm currently in) are/were done across the internet.

You need at least three people: two or more players plus one designated SM to advance time and watch for events that might require either immediate action or an early interrupt. I'm currently acting as the SM in one game with three player factions. We're posting a rough account in a game log here. For our game each faction has it's own password to help prevent accidental peaking, and the database is distributed through a shared dropbox folder. With .zip compression the database is 5-8 mb. Uploading a new database copy is fast (less than a minute) but doesn't allow people to simultaneously play off the same database at the same time.

Using relatively long time increments (3-12 game months) twice weekly has allowed us to play through 23 game years and counting so far.

A Co-Op game would be easier to run since you wouldn't need a designated SM, and as mentioned by jseah would allow better timing control.
Posted by: jseah
« on: July 16, 2012, 10:42:33 AM »

That would not be too bad if you play strictly Co-op.  You only need sensor checks for combat and Co-op means you can run in SM mode so you can tell each other about events in the event window. 
Call it "difficulties in coordinating task forces of different races".  =D
Posted by: Havear
« on: July 16, 2012, 10:00:18 AM »

If Stevefire.mdb is in a shared folder, Dropbox stores a copy locally on both machines. Every time it is updated, the changes are uploaded to their servers and then downloaded to everyone that uses it (except of course the user that modified it). I was considering doing something like this with the Tymas guys, but I don't have Access installed and a multi-gibibyte database file would be unwieldy to say the least. That sensor thing could be a semi-major issue for this as well.
Posted by: fflaguna
« on: July 16, 2012, 09:36:05 AM »

Quote from: JSilvanus on July 16, 2012, 08:41:53 AM
Can the database be simultaneously opened by multiple races? I mean, can it be multipated with a cloud file sync prpgram e. g.  dropbox, so that we simply only need to coordinate when someone presses time forward, not take turns in opening the db?

Yes, the database can be opened simultaneously AND MODIFIED SIMULTANEOUSLY with seemingly no issues by separate player races.

However, I don't think Dropbox's sync mechanism works in the way Aurora needs it to. I don't know how Dropbox syncs files in practice.

A problem you will run into is that the Aurora.exe makes ten zillion SEPARATE calls to the database every nanosecond, which means it takes foreeeevvvvvveeeerrr to load a screen. We're talking 5-10 minutes just to open the ship design screen for a player across the internet. Our solution was for me to run a local virtual machine on my computer, that the other person connected to and took control of through a VNC. That way the opponent's Aurora.exe is still running on my computer, and all the database calls are instantaneous. His client through the VNC connection was a bit sluggish, but now we're only talking 1-3 seconds to load the ship design screen now.

Anyway, that was my romp through multiplayer Aurora.
Posted by: fflaguna
« on: July 16, 2012, 09:31:20 AM »

Quote from: Brian on February 11, 2008, 04:32:48 PM
The only other way that I can see doing a multiplayer game would be with everyone logged onto a host server, and only one person allowed to increment time.  I actually did something like this with starfire, but that was quite different as the time ticks were for a fixed period of time, a turn based approach.  I am not sure how this would work with aurora.

Brian

This works with Aurora, and I have done it with someone, using two separate clients accessing the *same* Stevefire.mdb simultaneously using two different player races. It worked acceptably, with one minor flaw that ONLY the person whose client clicks "advance time" has their sensor readings updated. That means each player needs to alternate clicking the "advance time" button and they will only get sensor updates when it's their turn to advance time.

This is due to the fact that sensor contacts are stored in the client's memory now, and NOT in the database. Other than this issue, we had multiplayer Aurora going and we were doing battle with our 10,000-ton destroyers built by each side in secret.

I won. :)
Posted by: JSilvanus
« on: July 16, 2012, 08:41:53 AM »

Can the database be simultaneously opened by multiple races? I mean, can it be multipated with a cloud file sync prpgram e. g.  dropbox, so that we simply only need to coordinate when someone presses time forward, not take turns in opening the db?