A simple tool like uoconvert would also be great. I suggest that as pol commands cause you could ask the gamemasters building around. And if they are ready you use these commands to build the new statics and pol will delete the found items to build a new static file from the items.txt.
The possibility of coordination in world building on pol would be better.
I surely don't now if this is much code to swell the core. But these functions won't be called often (i think) to cause lag on a live shard.

If we could have only one new feature for 97, I would definately give my voice for this one. The new core is very stable (not a single crash after RC3 was released, absolutely great job!), so it would be good timing to try something new.

Currently updating statics with pol and external tools contains too much simplistic work that should be handled automaticly. Desroying one or two items in statics is plainly said painful operation. Only the server can give the best support for statics editing, especially when there are multiple builders.

Is there perhaps someone who played around with the RunUO type of files? I installed that server and played around with statics on the ilshenar map. It's very easy to change the statics on RunUO on every map. I can realtime delete or add statics there. The .mul is changed immediatly.
The only function i like on RunUO. So i tried to take a look if i can write a converter from item.txt to the RunUO type of handling of items. But that are 3 files, that are not purely text: items.bin, items.idx,items.tbd.
So it's not the easy way to convert. Does anyone else also take a look into this already?

This is very high on my wish list, for the next POL release.

Shame on me, i forget the language POL is written. Was it C++?
If so, it could be a simple thing if one takes a look into the statics.cs command of runuo.

The last three days i played around with runuo a little bit, without any knowledge of c++. The only thing that was interesting for me was the extremly fast method to change the static files cause it tooks too much time to use uosir, uosp or anything else ... And they don't work on maps like ilshenar, malas ...

So i tried too make a runuo 1.0 command that reads the 96/97 items.txt of Pol. After biting 2 days in my keyboard cause of no real idea how C++ works i managed the command on day 3. So far a test command.
I coded it so we could read in the items.txt this way:

command x1 y1 x2 y2 mapid

The command will read every item within these ranges on the choosen map to runuo. I did a test with a 23 MB items.txt without creating items. It took about 2-3 min. to go through that file size on runuo. Perhaps it can be faster, i am new to c++ as i said

The creating also works. I test it with a small range with 10 test items.
I will do some further test with some structures i like to place on the ilshenar map and therefor i tried this in first place.

If these tests are successful, i will post this command here.

Nevertheless i hope this will be a feature of POL, cause i hate to use 20 different programs and copy around data to reach my goal

My vote goes for a "simple" single function

ItemToStatics(itemref);

which copies the item to the right statics file according to the map it belongs to.
No need to delete the dynamic item, it can be done with another instruction
No need to add another command to delete in an area, it can be done in scripts
Any other login can be added in script, one single command which just copies 1 item to statics would be easy and powerful
there also is no need to autorun uoconvert and update the at runtime the server data about statics movement validation and such, it can be done turning the server off and doing it manually running uoconvert by command line
Having the ability to code a script which converts to statics the buildings but leaves the doors in dynamic would be great, and you can think of a lot of other examples where this could be very usefull.

Are you sure?
If the statics on whatever Map is changed, you need to run uoconvert again.

Of course, you have to
- shutdown the server
- run uoconvert
- give new statics to clients
- restart the server

What I meant is that, imho, there's no need for a complex modification to the server in order to add a StaticsConvert() function which lets us runuoconvert by scripts without having to shutdown and restart the server, because I think it would be a complex modification for the devs and not as useful as the ItemToStatics(itemref) itself. Do you agree?

Hard to say if i agree to that. I convert my items to RunUo and freeze it there to the .mul files. My wish stays as i stated in my first post in this topic to save this in my opinion useless export to runuo. And therefor force their only advantage over Pol.

