file.em: ReadBinaryFile & WriteBinaryFile
Moderator: POL Developer
file.em: ReadBinaryFile & WriteBinaryFile
I was working on a static tool the last days and thought about my suggestion on an Integrated Static Tool for pol made here.
I could translate my work easily to escript if there would be a possibility for pol97 to read and write binary files like *.idx and *.mul.
This way not only a static tool can be scripted, even more tools are possible in that case.
I don't know if that can be done easily but it would be great if the file.em could contain 2 new commands in the future like:
ReadBinaryFile(filename);
WriteBinaryFile(filename);
I could translate my work easily to escript if there would be a possibility for pol97 to read and write binary files like *.idx and *.mul.
This way not only a static tool can be scripted, even more tools are possible in that case.
I don't know if that can be done easily but it would be great if the file.em could contain 2 new commands in the future like:
ReadBinaryFile(filename);
WriteBinaryFile(filename);
Considering the fact that POL uses it's own UO data file formats, I doubt the devs will love your idea about editing .mul/.idx files
But there are ofc other possibilities... Like editing the POL datafiles and back-uoconvert them to Muls.
Then there's quesiton of whether or not to support "dynamic statics" in the core, for example if the GodClient features were to be implemented (the ones that can directly manipulate statics) etc.
good luck anyway
But there are ofc other possibilities... Like editing the POL datafiles and back-uoconvert them to Muls.
Then there's quesiton of whether or not to support "dynamic statics" in the core, for example if the GodClient features were to be implemented (the ones that can directly manipulate statics) etc.
good luck anyway
That's not junk.
I don't know the source code of Pol, like everybody else. But e.g. RunUO simple implemented the binary readers from Visual Basic or the .Net Framework, i don't know. But something like this. And somebody writes a simple script using this feature to read and write statics on RunUO. I use this feature by myself with my own importpol command.
Therefor i reduce my wish on a static tool to this suggestion. In this case i could simply script it on my own. Change the statics. Shut Server down and run uoconvert. I don't think that this will mess up Pol in any way.
And i think this could be a reason if such scripts will be public that some admins will choose Pol not RunUO.
Now i have to run several different programs, which cost a lot of time and nerves. In my case i build something. Read the items.txt to a RunUO Server. Freeze the statics with their simple command there. Than i run uoconvert on the new files...
If i won't be a Pol fan i would change to RunUO cause that's a lot easier there. But i hate [commands
Therefor my suggestion for a binary reader possibility. The script i would write on my own and publish it afterwards. So everybody could change statics on their own on the server they know --> Pol
No need of UOSir, UOSP etc. anymore.
I don't know the source code of Pol, like everybody else. But e.g. RunUO simple implemented the binary readers from Visual Basic or the .Net Framework, i don't know. But something like this. And somebody writes a simple script using this feature to read and write statics on RunUO. I use this feature by myself with my own importpol command.
Therefor i reduce my wish on a static tool to this suggestion. In this case i could simply script it on my own. Change the statics. Shut Server down and run uoconvert. I don't think that this will mess up Pol in any way.
And i think this could be a reason if such scripts will be public that some admins will choose Pol not RunUO.
Now i have to run several different programs, which cost a lot of time and nerves. In my case i build something. Read the items.txt to a RunUO Server. Freeze the statics with their simple command there. Than i run uoconvert on the new files...
If i won't be a Pol fan i would change to RunUO cause that's a lot easier there. But i hate [commands
Therefor my suggestion for a binary reader possibility. The script i would write on my own and publish it afterwards. So everybody could change statics on their own on the server they know --> Pol
No need of UOSir, UOSP etc. anymore.
I don't think lack of duplication of many, many already existing tools out there is why many people don't choose POL. I don't think a single person would choose POL over RunUO if POL had scriptable binary streams.
On the other hand, I think POL would do real well if both core and distro dev were regular and steady, and there was a modicum of a real front page on the site.
Right now, people come and look around, and they probably see what looks like a brand-new emulator not really in 'Alpha-test' status, with a complete lack of workable distro, and fit-and-start core dev at best, for years now.
To the extent that anyone has time to devote to POL core/script dev anymore, it needs to be geared toward real features and fixes that will let people come to this site, and find a working shard server program.
I have no doubt it would be fairly simple to write a way to let us script against C++ binary file streams using integer arrays. But I would much rather the Devs' time be spent on things that don't duplicate tools already out there, at the expense of getting POL viable again.
On the other hand, I think POL would do real well if both core and distro dev were regular and steady, and there was a modicum of a real front page on the site.
Right now, people come and look around, and they probably see what looks like a brand-new emulator not really in 'Alpha-test' status, with a complete lack of workable distro, and fit-and-start core dev at best, for years now.
To the extent that anyone has time to devote to POL core/script dev anymore, it needs to be geared toward real features and fixes that will let people come to this site, and find a working shard server program.
I have no doubt it would be fairly simple to write a way to let us script against C++ binary file streams using integer arrays. But I would much rather the Devs' time be spent on things that don't duplicate tools already out there, at the expense of getting POL viable again.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Pierce,
I appreciate what you are saying about needing so many tools to do building and map modifications. It is a shame that someone hasn't written a program to do it all in one easy to use environment. You don't necessarily need RunUO but you do usually need several tools. I prefer to use something called World Builder but I don't want to get off topic (Yeah I know, too late).
Let me offer a better reason why the developers probably wouldn't like to have POL read and write binary files, security. I know from previous posts in the POL forums from a couple years ago that POLs file IO was strictly limited because of security concerns. That's why the only file format that POL has full modification rights to is TXT files. The developers' big concern was that if POL was able to modify too many file formats that it could lead to vulnerability issues. I hate to speak for them but in this case I know this to be the reason POLs file IO is clamped so tight.
I appreciate what you are saying about needing so many tools to do building and map modifications. It is a shame that someone hasn't written a program to do it all in one easy to use environment. You don't necessarily need RunUO but you do usually need several tools. I prefer to use something called World Builder but I don't want to get off topic (Yeah I know, too late).
Let me offer a better reason why the developers probably wouldn't like to have POL read and write binary files, security. I know from previous posts in the POL forums from a couple years ago that POLs file IO was strictly limited because of security concerns. That's why the only file format that POL has full modification rights to is TXT files. The developers' big concern was that if POL was able to modify too many file formats that it could lead to vulnerability issues. I hate to speak for them but in this case I know this to be the reason POLs file IO is clamped so tight.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
No reason to stop wishing. It does make sense here too despite what some might say because this is the "Feature Suggestions" forum.
It's just the developers have said they prefer keeping POL as secure as possible.
Perhaps there could be a way to write 8 bit binary data to a TXT file then manually change the extension to MUL or IDX or whatever you like. I think if I recall my basic ASCII that text is 7 bits so it would require some special file functions to be added.
Anyway, that's my thoughts...
It's just the developers have said they prefer keeping POL as secure as possible.
Perhaps there could be a way to write 8 bit binary data to a TXT file then manually change the extension to MUL or IDX or whatever you like. I think if I recall my basic ASCII that text is 7 bits so it would require some special file functions to be added.
Anyway, that's my thoughts...
- MontuZ
- Forum Regular
- Posts: 338
- Joined: Fri Feb 10, 2006 8:08 am
- Location: Myrtle Beach, South Carolina
I didn't read everyone's post, sorry if this falls off topic. But I was stumbling along the beatin path of UO mul editing programs and found one that I fell in love with.
It's called MulEditor, http://www.runuo.com/forums/third-party ... ditor.html
It's got a really great map and static editor with a bunch of features that I wont bother to list. This is just a suggestion if you're looking for the easiest and fastest way to edit map and statics. At least IMO.
It's called MulEditor, http://www.runuo.com/forums/third-party ... ditor.html
It's got a really great map and static editor with a bunch of features that I wont bother to list. This is just a suggestion if you're looking for the easiest and fastest way to edit map and statics. At least IMO.
That's a mistakeI didn't read everyone's post
There are a lot of tools around to edit several muls. Muleditor, Mulbuilder, Mulpatcher, UOSir, WorldForge and a lot more. None of the tools are able
to edit on the fly. Only RunUO has this ability, cause it has an internal binary reader/writer. And each tool has a lot disadvantages. Mostly time, cause you have to look at the coordinates first (8x8 old statics and so on)
If you could see the envirionment you could script it. If you know what i mean. Which i think is not the case. If it comes to UOKR it even will be more important. There are no tools yet but there could be.
The big advantages of an integrated freeze/melt tool is that you can actually update houses and dungeons and all the non terrain items on a semi-regular basis IF you have a client updating package for players to get the changes.
At the moment when I want to fix a bug in the map (eg a world builder put a house wall in the wrong location and it got frozen to statics before anyone noticed) I need to use UOSIR to remove the old one, and use Shinigami's item exporter to make a cfg file. Then I freeze the cfg file using WorldForge. So far it works fine but 096 made it more complex because after that we now have to rebuild the realms on the server. Of course we still have to make sure the players have the new statics but I don't expect the core to be involved in that.
Having an integrated freezer/melter won't change the client side of things of course but there are client patching systems available that will solve that problem. What the integrated pol freeze/melter could do would be to edit the realms directory on the fly and then do a resync or restart. This of course makes the original mul files different from the realms directories so we can't use uoconvert any more, so we need an external utilitiy that takes the realms directory and rebuilds the maps and statics. ie a reverse uoconvert.
A lot of work, but the results would be a very flexible way of making changes to the map, statics and items.
At the moment when I want to fix a bug in the map (eg a world builder put a house wall in the wrong location and it got frozen to statics before anyone noticed) I need to use UOSIR to remove the old one, and use Shinigami's item exporter to make a cfg file. Then I freeze the cfg file using WorldForge. So far it works fine but 096 made it more complex because after that we now have to rebuild the realms on the server. Of course we still have to make sure the players have the new statics but I don't expect the core to be involved in that.
Having an integrated freezer/melter won't change the client side of things of course but there are client patching systems available that will solve that problem. What the integrated pol freeze/melter could do would be to edit the realms directory on the fly and then do a resync or restart. This of course makes the original mul files different from the realms directories so we can't use uoconvert any more, so we need an external utilitiy that takes the realms directory and rebuilds the maps and statics. ie a reverse uoconvert.
A lot of work, but the results would be a very flexible way of making changes to the map, statics and items.
- MontuZ
- Forum Regular
- Posts: 338
- Joined: Fri Feb 10, 2006 8:08 am
- Location: Myrtle Beach, South Carolina
I don't know what you guys use to do this stuff, but that program is just a suggestion if you wish to get things done a lot faster than those other programs will. There's no need for building in POL then extracting to a cfg file. You just have to load it, open the map editor, scroll(or goto) the spot you want to build at, start building, save. run uoconvert. If you guys have a simpler way of static/map editing than that, please do share, lol.
I'm with you guys, I agree this would be nice to have for small quick fixes. But it wouldn't bother me if they said they're never going to do it because it can be done just as easily with another program.
I'm with you guys, I agree this would be nice to have for small quick fixes. But it wouldn't bother me if they said they're never going to do it because it can be done just as easily with another program.
Ah, we just got used to doing world building inside the game.
To me uoconvert is the bad step especially if you have a remote site. Those directories get pretty huge and you can't replace them when pol is runnning.
I know it's been talked about before, but we've done without freeze/melt in the core for so long that we've forgotten how useful it could be to make changes.
To me uoconvert is the bad step especially if you have a remote site. Those directories get pretty huge and you can't replace them when pol is runnning.
I know it's been talked about before, but we've done without freeze/melt in the core for so long that we've forgotten how useful it could be to make changes.
There is no need to be condescending. It's just a wish. Noone said the devs have to do this. And yes i have a simpler way to do static/map editing. Even to convert maps to the new uokr format. But all that is an export from pol in another format and than running pearl scripts to do the mul (binary) stuff. That's way to complicated for most users. And because i like it simple i would like to do that in a one step customized way. Which i think is a lot easier. And you can customize it further in your own scripts or by changing existing scripts.If you guys have a simpler way of static/map editing than that, please do share, lol.
I don't know how much work this would be for the devs. I only know that such a binary reader/writer is part of the .net framework. Don't know what that means for the linux core.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
I know what Pierce is talking about and to be honest I do like the idea of being able to do InGame statics editing. My daughter was working on a RunUO shard and she was explaining that she could do InGame worldbuilding and then the shard admin simply froze the changes to the map. To me this sounds like it would allow easier world building. Not only that but this would allow concurrent development on the map by several different people.
To be honest I have considered setting up a RunUO server just for this very purpose but I don't know exactly which utilities I'd need and frankly I don't want to learn a whole new set of emu commands.
So all that being said, this is a very nice idea. If there is some way to do it and maintain reasonable file security.
To be honest I have considered setting up a RunUO server just for this very purpose but I don't know exactly which utilities I'd need and frankly I don't want to learn a whole new set of emu commands.
So all that being said, this is a very nice idea. If there is some way to do it and maintain reasonable file security.
Yes that my problem too. But for simple things you can build normally on pol and use thisTo be honest I have considered setting up a RunUO server just for this very purpose but I don't know exactly which utilities I'd need and frankly I don't want to learn a whole new set of emu commands.
http://forums.polserver.com/ftopic817.php
converter to import an area from items.txt and then [freeze or [freezemap the area you want. But this can simply end up in a chaos, if more people work on a project for several obvious reasons
- MontuZ
- Forum Regular
- Posts: 338
- Joined: Fri Feb 10, 2006 8:08 am
- Location: Myrtle Beach, South Carolina
Yukiko: If you already haven't seen this, http://www.aksdb.de/CentrED/
Check it out, might be useful.
Check it out, might be useful.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
I have looked at the CentrEd server once. I think it was right after it was posted on Ryandor's site and if it does allow concurrent editing by staff that is a step in the right direction.
The main issue about using outside programs to edit maps is the learning curve. However if you can do InGame editing of static with the same commands you use to place dynamic items then there's no learning curve for staff.
And I do understand the argument that says "Why should we add that functionality to POL when there are other utilities with which to do it?" I really do understand but if we want to attract users to POL doesn't it make sense to have utilities that integrate these and other useful (and desired) functions with the emulator?
I don't understand why this idea is so easily discounted.
The main issue about using outside programs to edit maps is the learning curve. However if you can do InGame editing of static with the same commands you use to place dynamic items then there's no learning curve for staff.
And I do understand the argument that says "Why should we add that functionality to POL when there are other utilities with which to do it?" I really do understand but if we want to attract users to POL doesn't it make sense to have utilities that integrate these and other useful (and desired) functions with the emulator?
I don't understand why this idea is so easily discounted.
We just need to corner and bribe a POL core developer to get interested in the newer OSI features. With the RUNUO sourcecode and the POL sourcecode, what could be simpler? (/me looks for an emoticon to convey my ignorant optimism, but fails.)
With some alarming signs that core developers current and future may not necessarily all be beer drinkers, this may become more difficult.
With some alarming signs that core developers current and future may not necessarily all be beer drinkers, this may become more difficult.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
OldNGrey what we need is to get Anthony Soprano to use POL and then we'd see some improvement.
*grins*
But seriously functionality like this among other things is why "that other emulator" gained such momentum. POL excels in its internal versatility from a scripting standpoint but it lacks some in the area of external versatility and utility.
Anyway, this will probvably not happen soon but it is something worth looking into I think.
*grins*
But seriously functionality like this among other things is why "that other emulator" gained such momentum. POL excels in its internal versatility from a scripting standpoint but it lacks some in the area of external versatility and utility.
Anyway, this will probvably not happen soon but it is something worth looking into I think.