Ryandor.com
https://ryandor.com/forum/

punts mapgenerator
https://ryandor.com/forum/viewtopic.php?f=4&t=2764		 Page 1 of 2
Author:  Stormcrow [ Sat Apr 22, 2006 2:52 pm ]
Post subject:  punts mapgenerator
New topic for prior discussion:

Well what exactly is the rough edges for?
Also does it generate statics other than coastlines? I have to recheck my scripts.
What else? Where are the errors it is having with the scripts? I'm sure I can fix them. Part of the problem I know is because of not being strict about using hex or decimal. In some places 1, in some the other, and in yet other places both. I'm partly to blame because I am used to doing things in hex and Rich had been using mostly decimal. He had it in his head that everything should be created using the various wizards he created but I argued strongly that the project would never be in a useable state at that rate and it is much faster for me to directly edit the xml files than it is to do things with a GUI. We also had some version mismatches, because there were things that I had working well before release that no longer work. I know he also slipped me a few downloads where he assured me he just changed 1 or 2 specific things in the core and nothing else and yet shit that worked perfectly the revision before were broken.
Author:  punt1959 [ Sat Apr 22, 2006 2:59 pm ]
Post subject:  Re: punts mapgenerator
Stormcrow wrote:
New topic for prior discussion:

Well what exactly is the rough edges for?

Roughedges "roughens" up coastlines, so it isnt just a stragith line.
Quote:
Also does it generate statics other than coastlines? I have to recheck my scripts.

if you enable it, yes it will generate statics (based on the scripts of course)

Quote:

What else? Where are the errors it is having with the scripts?

Yes, it is hex and decimal. The warning messages attemtp to tell you the obivous ones. Doesn't mean more aren't lurking. Again, it is attempting to maintain total compatibtlity with UOL, so it was whatever I figured UOL did, I attempted to recreate.


For Dian's question, the images are 8 bit, that the palette must match what is in UOL's data file for altitude and terrain xml files. The key is the index, not the color.

If one wants, we could move this over to WorldMaker's site, under map editing
Author:  Stormcrow [ Sat Apr 22, 2006 3:05 pm ]
Post subject: 
Oh, ok. I'll recompile after dinner. Going to have to take the old lady out to the movies as well, but I should have some time tonight and tomorrow to work more on this.

And Dian to answer your question, it requires 2 images using UOL's index. In a nutshell you could say UOL is a rewrite of Dragon using 2 images. You could say that of pretty much any program that takes an image and converts it into a UO map. While there may be more than 1 way to skin a cat, in the end what is important is that you skinned the cat.
Dragon in many ways isn't different from the programs that came before it (the standalone statics generators) it just does a lot more than they did. And so it is with UOL and so on and so forth.
Author:  punt1959 [ Sat Apr 22, 2006 7:05 pm ]
Post subject: 
mltplacer has been uploaded as well. So I believe one now has the complete suite again.

I believe we "could" continue this under the Map Making forum of worldmaker if we wanted to.
Author:  Stormcrow [ Sat Apr 22, 2006 9:27 pm ]
Post subject: 
Ok, now I got some real wierdness. It is compiling the map. All transitions are correct, including statics, but most of the base tiles are "unused". Very odd. Didn't throw any errors which means either A: I don't have the directory structure right and the statics aren't being parsed or B: It is the stuff that was added by people other than me that is throwing the errors. How complicated is the source code? Would I be able to pick out the paths and what files it is parsing by looking at it?
Author:  Stormcrow [ Sat Apr 22, 2006 10:04 pm ]
Post subject: 
Ok, when I ran it through with one of my old maps and the UOL 1 data (not 1.1) it worked pretty well. The UOL 1.1 data is full of errors and I can't get it to compile anything from there, but that may be a hosed up UOL installation.
Author:  punt1959 [ Sun Apr 23, 2006 6:01 am ]
Post subject: 
The data I use is:

