Latest on .agn file format

[Guest artmartin]

Okay, made some major strides in deciphering the .agn file format last night. For buildings inserted in Annotator that are aligned vertically and horizontally, I am now able to fully recreate their locations relative to my image in my new autogen editing program. I ran into a major roadblock however when those buildings have been drawn at an angle. The starting point of the rectangle is easily identified, the sine and cosine of the angle the user chooses to go from point 1 to point 2 is easily read from the agn file, and the final two byte sets that supposedly contain the point 3 coordinates or offsets are also easily read. Here's the information I'm missing though. I tried every combination of those numbers, adding, subtracting, multiplying, dividing, etc to try to derive at least one more point on the rectangle and have failed every time. The simplest explanation would be that the agn file is, through some easy math manipulation, supplying you with the third point of the rectangle after the starting point is known and you could easily deduce the other corners from that information knowing the angle of the slant of the primary side of the rectangle. Nope, not so lucky here. With the horizontally aligned rectangle, you simply added or subtracted the contents of the point 3 X and Y offsets depending on the alignment shown in the middle 2 byte sets and you had your third point coordinates. So one would assume that, with diagonally aligned boxes, they'd use the same technique, except use the vector amounts in the form of sin and cos values to multiply by the offsets to get the final X and Y values of the third point. Not a chance. Tonight I'm going to try some other trig ratios derived from those values to see if I can get a match. If those don't work, I'm at a standstill.Anyone have an inside connection on the Microsoft FS development team that we could get an explanation? Ha!Another interesting note. Annotator claims that, based on how one draws the house rectangle on the screen, the user defines where the front of the building is placed. The output agn file doesn't seem to indicate this to be the case. Let's say I create a house by holding down the mouse, drawing a vertical line to the right, and extruding the box upwards. The resulting box shows the bottom line highlited to indicate the front of the building you just created. Were I to to do the same thing but extrude the box downward, the highlite would show on the top of the box. However, when you look at the entries to the agn file for the two boxes you just made, the entries (other than their corner point info) are exactly the same in regards to their X and Y point 2 vector info (1, 0). In both cases, the point 1 X and Y coordinates are the upper left point and the point 3 X and Y coordinates are the lower right point. I haven't tested to see if FS truly does care about where the user puts the front of the building but if it's being saved, I can't tell where.Art Martin

[LuisFelizTirado 33]

Hello Art,This is really great work that you are doing. Congratulations.Maybe you might consider adding further comments to the same thread, instead of starting a new one every time. This will facilitate searches for this topic in the future.As for the "front" of the house, I had not noticed that there were different sides in houses, although I do not spend a lot of time examining the autogen buildings. If you look at the texture sheets, there would seem to be only one side per building depicted, and this makes me believe that they all show the same texture on all 4 sides.Best regards.Luis

[Guest artmartin]

Luis, I would prefer to keep things within the same topic but, in a forum where new topics come in quickly, your topic can quickly move off the page. This is a topic that's going to only catch the attention of very specific people and the fresher you can keep it the better I would think. I also think psychologically that when people see someone constantly replying to themselves they tend to pass it by as well. I certainly will keep them together in the future if it bothers anyone. I'm not at home with all my programming and reference material but my impression about a front side of the structure I think comes from documentation that came along with the Annotator program and you can clearly see a different line style on the side of the box you begin with when you place a house. In my own experience I've never really cared since filling the ground is my first and foremost goal anyway. If people are flying low enough to figure out what side's the front, they may as well be driving cars. Those kinds of details however worry me a bit when you start to look at the actual data inside the agn file. There are clearly a couple of byte groups that nobody has deciphered yet and just maybe these "missing" details are contained in them. Thanks for the reply,Art

[LuisFelizTirado 33]

Hello Art,There is certainly no bother to anybody - this is our forum and we can do what we wish, within the limits established by Tom. However, everytime you or someone else replies to this post, it moves to the very top of the forum and becomes the very first topic! So, it will never go off the first page if you keep adding your developments here. And we shall never get bored by monologues of people discovering new information or taking Flight Simulator scenery to its limits, have no worry about that.Often the documentation in the S.D.K. is incomplete or reflects planned developments. Perhaps the comment about a "front" is just more evidence of the (excessive?) ambition of the FS Team.Best regards.Luis

[Guest flightsimstudios]

Hey Art,Keep up the good work... If you can figure out how they get the trees to fade in you'll have my attention even more!!! :)Also if you discover a way to create a tree area that is non square you'd make my year ;)Dean...

[Guest artmartin]

Dean, spent much of last night working on exactly that - non-square tree areas. Very easy to program the code required to define the area. What I found the tough part to be was creating the squares within the selected area that best fill the possible shapes. Started out with logic that found the geographic center of the shape based on the farthest left, farthest right, top, and bottom screen positions and then slowing expanding a box until it hit an edge. Once I had the center rectangle I was going to try to fill in the other holes in a similar manner. Well, that seemed to work but it was dog slow and required huge amounts of code to do the work. It became obvious to me that method was doomed so I went with another try. I created an 8 X 8 grid of small boxes across the defined area and within each box, looked for the existance of points that made up the area. If I found one, I excluded the box from consideration. Initially this worked pretty well but included boxes totally outside the shape. Next step was that any boxes on the outer 2 or so rows of the grid I defaulted to bad and then did a search outward for any points of the defined area. If I found any then I brought that box back into the good designation. After that, I was left with good defined boxes only inside the center of my defined area with the boxes that hit the perimeter shown as bad. Next step was to see if those outer boxes could be redefined by shrinking them down to make them stay within the boundaries. That's where I left off. That logic is very tricky since one has to treat a box on the right side of the area different from one near the top. I'll also want to write some code that combines boxes near the center to cut down the number of square vegetation areas I have to create.None of the rules you set up work perfectly if your defined area has grossly exaggerated shapes to it. To save the number of points I have to save when defining the shape, I wrote code that only saves a new point if there's a change in both the x and y direction which can trip you up in the area evaluation later if you end up with a long span that might not have a point above, below, or to the side of a box you want to evaluation. Now for the completion list. Code is done for defining new house boxes that are aligned horizontally and vertically using the standard method of a button push to mark one corner, dragging to the opposite corner, and letting go to set the rectangle. Another button is for creating angled houses, same first steps to create a rectangular box but when you release the button, mouse movements rotate the rectangle. Pressing the mouse button again sets the angle. Another button is for creating multiple houses in a row. You set a narrow rectangle using the same method as a squared off house and then go back and click back into that rectangle to set a distance from your inital first point to set the width of the houses you want created. The computer automatically creates a row of spaced houses across your rectangle at the selected width. This works equally well for rectangles you define going across or up and down. Future versions might also allow for an angled rectangle to be defined but that would be much trickier creating the individual houses. This should speed up tremendously creating the hundreds of houses needed to really define an area such as a housing development.I'll get a screenshot of my progress completed in the next day or so and let you see it. Man, this has been a great refresher course on graphics programming and trigonometry. In my own job as a programmer in the transportation industry, we as programmers have been reduced from creative analysts to simple code and data mechanics as the moronic government we work for pushes for more and more off-the-shelf software packages and shuts down in-house development. It's a breath of fresh air to play like this and feel once again that artistic side I always loved about programming. Too bad the fun stuff doesn't pay the bills.Art Martin