PC A17 How Long Would You Wait For A Pre-Generated Map to Build?

A17 How Long Would You Wait For A Pre-Generated Map to Build?

  • 8k x 8k 5-10 minutes

    Votes: 0 0.0%
  • 10k x 10k 8-16 minutes

    Votes: 0 0.0%
  • 12k x 12k 12-23 minutes

    Votes: 0 0.0%
  • 16k x 16k 20-40 minutes

    Votes: 0 0.0%
  • 17.73k x 17.73k 25-50 minutes

    Votes: 0 0.0%
  • 20k x 20k 32-63 minutes

    Votes: 0 0.0%
  • I don't care if it takes all day.

    Votes: 0 0.0%

  • Total voters
    0
Here's the thing. According to Kinyajuu, the maps exist separately from our Saved character data which is why we can start a new save on a new map. I'd be all for a 16k x 16k option even if it ended up taking 2-3 hours because I could start on Navezgane and while playing that and checking out what's new I could generate a new random map each night before going to bed and let it work itself out while I'm sleeping. At the end of a week I would have 7 different maps I could choose to play all of which would be ready to load much more quickly thanks to the pregeneration already being done.
WAIT. Does that mean the need to restart every alpha is obsolete?

 
I don't think so. It's been very clearly stated that World Generation is not done on the fly as you play.
Server generated files sounds like what's been described. I'm just curious how much a new player to a map has to download before they can start playing. *shrug*

- - - Updated - - -

I think you may have missed some key points in this conversation. A17 and pre A17 maps for RWG are not the same.

Just hoping for some additional details. But my guess is that their either too busy trying to get out the release or this is one of the challenges with fully generating a RWG map that their trying to resolve prior to A17E launch.
The client does not read from the local .rg files, otherwise, it would always see "fresh" region files, not player builds, etc...

The generation is NOT done "on the fly", you are correct; it's done then exported, and those files are sent to the clients, just like in Nav. So instead of generating region files and having to do the calculations to GENERATE the files, it already knows what to generate, and send to the client.

Hope this makes sense.

As far as how much the client has to download, I suspect that'll be the same as it is now, a minimal amount.

Now, I know you're looking for an "official" explanation, and obviously Roland isn't Kinyajuu, but bear with me anyway...

Old method: Server needed to calculate what to generate in order to make the .rg files to send to clients

New method: Server already calculated what to generate in order to make the .rg files to send to the clients

BUT, let's try the old tried and true method: Kinyajuu, Kinyajuu, Kinyajuu, and see if we can get you that official explanation, rather than our poorly educated guesses. :)

 
To stop the guessing: Either we have the client do the same calculations as the server side (i.e. spend some time calculating) or the server has to send the Data/Worlds/-folder to the client (i.e. data transfer -> bandwidth + transfer time).

 
To stop the guessing: Either we have the client do the same calculations as the server side (i.e. spend some time calculating) or the server has to send the Data/Worlds/-folder to the client (i.e. data transfer -> bandwidth + transfer time).
Given the complexity of random gen, the data transfer method would be both faster and more efficient. The server would create the map only once during initialization. This could be further refined with compression on the map files to be unpacked by the connecting clients.

To do it the other way means that every single client that connects has to do the calculations, based on config information the game server would have to share anyway, no?

 
The client does not read from the local .rg files, otherwise, it would always see "fresh" region files, not player builds, etc...
The generation is NOT done "on the fly", you are correct; it's done then exported, and those files are sent to the clients, just like in Nav. So instead of generating region files and having to do the calculations to GENERATE the files, it already knows what to generate, and send to the client.

Hope this makes sense.

As far as how much the client has to download, I suspect that'll be the same as it is now, a minimal amount.

Now, I know you're looking for an "official" explanation, and obviously Roland isn't Kinyajuu, but bear with me anyway...

Old method: Server needed to calculate what to generate in order to make the .rg files to send to clients

New method: Server already calculated what to generate in order to make the .rg files to send to the clients

BUT, let's try the old tried and true method: Kinyajuu, Kinyajuu, Kinyajuu, and see if we can get you that official explanation, rather than our poorly educated guesses. :)
I dunno... I just connected to a Navs multiplayer server for the first time. My SavesLocal folder picked up a new game it seems with that connection and downloaded/created a map file as and something else but much smaller. Makes me think there's modified data that's paired with a map definition. Navs has all region files generated. And I'd think that's where it's getting the definition of what's the base map is around you. Especially since I only got a map file downloaded. Just guessing.

However my multiplayer randomgen saves seem to have HubCell data if memory serves. Though, for the RWG save data I looked at, it was old and wasn't literally from testing a connection today so I could find dates on files and folders that matched when I connected.

*shrug*

I dunno. Losing interest in the subject now lol. Moving on.

Nice chatting with ya again Guppy! Hope the toilets been treating you well!

 
8k is just not interesting, the exploring part of this game is just gone in a short time when playing with several players. Usually we play with 20kx20k but the smallest we can accept is 15kx15k, any smaller than that and this game become less interesting. But as long as players still can select what size they want Im happy.

 
Last edited by a moderator:
Back
Top