data/system/terrain.xml
data/system/altitude.xml
data/transistions/common.xml
data/transitions/subdirectories*.*
data/statics/*.*
data/system/roughedge/leftrans.xml
data/system/roughedge/toptrans.xml
data/system/roughedge/cornertrans.xml

The last three need to be the files I have in the rar.

I believe I interpret it all as decimal. It is only when I find characters in the number, I give a warning and attempt to try hex. So clearly, if some are hex, but have no characters, I will read it as decimal.

I will acknowledge I had to make one change to compile on the new QT/mingw. I haven't flushed this fully out, but I don't think it should have made any difference. Just letting people be aware of another unknown. And of course, I have no idea if what I am using was the latest source. The fact it supports structure files, is a good sign.
Author:  Stormcrow [ Sun Apr 23, 2006 7:05 am ]
Post subject: 
Well your program is pretty much bulletproof. It doesn't seem to care what kind of garbage we throw at it. It says garbage in, garbage out and keeps on truckin.
Author:  punt1959 [ Sun Apr 23, 2006 7:22 am ]
Post subject: 
That is true in many cases actually.

For instance, if I find a terrain index in the image file, that has no corresponding in terrain.xml. I will continue one (recognizing that area will be bad).
Same is true for altitude.

I actually catch the error, so if it one would like to me stop, or do something with it, I can.


MapGenerator is a one pass system. It does everything a block at a time (and considers overlap for transistion resolution purposes).

This was one of the reasons I had to come up with a different solution for roughedges then UOL.

This approach will also have some affect on random statics. It means trees that take multiple statics, will never be placed on the block boundaries (for I cant fit them within the block). Same with the frequency calculations.

The exception to this, is structure files. They can cross block boundaries, because I know that ahead of time, so I can preprocess the structure into blocks, before I start.
Author:  Stormcrow [ Sun Apr 23, 2006 7:47 am ]
Post subject: 
Oh that's fantastic. It addresses the jungle trees problem and the like.

One thing for certain, we'll need our own rewrite of the other programs that make up UOL. The dataviewer first. Image and altitude map prep next. Then the rest.

Ok, just created a new test map and compiled it. Looks good in insideuo, statics and all. Loading it up in RUO now.
Author:  punt1959 [ Sun Apr 23, 2006 7:57 am ]
Post subject: 
Stormcrow wrote:
Ok, just created a new test map and compiled it. Looks good in insideuo, statics and all. Loading it up in RUO now.


If it is normal sizes, WorldMaker Map editor can view it as well *grin*

As for the other tools, that is fine. I am not versed in what they do. so will need a lot of patience and guidance. Recall, I dont actually play uo, and only did breifly. So I am not familar with the game much at all.
Author:  punt1959 [ Sun Apr 23, 2006 8:22 am ]
Post subject: 
Quote:
dataviewer first. Image and altitude


I have wondered about the image and altitude prep. They only create files that have a palette associated with them. Would it be more usefule, to be able to take a true color image, and assuming it used the colors (not index), convert them into proper eight bit images? That seems to be more useful.

But to just make an image(s) with a platte, is trival. If needed, that can be done.

Should it preload the files to set terrain/altitude?

I have no idea what the dataviewer does
Author:  Stormcrow [ Sun Apr 23, 2006 8:30 am ]
Post subject: 
Oh, yeah have to remember to check that out. Still trying to work out a directory structure.

I'm going to scrap 90% of the UOL 1.1 release because Irro, being the halfwit that he is can't follow simple directions made a mess out of the scripts (again!). I'm sure I've explained very clearly (and more than once) why some things transition from both sides and some do not. In all likelihood I am going to go back to my own pre-release scripts and then add in the ones I didn't do one at a time (or probably just make my own). Also the color and altitude tables I'm going to scrap, because I never liked how they were done in the first place. Probably add in a 5th altitude group, but I think the generation is controlled by the xml files so it shouldn't be something you need to recode around.

LOL. Do any programmers use their own programs? I suspect not or we wouldn't see some of the things we see out on the market.

Anyway the dataviewer lets you open up the terrain.xml and altitude.xml and lets you see the color assigned to a particular block, edit the associated values and (most importantly) generates the .aco and .act files (photoshop stuff). The altitude map prep tool is also very important, as you run it after you make your terrain map and it makes the altitude map into something you can actually work with.
Author:  Stormcrow [ Sun Apr 23, 2006 8:33 am ]
Post subject: 
A truecolor image while it would give you total control, would be a nightmare to work with. Just setting it up is awful. We need 256 colors for each terrain (-127 to 128 Z) and to try to produce any kind of color range that large that is distinguishable to the human eye is nearly impossible (not to mention you have to make sure it doesn't overlap any of your other color ranges)
Author:  punt1959 [ Sun Apr 23, 2006 8:36 am ]
Post subject: 
Stormcrow wrote:
Anyway the dataviewer lets you open up the terrain.xml and altitude.xml and lets you see the color assigned to a particular block, edit the associated values and (most importantly) generates the .aco and .act files (photoshop stuff). The altitude map prep tool is also very important, as you run it after you make your terrain map and it makes the altitude map into something you can actually work with.


Bear with me.
Dataviewer:
Displays the terrain name, and the corresponding color. Allows one to edit the color if they choose. I have no idea what the format of an .aco and .act file is, so will need a link or reference.
Image prep:
I dont understand how one uses the terrain map to get the altitude map. I don't see the corrleation. they appeared to be independent, other then by size. Is there an attribute in the terrain.xml that is a an initial altitude ?
Author:  Dev Viperrious [ Sun Apr 23, 2006 8:41 am ]
Post subject: 
Not that I have a clue what I'm talking about but why doesn't anyone use the default color groups from UO?

They would provide 100 times the possible combinations yet they would not be so overwhelming to work with.

Dev
Author:  Stormcrow [ Sun Apr 23, 2006 8:46 am ]
Post subject: 
Dev Viperrious wrote:
Not that I have a clue what I'm talking about but why doesn't anyone use the default color groups from UO?

They would provide 100 times the possible combinations yet they would not be so overwhelming to work with.

Dev


Who? Huh? What?
Default color groups from UO?
Please elaborate.
Author:  Stormcrow [ Sun Apr 23, 2006 9:02 am ]
Post subject: 
punt1959 wrote:
Bear with me.
Dataviewer:
Displays the terrain name, and the corresponding color. Allows one to edit the color if they choose. I have no idea what the format of an .aco and .act file is, so will need a link or reference.
Image prep:
I dont understand how one uses the terrain map to get the altitude map. I don't see the corrleation. they appeared to be independent, other then by size. Is there an attribute in the terrain.xml that is a an initial altitude ?


That might be a tough one. I know it took Rich a bit of figuring out how to generate the files. They are adobe index and palette files (the act is the index file for the image, and the aco is the swatch file). Basicly the dataviewer is a GUI for the terrain.xml and altitude.xml. I guess none of it is absolutely necessary. I generally edit the xml in editpad, I can manually create an aco and I can generate an act from that (I think, but I'm pretty sure because we had to do that for Dragon more or less). Mainly it is of concern to people who want to generate their own data sets, or just add in a terrain group or three but are afraid to dig into the xml.

Ok, for the altitude map. Well first we start with newmapimage.exe which generates 2 blank properly formated images for the terrain and altitude. So you go and draw your terrain map. Then you run altimageprep.exe which somehow references the terrain map and makes a copy of it into the altitude map, except that the terrains are all set into 4 groups. Water is a group, rock is a group, basic land, and other. This is done so that you have some clue what you are looking at when you are trying to make your altitude map. I can't find where you set those groups in the xml file and I suspect they are hardcoded.
Author:  punt1959 [ Sun Apr 23, 2006 9:08 am ]
Post subject: 
Ok, in terrain.xml, there is a base attribute. I never knew what that was for. I assume it is the groupID in Dataviewer (but no idea what it is used for).


In Altitude.xml, there is type, which is another one I don't know what it is used for. (for it duplicates). UNless it is documentation only
Author:  Stormcrow [ Sun Apr 23, 2006 9:08 am ]
Post subject: 
Dev, are you talking about using the hues.mul? :shock: That's brilliant!
Just how do we make it useable in photoshop (and then we have to remember the people who don't own photoshop) ? Hmmmmm...... :idea: feel like making a custom paint program punt? :twisted:
Author:  Stormcrow [ Sun Apr 23, 2006 9:13 am ]
Post subject: 
Well the groupid identifys which group the terrain is in. I don't remember if it was just a leftover or if there is something hardcoded in UOL that references it. Originally a lot more was hardcoded, I had to argue a lot with Rich to get him to put more into the xml, which now he is going to put back in the exe.

Ok, actually looking through them again more closely I think they are solely the position in the color index. The terrain has 2 because it is there in hex (I think for my reference) and then in decimal. The altitude only has it in decimal.
Author:  Stormcrow [ Sun Apr 23, 2006 9:39 am ]
Post subject: 
Ok, I also figured out why my UOL 1.0 statics wouldn't work but the 1.1 do, Rich changed the syntax in the file. Fixed that, also fixed the stuff that was left in hex. What I don't understand is where/how the statics are being called from within the program.
Author:  punt1959 [ Sun Apr 23, 2006 10:23 am ]
Post subject: 
If a TransInfo tag has a "File" attribute, it has random statics.
Author:  Stormcrow [ Sun Apr 23, 2006 10:33 am ]
Post subject: 
punt1959 wrote:
If a TransInfo tag has a "File" attribute, it has random statics.


Where is that stored?
Author:  punt1959 [ Sun Apr 23, 2006 10:43 am ]
Post subject: 
The file points to a file in the statics directory. Is that what you where asking?
Page 1 of 2 All times are UTC - 7 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/