Xavier_WER
Sorceror
you got that wrong...In soviet Russia, game codes you!
In Soviet Russia, client hooks you!
RunUO Community
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
In Game Map Editor
- Thread starter Praxiiz
- Start date
- Status
In Soviet Russia, client hooks you!
Praxiiz
Sorceror
Status Update:
I finished the statics defragment methods that will be included in the map editor. This allows the removal of extra space in the statics files. I am testing them now to make sure the client files
match the server files exactly after a defrag.
As mentioned in a previous post, I now have the ability to make a series of changes and then update the blocks after the all the changes have been made instead of one at a time. Using this series of changes ability, I have added a circle rasterizing algorithm to allow changes to be made in a circle, given a radius. This is all done server side, which means that anyone who uses the system could develop their own shapes or methods of doing changes to an area. I plan to add a rectangular shape as well.
After researching the God Client, I have realized that incorporating the grid ability will be a major challenge. So I shelved that for now, and instead focused on a different way to do targeting. I added in the ability to patch into memory some multis that will be used exclusively for targetting. The multi.mul and multi.idx file are never changed on disk, only in memory to allow for this new targetting ability. At some future point, I may add in the ability to alter the multi files, but currently it is a low priority.
This is basically what it does:
This is a sample command that I implemented to show both the new targeting ability and the circle rasterizing algorithm (which I graciously got off wikipedia
)
[inccirculararea 5 10 (where 5 is the radius and 10 is the z direction of the change)
It brings up this multi target (the same one used for placing a house) with the same radius as specified on the command. I can move it around on screen until I find a place I want to make the change.
The result:
I finished the statics defragment methods that will be included in the map editor. This allows the removal of extra space in the statics files. I am testing them now to make sure the client files
match the server files exactly after a defrag.
As mentioned in a previous post, I now have the ability to make a series of changes and then update the blocks after the all the changes have been made instead of one at a time. Using this series of changes ability, I have added a circle rasterizing algorithm to allow changes to be made in a circle, given a radius. This is all done server side, which means that anyone who uses the system could develop their own shapes or methods of doing changes to an area. I plan to add a rectangular shape as well.
After researching the God Client, I have realized that incorporating the grid ability will be a major challenge. So I shelved that for now, and instead focused on a different way to do targeting. I added in the ability to patch into memory some multis that will be used exclusively for targetting. The multi.mul and multi.idx file are never changed on disk, only in memory to allow for this new targetting ability. At some future point, I may add in the ability to alter the multi files, but currently it is a low priority.
This is basically what it does:
This is a sample command that I implemented to show both the new targeting ability and the circle rasterizing algorithm (which I graciously got off wikipedia
)[inccirculararea 5 10 (where 5 is the radius and 10 is the z direction of the change)
It brings up this multi target (the same one used for placing a house) with the same radius as specified on the command. I can move it around on screen until I find a place I want to make the change.
The result:
Pure Insanity
Sorceror
Wow, that is pretty awesome. I really can't wait for this to be released. Just hope it doesn't end up a personal project that is never finished. :/
-hash-
Sorceror
It brings up this multi target (the same one used for placing a house) with the same radius as specified on the command. I can move it around on screen until I find a place I want to make the change.
There exists a packet that allows you to do this as well:
0xB4 - Target Obj List
----------------------
Client->Server:No
Server->Client:Yes
Length:dynamic
byte 0xB4
short size
bool/byte allowGround = true
int targetSerial
short x = 0
short y = 0
short z = 0
short numEntries
loop x numEntries
{
short artworkID
short hue
short x
short y
short z
}
The client responds with a normal 0x6C Target packet when placed.
Just in case you wanted options.
Attachments
-
example.png
Praxiiz
Sorceror
The system could be released within a day, the main question is if the existing complications are acceptable or not. Let me explain.
Right now I'm making a list of the features that need to be included in the release. The basic functionality is all done. The basic map operations to raise/lower/change land tiles are in place. The basic operations to add statics, delete statics, raise/lower/statics and change static ids are in place. All other commands will just be a combination of those. For example, the move static command I implemented is just two commands, delete static and add static. I could just release the system and depend on the community to help finish some of the commands that will make map editing more convenient.
The hashing system is setup so that whenever your character changes blocks, the server queries the client and the client sends back a packet containing 25 bytes plus a header for a total of ~40 bytes. Each byte is basically a version number of a block. This system could definitely be optimized to only send the additional blocks checks in the direction of the block change. That would reduce the amount of data send by the server even further, but it complicates the algorithm. So there's some optimizations that could be done there. The question is do I delay the release to make those optimizations, or do I include them in a later version.
One of the main concerns I have is the reliance on Razor. The choice to use razor was made in the interest of development time. It already handles packets and many of the other client interactions that this system needs. Using this existing functionality saves me a lot of time. The problem with doing this is that if razor undergoes any major changes, then it breaks this system. I am basically counting on Razor to remain a "minimally maintained project." Currently, when razor updates, each player using this system would have to run the setup batch file after the update. I'd like to avoid this, but there are several complications. The first is that to avoid it, I would have to write a loader for razor (unless anyone has another solution, in which case I'm all ears.). This means that programs which are made to launch razor automatically, will not use the custom launcher. They are already setup to launch Razor directly, not via a custom launcher.
Now I could write this project completely independent of Razor. If I do, I'll have to either make a custom launcher for the client which would break compatibility with Razor (since Razor doesn't know to launch it), or I'll have to find another way to inject the code needed into the client (possibly via global hooking, which I want to avoid) or modifications to the client install, which I also want to avoid. Building a custom launcher with a framework to handle packets may take some time, delaying the release even further.
Now if people are willing to shutdown razor after it updates and run the included setup file, then this shouldn't be a big deal. But many players don't want to hassle with it, so I'm still trying to figure out how to best approach this.
The final thing I'm considering is that right now, a player never gets all the changes to a map unless they visit each section of the map that has been altered by the system. This is ok if you're using the system to stream map changes to players as they play. But if you're trying to use it exclusively as a map editor (and you don't intend to use the system on a live shard with all your players), then you'll still have to get the complete mul files off the server before you distribute them. This is especially true if multiple people are working on the map at the same time. So the question still remains, do I include an option for people to receive updates every time any of the maps get changed for the case scenario where this is being used as a pure map editor?
If people want to use it to stream changes to their players and use it for other in game systems, and if the players are willing to accept the setup method as it is, then I could release it almost immediately. There are a couple miscellaneous things that need to be done before the release, but they shouldn't take more than a day or two.
-hash-
Sorceror
Pure Insanity
Sorceror
I think you should release it the easy way you can think of. Giving server owners time to play with it and decide how they want to deploy it. Then they could easier use your method and convince their players to just restart razor after it updates (damn thing is rarely updated...won't be much of an issue there.) And if the server owners aren't a big fan of how the setup process is done...or how it works feature-wise. Then they can simply come to you and give you some feedback. As really it's a bit hard to give much feedback atm, as the only things we know about the system is what you've told us. Just easier to wrap your mind around things if you are able to test it out yourself.
Personally, I don't care how it's done. The idea alone is enough to make any setup process worth the trouble. I can't wait for the release, can't wait to toy around with the server pat and see what I can do with it on my shard. On thing I'd like to suggest if you feel you have time to get it in before you release it...is something basic such as a command that you could use to add cave entrances. Not needed...as we could always do that, since that part is server side. I just know that creating cave entrances hasn't always been really easy in the past. Believe there's only one program out there that does it decently.
The community and myself will most likely love this system...as it's rather unique and could add a whole different level of game play to the game if used properly. You're really outdone yourself. =D
Personally, I don't care how it's done. The idea alone is enough to make any setup process worth the trouble. I can't wait for the release, can't wait to toy around with the server pat and see what I can do with it on my shard. On thing I'd like to suggest if you feel you have time to get it in before you release it...is something basic such as a command that you could use to add cave entrances. Not needed...as we could always do that, since that part is server side. I just know that creating cave entrances hasn't always been really easy in the past. Believe there's only one program out there that does it decently.
The community and myself will most likely love this system...as it's rather unique and could add a whole different level of game play to the game if used properly. You're really outdone yourself. =D
Thagoras
Sorceror
What would be nice, is it Razor had like a plugin option.
And I agree with Insanity. I think that most players and admins would be ok with having to run the setup when/if razor updated because of the huge payoff of having custom maps.
Would it take long to update a long string of changes? Like if you were to have it update changes on login. I suppose that would make it harder for multiple people to modify the map at a time though.
And I agree with Insanity. I think that most players and admins would be ok with having to run the setup when/if razor updated because of the huge payoff of having custom maps.
Would it take long to update a long string of changes? Like if you were to have it update changes on login. I suppose that would make it harder for multiple people to modify the map at a time though.
Praxiiz
Sorceror
Status Update:
I'm currently tying up loose ends and getting ready for a release. I had to disable Razor's mini-map because it is not compatible with memory mapped files when they are shared in read/write mode. For now I've simply hidden/disabled the button that brings up razors mini-map. The first release will consist of just the basic functionality that I've finished. There will undoubtedly be commands / features that people will want, and it is definitely not a polished map editor. I've decided that since this project can really be taken in two major directions (an interactive map patching system for the players and a map editor), that I will release it a couple different packages. This way shard owners can download the parts they want / need.
On another note, I've discovered that there may be a way to allow the client to handle additional maps if the map size matches one of the stock ones. For example, you could build 4 or 5 custom maps that are all the size of Felucca, and the framework would automatically swap between them. This feature wouldn't be in this upcoming release of course, but its on my list of things to investigate further. Since I can't do it completely through hooking, I'll have to come up with a good algorithm that works for a range of clients.
I'm currently tying up loose ends and getting ready for a release. I had to disable Razor's mini-map because it is not compatible with memory mapped files when they are shared in read/write mode. For now I've simply hidden/disabled the button that brings up razors mini-map. The first release will consist of just the basic functionality that I've finished. There will undoubtedly be commands / features that people will want, and it is definitely not a polished map editor. I've decided that since this project can really be taken in two major directions (an interactive map patching system for the players and a map editor), that I will release it a couple different packages. This way shard owners can download the parts they want / need.
On another note, I've discovered that there may be a way to allow the client to handle additional maps if the map size matches one of the stock ones. For example, you could build 4 or 5 custom maps that are all the size of Felucca, and the framework would automatically swap between them. This feature wouldn't be in this upcoming release of course, but its on my list of things to investigate further. Since I can't do it completely through hooking, I'll have to come up with a good algorithm that works for a range of clients.
Pure Insanity
Sorceror
That would be neat. Atm it appears as if we have 6 different maps on my server. I replaced Fel with a custom map, then cloned Tram and reworked the clone a bit to look like Fel. As far as the server knows, and the clients...it just seems like a new map. Also with the ability of cloning existing maps, I can make it appear as there are even more maps...but the real thing would be far better than a clone. Would love to see it finished and working. D:
Warstone
Sorceror
In about year ago I wrote guide - how you can "change 8 bytes" and get 32768*8196 map. Later tests bring me idea that you can even get it more that 64K*64K, If you change some packets (with UOExt) and write plugin to UOExt map size may be any...
You need to change movment packets (add 4 bytes for X and Y) and X mod <Felluca-Width> will be client X, while UOExt will fix staidxX.mul and mapX.mul in memory... Map right block of real files in memory and you'll get similar effect.
You need to change movment packets (add 4 bytes for X and Y) and X mod <Felluca-Width> will be client X, while UOExt will fix staidxX.mul and mapX.mul in memory... Map right block of real files in memory and you'll get similar effect.
Warstone
Sorceror
There one thing that I must mention about my algo... Such static won't be visible on radar. ((
Next one - if you need radar, you may use custom house mechanics... one house for one tile square (8*8) for example. It's a bit more complicated and I didn't test it, but it must work with radar.
Next one - if you need radar, you may use custom house mechanics... one house for one tile square (8*8) for example. It's a bit more complicated and I didn't test it, but it must work with radar.
Praxiiz
Sorceror
I've decided to call this project UltimaLive. The first alpha release is in the Custom Script Releases forum. Please direct any further comments there.
- Status