its custom tile sets when it loads maps it adds to the value read from the map to get the correct set from data/map data/wemade or shanda.
You can have as many maps as you like as thats in the database
the 0-99 would allow you to add more tile sets to that set so in theory you could add custom ones and then use a map editor to build using the extended sets.
its custom tile sets when it loads maps it adds to the value read from the map to get the correct set from data/map data/wemade or shanda.
You can have as many maps as you like as thats in the database
the 0-99 would allow you to add more tile sets to that set so in theory you could add custom ones and then use a map editor to build using the extended sets.
Same libs setting is in the Map Editor where I have increased the number of ShandaMir2 libraries (=> SM2 libs).
Mind you, what is allowed is 100 libraries, not 'maps'. Maps you can have as many as you care to build from those libraries. I note this just to be clear.
And no, you cannot have more Object libs in that SM2 section with that code setting you posted, but that limit of i<31 for 30 Object libraries can be increased to the total count of 70 libraries with a simple tweak of the numbers in the code. I increased this number in the Map Editor but for the maps using these higher numbered libraries to also work in mir client, those changes must also be done in the mir client code (which mirrors that of the map editor).
I suppose in mir client, you might be well advised to keep the range limited just to the libraries you use because it might use extra resources but in the map editor it doesn't mater if you maximize it.
Default setting caps them at 30 Objects#.Lib libraries (there is 29 Objects libs in the classic or original set, leaving one spot to potentially add one new library - Objects31.lib). Mind you the 11 & 12 Object libs were always missing and those two places can also be used to put in new libs numbered 11 & 12, so you can have total 3 added libs if the code stays as is.
Those objects libraries contain all tiles to enable the classic (original) set of Shanda maps and more maps can be built up from those libs with variations on those existing maps.
This is the default SM2 lib setting in the map editor and in the mir client, I made it some years back when I was figuring it out. All relevant parameters that can be changed are marked. This pic shows the code in the map editor in MLibrary.cs
This code you (IHALN in OP) show here is from mir client which I take it mirrors the lib setup in the Map Editor.
In the editor I increased SM2 lib count to max by reducing the AniTiles1.lib reserved section from 10 libs to just one place (the last one for SM2 libs, the #199, originally that was 190-199). That freed 9 places to be taken over by Object libs, of which the new number in the MapEditor is 79.
100-199 gives clean 100 places, ten of them is assigned to Tiles, another ten to SMTiles, which leaves 80 places of which one is reserved for the AniTiles1.lib, so you can have the total of 79 Object.lib(s) which includes those existing classic ones.
You could ignore that AniTiles1.Lib since it is not used on any maps and in the code below, change that 79 to 80
This is the code currently in the Map Editor
C#:
//shanda mir2 (allowed from 100-199)
MapLibs[100] = new MLibrary(@".\Data\Map\ShandaMir2\Tiles");
ListItems[100] = new ListItem("Tiles", 100);
for (int i = 1; i < 10; i++)
{
if (File.Exists(@".\Data\Map\ShandaMir2\Tiles" + (i + 1) + ".lib"))
{
MapLibs[100 + i] = new MLibrary(@".\Data\Map\ShandaMir2\Tiles" + (i + 1));
ListItems[100 + i] = new ListItem("Tiles" + (i + 1), 100 + i);
}
}
MapLibs[110] = new MLibrary(@".\Data\Map\ShandaMir2\SmTiles");
ListItems[110] = new ListItem("SmTiles", 110);
for (int i = 1; i < 10; i++)
{
if (File.Exists(@".\Data\Map\ShandaMir2\SmTiles" + (i + 1) + ".lib"))
{
MapLibs[110 + i] = new MLibrary(@".\Data\Map\ShandaMir2\SmTiles" + (i + 1));
ListItems[110 + i] = new ListItem("SmTiles" + (i + 1), 110 + i);
}
}
MapLibs[120] = new MLibrary(@".\Data\Map\ShandaMir2\Objects");
ListItems[120] = new ListItem("Objects", 120);
for (int i = 1; i <79; i++)
{
if (File.Exists(@".\Data\Map\ShandaMir2\Objects" + (i + 1) + ".lib"))
{
MapLibs[120 + i] = new MLibrary(@".\Data\Map\ShandaMir2\Objects" + (i + 1));
ListItems[120 + i] = new ListItem("Objects" + (i + 1), 120 + i);
}
}
MapLibs[199] = new MLibrary(@".\Data\Map\ShandaMir2\AniTiles1");
ListItems[199] = new ListItem("AniTiles1", 199);
I think you could also use the space in WM2 section which has 26 Object libraries plus one Tiles.lib & one SmTiles.lib
Here for the Object libs the i ranges from 2 to 26 (ie., <27) which allows 25 libraries (actually currently there are 26 Object libs and the value should be i<28 ??
If the range in WM2 would be maximized to i<100, you could put in 98 Object libraries (I think, it is the count 2 to 99). So in addition to those 26 current libs, you could put in 98-26=72 additional Object libs
The question here is, do the 48x32 tile sizes really need to be in libraries called SmTiles? IMO they can just as well be in the Objects libraries. I say this because you may find you need more space for SmTiles libs (SM2 has space for one more Tiles lib and two more places for SmTiles lib).
And wider question is, do those ShandaMir2 libraries (of any of the three kinds) need to be in that SM2 space 100-199, or would they load just fine if they were put into WemadeMir2 libraries space?
As maps go, you have maps that call on libraries (that is load tiles from them) from any section. Like you can put an object, a building or a tree that use libraries in the mir3 library section on the classic mir2 Bichon province map and also place on it objects that use libs from ShandaMir2 lib section.
Suppose I use the TileCutter and cut up an image into tiles and use library editor to make new lib file and put these tiles into it. Then I put this new library into whichever lib space since a library is a library, right? For example, what makes a Shanda library a Shanda library?
This new library can't be called Shanda or Wemade or mir2 or mir3, it is a library like any other and so can be put where I have the space, right? New map is then built from the tiles in this new library and it will then always 'know' to load the tiles from it, never mind where originally I put the library (WM2 or SM3 lib space...).
Even the distinction between SmTiles and Objects libs is just a matter of convention. There are tons of SmTiles in Object libraries and why not. Only Tiles are still kept separate because they have double the 'normal' or SmTile tile size 96x64 but even these you can import them into Object library and load them from there I believe. You still have to observe the rule of placing them on back layer only. There are restrictions how you use the tiles when building maps from them but their separation into those three or four kinds map spaces (if include SM3) or library type is just a matter of convention. Or is it not?
I believe the maps in question here would be from the Fables map pack and those are Shanda map type maps and I take it, their libraries need to be put into that SM2 reserved space (data/maps/SM2). That is, if those maps did originally come with .Lib type libraries but they come with .wil ones.
These maps need to be assigned lib files to use and their location (since originally those maps used wil libraries that were converted to lib format). And in that process of assigning those libraries to the map in question, you have the choice of specifying the lib space where they would be placed (data/map/WM2 ... SM2 etc.).
That assignment I take it then changes (rewrites) the map type, right? That means you don't need to worry about what the map type originally was, since you need to (or can) make a new choice anyway (in the case of that Fables map pack) and you make the one that suits you (where you have the space available to place the libraries).
So the only change in code needed is to increase the 'i' value (loading or scanning lib range) within allowed limits to include the new added libs (in the particular location, WM2 or SM2 etc) in both the map editor and mir client.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
