This site has been archived and made available for preservation purposes. No edits can be made.

Results 1 to 6 of 6

Thread: Thinking about saving and transferring data

  1. #1

    Thinking about saving and transferring data

    In single player our game-saves store every bit of data related to the game. In multiplayer we need a server that can construct on its own a snapshot of the world and the players in it. Of course after the fact, that snapshot is updated a bit at a time depending on the players who are in it. But also the assumption is you will check if the player's actions are bunk.

    Each person who joins a server downloads the whole snapshot from the server, and after a person can receive minor updates to the bits of the game. We do not use RELOAD.


    I say we need to find an efficient way to let the server run its image of the world, and copy the world out in part where the player's character is. Of course anyone who moves to a new zone will get a fresh copy of it in any case. But I do not mean the "bsa, textures, nifs, kfs, " and so on. But simply the states. We have to trust our players to have all the content and configurations set up right like in the realm of single player modding.




  2. #2

    Re: Thinking about saving and transferring data

    Using the save file is an efficient way of the server running it's image of the world. We just need an efficient way of it to save that image after so long.
    I have been working with GECK lately to provide new content in my server so far. Since GECK also allows scripting in the mods, I am going to try to have that autosave every so often, but still, I'm unsure if that will save server sided as well as client sided...

  3. #3

    Re: Thinking about saving and transferring data

    wait. you don't the fallout 3 or new vegas client saving your copy of the world. it will be biased because what updates for you is just what you do and you need their updates.

    it is a must that a server that can reliably construct what would otherwise be saved given the relevant parameters of the game world without the need to run the game. we understand the format of many of the files, including the game save.


    also the server only saves that snapshot to disk when the server itself is shuttindown.

  4. #4

    Re: Thinking about saving and transferring data

    That's why im messing around with GECK scripting until the server has something itself. Because if I'm correct, the server is running the world whether people are on it or not. So therefore, anything in the server that is changed on the server and saved, should still be saved into the server's saved game. GECK will allow my mod to to have the server save the game say, every minute. so, every minute, the game is being saved. But yeah, that still conflicts in the way that every time someone connects, they load the game of someone else and run off that...

  5. #5
    Administrator
    Join Date
    Jun 2011
    Location
    Germany
    Posts
    1,057
    Blog Entries
    5

    Re: Thinking about saving and transferring data

    The plan is to have a base savegame which won't change anymore (this provides first consistency between clients). The server will make sure everybody owns the same savegame and modification files (ESP / ESM). The dedicated server keeps track of all changed objects and states in-game and will save them to a custom file (the format needs to be invented) on shutdown or on command (this would be the snapshot). When a player enters the server, he will receive that snapshot plus everything which has changed since the last snapshot (the running game session snapshot).

    Before the player actually enters gameplay, the world will automatically get setup for him. Depending on the size of the snapshot, this may take little loading time. Snapshots are bound to the savegame. If the server owner changes the savegame, he can't use previously saved snapshots anymore (with that new savegame). These snapshots will mainly consist of the data which is already held by the game object classes of vaultmp (maybe even completely serialized)

  6. #6

    Re: Thinking about saving and transferring data

    [quote author=Recycler link=topic=319.msg3073#msg3073 date=1317129182]
    The plan is to have a base savegame which won't change anymore (this provides first consistency between clients). The server will make sure everybody owns the same savegame and modification files (ESP / ESM). The dedicated server keeps track of all changed objects and states in-game and will save them to a custom file (the format needs to be invented) on shutdown or on command (this would be the snapshot). When a player enters the server, he will receive that snapshot plus everything which has changed since the last snapshot (the running game session snapshot).

    Before the player actually enters gameplay, the world will automatically get setup for him. Depending on the size of the snapshot, this may take little loading time. Snapshots are bound to the savegame. If the server owner changes the savegame, he can't use previously saved snapshots anymore (with that new savegame). These snapshots will mainly consist of the data which is already held by the game object classes of vaultmp (maybe even completely serialized)
    [/quote]
    Perhaps we should follow garry's mod in the sense of fast download? Being able to outsource the saved file(s) could be greatly helpful and ease the lag when someone has to sync to grab the saved files.

Similar Threads

  1. Server sided saving
    By frankpetrov in forum Discussion
    Replies: 5
    Last Post: 09-27-2011, 05:13 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •