 |
 |
|
|
| Author |
Message |
Pierce
Joined: 02 Feb 2006
Posts: 256
|
 Posted: Mon Apr 03, 2006 7:44 am Post subject: Integrated Static Tool |
 |
|
I'm just working on a custom map2 getting a little insane while doing so  I think most of us know that building maps and statics need a lot of patience and a lot of knowledge of several tools (UO Landscaper, World Forge, UOSIR, UOSP .........). Imho there is no tool to create or edit statics2.mul and staidx2.mul except for random creation with UO Landscaper or install RunUO and use the freeze function there (just read that). This is way to complicated i think.
Cause 96 has ListStatics* commands i thought about an easy to use a feature at least for statics to build, edit or delete staticsN.mul and staidxN.mul files. The file formats for these files are well known and i thought about writing a pearl script but if pol can do that for all map statics it would be a lot easier and we all can easily do that just using pol.
I think about commands like:
AddItemsToStaticsInBox(( x1,y1,z1, x2,y2,z2, flags := 0, realm := _DEFAULT_REALM );
AddItemsToStaticsOfTypeInBox(( x1,y1,z1, x2,y2,z2, objtype, flags := 0, realm := _DEFAULT_REALM );
DeleteStaticItemsInBox(( x1,y1,z1, x2,y2,z2, realm := _DEFAULT_REALM );
DeleteStaticItemsOfTypeInBox(( x1,y1,z1, x2,y2,z2, objtype, realm := _DEFAULT_REALM );
Flags could be:
const IGNORE_Z := ??;
const IGNORE_DOORS := ??;
const IGNORE_INVIS_ITEMS := ??;
Just to mention the most important operations.
Pol could rebuild the staidxN.mul and staticsN.mul then and save it e.g. as newstaidxN.mul and newstaticsN.mul into the mul directory.
If that is possible, it could save a lot of time in world building. You only need to uoconvert the new files and restart the server to check your work. |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
| Posted: Wed Apr 05, 2006 11:14 am Post subject: |
|
|
| Tritan wrote: | | With Windows, if the file is in use changes can not be saved to them. That is why the restart would be required. At least that is what I have heard in the past. |
That's actually not technically true - a program can choose what sort of lock to request on a file, and the operating system can grant or not grant that type of lock.
With that said, it is typical when a program must have constant access to a file which it expects never to change, that it requests a lock that prevents writing to the file. This is usually because changes in some part of the file could cause program errors due to the program making assumptions about what else it read from the file before - which may have changed in the interim.
I haven't tested it myself, but my understanding is that POL096 doesn't lock -ANY- of the mul files at all, since it's actually not reading them at all.
But the configs that it produces, which it has to read from time to time - POL typically does not lock them at all ever, except for the momentary locks when it actually is writing to them. This demonstrates what I said above: It's up to the program to lock or not lock, depending on how it uses the file in question. (of course, it's also likely POL doesn't keep those files open, but just opens them right when it needs them - but I still don't believe it locks the files at all while reading, as you would expect errors if you were editing a config file at the same time POL read from it, but I've never seen such an error)
ALL of that said... I think I would have to vote against including such features into POL, for two reasons:
One: The tools to do this are already out there, so why waste POL dev time (which is already so extremely limited) working on reinventing the wheel?
Two: I really don't want my production server clogged up with code for this sort of thing. Even if the above objection were made moot by a sudden influx of more dev team time than needed to accomplish the more important things that need to be done for POL, I would still object to this unless it were possible to configure POL not even to load the code which does this... as a dynamically loaded module, for example. |
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
MontuZ
Distro Developer
Joined: 10 Feb 2006
Posts: 293
Location: Myrtle Beach, South Carolina
|
| Posted: Wed Apr 05, 2006 9:57 pm Post subject: |
|
|
Marilla I totally understand you'd rather have the devs bust out all the bugs. But this is a Feature suggestion. It doesn't really help pol, but it helps the users. That's what Features do. Atleast from my point of view, which to you is apperently very wrong. 
What you're basically saying is that you'd rather; cmd<coords/target> the item(s) you want static into a cfg, copy/paste the cfg, load up a program, burn the statics, etc.
Sphere/RunUO(One of the two) has it(I think) and no this isn't Sphere/RunUO. But you have to admit, it's a nice Feature for an emulator. And knowing you, you probably will still object to it/never agree to it even if we had the developers.
That's all I'm going to say, Anti-Feature.  Rawr. |
|
|
|
|
|
|
