Praxiiz
Sorceror
I'm mostly interested in the additional maps. Seems you've got a proof of concept going, to prove to yourself that it could work. But I have a few questions pertaining to this. Will the additional maps also support having their own separate statics? Will there be a way of making the additional maps client side and not have to send every bit of the map over the network. Do you plan on providing easy methods of...maybe copying/cloning a map?
If you have tested the additional maps...did you only test it with the client? Won't we still need to update the RunUO server core to work with the new maps?
Here is what I've done so far on the maps. My proof of concept has been all client side. Without the client working with it, there's zero chance of implementing it. I can successfully find where the client stores its memory pointer to a map/statics, and point it to a location I choose. This means I can allocate memory and point the client to that memory, and the client will use it as the map. This works with both the maps and statics.
To implement it, I plan on intercepting the MapChange packet and parse it for the map number. If it corresponds to an existing map file, then I will let it pass through. If it doesn't correspond to a normal map, then I'll check to see if that mapXX.mul file exists on the disk client side. If it doesn't exist, I'll create it as a blank file. The server won't stream the entire map to the client when they change maps. It only streams the current block the player is standing in and the 24 blocks around it. This means that as the player moves, portions of the map which aren't built will have the same CRC check as the client side (both will be essentially blank), which means no network bandwidth would be used on unfinished portions of the map. For finished portions, the server would stream blocks to the client as the client encounters them in its 25 block area. So running at full speed you'd probably expect to send a client 5 blocks per second. I'd be surprised if this was more than a few kilobytes of data.
Now I am fully expecting some complications server side. I haven't read through all the server side code dealing with maps, so I am speculating at this point. I am hoping that I will be able to register maps and give them a fileindex that is higher than the normal range. (Client is upto index 5 now?)
Just glancing through the MapDefinitions.cs file, I see
Code:
/* Example of registering a custom map:
* RegisterMap( 32, 0, 0, 6144, 4096, 3, "Iceland", MapRules.FeluccaRules );
*
* Defined:
* RegisterMap( <index>, <mapID>, <fileIndex>, <width>, <height>, <season>, <name>, <rules> );
* - <index> : An unreserved unique index for this map
* - <mapID> : An identification number used in client communications. For any visible maps, this value must be from 0-3
* - <fileIndex> : A file identification number. For any visible maps, this value must be 0, 2, 3, or 4
* - <width>, <height> : Size of the map (in tiles)
* - <name> : Reference name for the map, used in props gump, get/set commands, region loading, etc
* - <rules> : Rules and restrictions associated with the map. See documentation for details
*/
And glancing at the server core Map.cs file
Code:
public sealed class Map : IComparable, IComparable<Map>
{
public const int SectorSize = 16;
public const int SectorShift = 4;
public static int SectorActiveRange = 2;
private static Map[] m_Maps = new Map[0x100];
public static Map[] Maps { get { return m_Maps; } }
Initially, it looks like they've given the array for maps a capacity of 255. They reserve the first 32 for core use, and they also reserve 0x7F and 0xFF. This leaves space for 221 maps (some of which are likely being used with the same map index on custom shards already). As I said before I haven't read through it yet, I'm just speculating. I will dig into it further after I finish reducing the save times. I fully expect to be able to implement maps with their own sets of statics, and with their own map files.