Software like Fantast Grounds actually allows the DM to mark maps as "Preloaded", i.e. the clients download them at the start of the game, meaning there is no interruptions during.
Perhaps the imaging sharing bit could be changed so that maps not currently in use are still transferred so that they are ready ahead of time?
Working on 1.1 release
Moderators: dorpond, trevor, Azhrei
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Sounds good to me. When we rebuild the networking and offload the image loading to a different thread (perhaps even socket connection) this will be much easierNomad3k wrote:Software like Fantast Grounds actually allows the DM to mark maps as "Preloaded", i.e. the clients download them at the start of the game, meaning there is no interruptions during.
Perhaps the imaging sharing bit could be changed so that maps not currently in use are still transferred so that they are ready ahead of time?
Dreaming of a 1.3 release
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Nope, doesn't matter what structure you put them in. This is because the images are ID'd by their content, not their location. When you add a directory to your image explorer note the status bar, it shows MT looking at all of the images. MT is looking at the images, calculating the unique ID based on content, and remembering where it is. That way when you drop an image into MT, all the clients look to see if they have a copy of it somewhere on the local filesystem before going to the server to get it.dorpond wrote:Trevor, does the player have to worry about where they put these images that the GM gives them? Does it have to be the same exact directory structure as the GM?
Dreaming of a 1.3 release
Ideal technique would be something akin to bittorrent: the first client gets the image (or part of it) from the server and the other clients retrieve their parts from that client (and other parts from the server).
Probably not a drop-in ability, though. Although it might be interesting for the server to feed URLs to the clients and those URLs could be of the "torrent://" format, indicating the location of the torrent tracker...
Better left for 1.2, I'm sure! Maybe even 1.3!
Probably not a drop-in ability, though. Although it might be interesting for the server to feed URLs to the clients and those URLs could be of the "torrent://" format, indicating the location of the torrent tracker...
Better left for 1.2, I'm sure! Maybe even 1.3!
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
The tricky part about peer to peer is that you have to get everybody's firewalls open and not just the server. It's often tricky enough just getting the server up and running.
However, there is a plan to allow images to have alternate download URLs so that you can download them from servers with big pipes. In fact, my plan to offload image loading will make it trivial to supply a list of image servers that can be queried whether they have the image or not (think map and token repositories).
However, there is a plan to allow images to have alternate download URLs so that you can download them from servers with big pipes. In fact, my plan to offload image loading will make it trivial to supply a list of image servers that can be queried whether they have the image or not (think map and token repositories).
Dreaming of a 1.3 release
Re:
Is it going to be implemented in the next (1.4) major release? I ask because I haven't seen this feature or similar in the list of the wall of feature!Azhrei wrote:Ideal technique would be something akin to bittorrent: the first client gets the image (or part of it) from the server and the other clients retrieve their parts from that client (and other parts from the server).
Probably not a drop-in ability, though. Although it might be interesting for the server to feed URLs to the clients and those URLs could be of the "torrent://" format, indicating the location of the torrent tracker...
Better left for 1.2, I'm sure! Maybe even 1.3!
Re: Working on 1.1 release
Probably not in 1.4.
Although I have an interest in this and would like to make it an option, so perhaps 1.5...?
Although I have an interest in this and would like to make it an option, so perhaps 1.5...?
Re: Working on 1.1 release
Check out Azureus. It is a JAVA based Open Source bittorrent client that does not need the firewall ports opened.
Re: Working on 1.1 release
holy thread necro batman!