I use a RunUO server to build my towns for the same reason
And also because noone ever coded (it's a cat who bites its tail) a tool like UO Architect for POL

I do admit that the one thing that I like about RunUO, and it's the only thing, is that you don't need to run a conversion on the files. Atleast you didn't the last time I used it anyway.

For the record I use Punts Worldmaker Map Editor for editing statics but like you said Lagoon ya still have to UOConvert it afterwards.

would be sweet to see commands like that

The first time I saw the RunUO .admin command and the ability to unfreeze and freeze map statics together with UO Architect to make templates of items and move them around smoothly, I was totally convinced it was the way to decorate and edit the world. I am guessing that those two things - rewriting statics on the fly and the OSI housing system (like dynamic multis) are THE two features that RunUO has that we will always miss in POL. From what I read, a lot of POL shard developers are using RunUO to work on their world. Even if the features were available in POL we would still have to write the utilities to make use of them.

Pandora's box has me intruiged too, so I am even contemplating writing some pol scripts to emulate runuo commands - like incx etc. I know I can edit the xml files to change the commands in a lot of cases, but it interests me that I could distribute some scripts that would allow pandora's box to work unmodified. Of course RunTest could finish his utility first!

I would love to see a way to do map modification in POL, personally.

Someone above said they didn't like the fact that we have to run UOConvert before a map is usable- the goal with that was to divorce ourselves from explicitly using UO's maps and map formats. POL can use pretty much any map format... so long as the format had an associated MapConvert program that turned its data into what POL can read. The problem with this is it has never been taken advantage of, as far as I know. The problem there is that there's insufficient advantage to bothering to take advantage of it. But that's why it's there- so if someone someday wanted to use POL to create a game totally unaffiliated with UO, they would not have to use UO's data formats to make it work.

My apologies for the boring history lesson for those who were aware of all of the above.

Madman,

Are the POL map data file formats documented anywhere?

Would it be possible to create a module (*.em) with functions that allow manipulation of the POL map datafiles and possibly a conversion function to convert those newly modified data files back into *.mul files for the UO client? This seems like something that might be feasible at least. I was thinking someone could script an InGame editor calling these new functions and when the editing is done call the 'convert' function and have the mul files generated. The only issue I can see with 'real-time' editing is the terrain. Does the client dynamically update an area once it is in its display window? In other words if I was InGame and raised a mountain a few Zs would the client update that on screen? Can POL send map info to the client dynamically and have it "see" it? Since I have only glanced at the packet docs I am ignorant on that issue.

Statics editing would not face this issue ofcourse as static items are handled differently and get "frozen" from dynamically placed art tiles. But it would be nice to have this ability internalized with some EM functions if possible. As long as I am on the subject, the scripts for static editing could easily be made to only freeze items with a custom property that indicated they are to be frozen. In this way existing maps on active shards could be edited right on the working shard without having placed dynamic items frozen as statics.

I would like to reduce my wish for that feature a little bit, because it was over
2 years ago i had it.
Meanwhile i scripted a lot of tools like a multi.mul builder, a statics mul builder and
a custom map/statics to UOKR facet converter etc. These tools are always a combination
of a pol and a perl script.
There is only one simple thing that Pol is missing and i could rescript the Perl part into
a 100% pure pol script. And that is the lack of a binary reader/writer, cause i use the
perl script mainly for that reason.

These are the perl commands i can't simulate with a pol script cause they use
binary mode not text mode.


I don't know if the cfgfile.em and datafile.em commands use the StreamReader/Writer object from the .NET framework, but i think so.
If that's the case it could perhaps be simple to add the binary Reader/Writer object.

http://www.genprogrammers.com/forum_posts.asp?TID=306

I think 4 commands/methods would be needed (an example):

var binaryfile := OpenBinaryFile(filename);
Opens the binary file if exists or creates a new one.

CloseBinaryFile(filename);
This one is perhaps not really needed.

binaryfile.ReadBytes(position, number of bytes);
Read the number of bytes from the given position.

binaryfile.WriteBytes(bytes);
Append the bytes to the binary file.

Therefor i always write a completly new e.g. static file from the start i think
the append function would be enough. In this case you don't have any
garbage in your new mul files, like with most mul editors around atm.

I think these 3-4 commands could make life a lot easier, at least for people
like me who don't like to work with several different tools when there could
be one that does all

This thread is leaping about and quite intruiging!
I'd like to pick up on the uoconvert utility and the realms directory.

Two things:
1. there is a file that is always open in each of the realms directories. Makes it tough to copy and work with it when pol is running.
2. you still need to write out maps and statics files in mul format somehow otherwise your players can't get the maps. So we need a uo-unconvert.exe utility I guess.

Coincidentally enough, I added a BinaryWriteFile to my working copy of POL098beta this last weekend. It mimics the format format of the normal WriteFile, and its slightly hokey due to the lack of a BYTE and WORD datatypes. However, by packing information into DWORD (Integer), double (Real), and strings, it works perfectly well.

After reading your suggestions, and talking to Madman, it seems that a better step would be to work on editing POL files directly, and writing a re-converter to turn them back into MUL format for redistribution to players.

Hm... no promises, but I'm going to put a little thought into this. Its certainly not impossible. Might take another weekend of work...

Luth,

I would still advocate for it to be done as functions in a new EM, maybe mul.em that would provide conversion, static freeze and melt (for those who wish to remove statics) and terrain modification functions. This way a tool could be scripted to take advantage of the functions and allow customization by each shard owner to their liking.

Oh and no fair you getting to play with POL 0.98 beta!
*sulks and sticks out tongue at you*

Why not make the same functionality like packets (.set/getint8/16/32/....)?
Also i see no need to limit it to mul files, maybe someone wants to write/read bmp files

Turley: Because I needed a multi exporter to write MLT files from in-game, and copy/paste functionality was the quickest way possible. I've already decided that my additions will not be committed. Its too... unwieldy. No average scripter would be comfortable using it. If I were to commit a Binary Writer, it would be in lines with what you're expecting.

Yuki: I think a polfile.em to read/write POL's data files sounds like a good idea. Of course, I'm going to have to talk to everyone else and learn a bit more about the core's data system before I even begin to promise such a thing. Just because it sounds like a good idea doesn't mean it is one.

Damn, i started to convert the Perl scripts to Pol after your post yesterday,
at least the parts that not handle the binary part. It seems i cheered too
soon
Does this mean Pol will not have the possibility to read/write binary files or
only that Luth does not want his functionality to be in, because it is
a bit uncomfortable?

I mean that my implementation will not be added. I see no reason why a binary file writer should not be included, but the way I had done it originally was just terribly ugly. Here's a section of my multi exporter:


No normal user would want to do all that. Instead, I think a function-set including the likes of { Write8, Write16, Write32, Write64, and WriteString } would be much more beneficial. I would be perfectly happy to commit that.

I'm still merging my changes from the end of 097 (the ones that didn't get committed) to 098. I'll try to write a good Binary File Writer as well.

I honestly don't know, and I've promised Luth I'll try to find out. I mean, they can be reverse engineered from the uoconvert source code, but that's no fun.

Luth said:


Ofcourse it's a good idea, it was mine wasn't it? ; )