Military AI Works

Tried some tests for Yuma, Kaneohe Bay, Meridian and Kingsville.
Just stay at the airport for 5-6 minutes.
Memory stable. Don't seem these sceneries are affected.

Giorgio

This topic tweaked a long forgotten memory.

You may not have a texture folder (empty or otherwise) with any landclass files as this will definately cause a memory leak.

Easiest way is to have a Scenery folder containing all the landclass files, but with no Texture folder.

MS was aware of the problem, but was supposedly unfixable.

Perhals a main MAIW_Landclass folder, with only a Scenery folder inside it?

Well it seems that out of an abundance of caution we should go with that or something else.

This may only affect certain types of landclass files that are compiled in certain ways. I say this because so far, my testing at Yuma reveals no memory leak at all and it has a landclass file in the custom folder.

But I guess from now on it would be better to be safe than sorry.

MIKE JG wrote:Well it seems that out of an abundance of caution we should go with that or something else.

This may only affect certain types of landclass files that are compiled in certain ways. I say this because so far, my testing at Yuma reveals no memory leak at all and it has a landclass file in the custom folder.

But I guess from now on it would be better to be safe than sorry.

Won't affect all landclass files, only ones that call a texture.

Theory is -
If a landclass.bgl calls a texure and it isn't in the associated texture folder it loads it from the main game texture folder.
BUT doesn't release the memory allocated for a load from the associated texture folder.
In effect using double the memory. Now mulitply this by all texture calls by the bgl file and you can see it soon mounts up.
By removing the local texture folder it doesnt allocate any memory for it, and instead loads directly from the game texture folder.

Ok, same problem at Hill AFB.
Resolved in the same way of Luke.

Giorgio

I knew there was a good reason for me having a Landclass scenery layer in my system (I just forgot about it).

Works fine now with the Luke AFB Landclass.bgl in the Landclass\scenery folder. Hill Landclass.bgl moved there also.

Regards

EDIT: Ok after some reading I now understand what's going on. Land Classification, "land class" not "landclass" according to the experts, really only is comprised of the terrain textures that go on top of the TEM, terrain elevation mesh. Things like airport backgrounds, roads, rivers, lakes are not considered land class, they are textured polygon shapes of one form or another.

The "land class" that I made for the Yuma package is not true land class after all. In the case of the Yuma scenery, it is a simple VTP2 polygon that is textured with one of the default land class textures. Even though that is probably not the correct way to do it, it seems to work ok. I would imagine that the land class texture that I chose for that polygon, probably does not change with the seasons like it should. It's the desert so there may not be seasonal changes in the first place. In that case, one would never notice that the texture was not changing with the seasons. I'll have to do some checking.

So basically it's another way of creating a change to the regular land class without actually altering the land class for that area. It is simply placing a textured polygon on top of the existing landclass. Since this method is not true land class, it is not subject to the memory leak issue.

That might explain why this issue is happening at some sceneries and not at others. Even if they are both meant to alter the land class in the area, if they use the land class feature in SBuilder to make the changes AND this file is then placed into the custom scenery folder, you will get the memory leak. However if the land class change is done as a VTP2 polygon that lays on top of the existing land class, the look will be the same but you will not get the memory leak issue.

Sorry about that guys, I had to make a quick move and am just now getting things out of the boxes. I guess I've never been in one place long enough to notice that memory issue. Mike has some good suggestions on how to handle this and I will make sure - going forward - that any landclass modifications are installed to a safe location. Again, my apologies and thanks to everyone for sticking with this and finding the cause of the problem.

MIKE JG wrote:EDIT: Ok after some reading I now understand what's going on. Land Classification, "land class" not "landclass" according to the experts, really only is comprised of the terrain textures that go on top of the TEM, terrain elevation mesh. Things like airport backgrounds, roads, rivers, lakes are not considered land class, they are textured polygon shapes of one form or another.

The "land class" that I made for the Yuma package is not true land class after all. In the case of the Yuma scenery, it is a simple VTP2 polygon that is textured with one of the default land class textures. Even though that is probably not the correct way to do it, it seems to work ok. I would imagine that the land class texture that I chose for that polygon, probably does not change with the seasons like it should. It's the desert so there may not be seasonal changes in the first place. In that case, one would never notice that the texture was not changing with the seasons. I'll have to do some checking.

So basically it's another way of creating a change to the regular land class without actually altering the land class for that area. It is simply placing a textured polygon on top of the existing landclass. Since this method is not true land class, it is not subject to the memory leak issue.

That might explain why this issue is happening at some sceneries and not at others. Even if they are both meant to alter the land class in the area, if they use the land class feature in SBuilder to make the changes AND this file is then placed into the custom scenery folder, you will get the memory leak. However if the land class change is done as a VTP2 polygon that lays on top of the existing land class, the look will be the same but you will not get the memory leak issue.

Sure I read somewhere that the memory leak issue can also affect VTP2 polys.
Only sure way to avoid it is to not have a Texture folder.

Seperate issue I found:

If you go through the "add or remove programs" feature on your system and try to uninstall ANY MAIW package, for some reason it always uninstalls the Luke Package. I stumbled upon it by accident when I was removing stuff and I accidently clicked on remove the Patrick AFB package and it asked "Are you sure you want to remove Luke AFB....?". I tried it with every other MAIW package in the add/remove programs list and it's the same thing.

....has anybody taken a look at this (the problem I posted above)??

It's starting to get very annoying.... (the problem, not you guys lol)

I'll send Barry a PM. He does the packaging.

Danny

Sorry got distracted easily done these days...

Yeah not sure what happened there. I dont include any UNINSTALLER in the package so will have to investigate and come back to you all!

Barry

Any luck so far??

First of all, please excuse me if this turns out to be a dumb question, but I noticed that there are a bunch of overlapping nodes on the MAIW_AF2_KLUF_CUSTOM.bgl included in the Luke package. Is this by design? I have attached a photo showing the nodes (located between the parking links and parking spots.

The overlapping nodes prevent connecting the parking links.

Please excuse me - Can't figure how to attach photo. Done it before but forgot how to.

Does this overlapping have something to do with 'drive through parking'?

Eli the nodes are done like that to prevent the aircraft from pushing back out of their parking spots. The push back feature is something MS put into the AI code to accommodate Airliner based AI. Military planes don't do push backs. But FS9 doesn't know that and wasn't programmed like that. So to prevent a military fighter like the F16s in the Luke package from pushing backwards out of their parking spots, we have to essentially break the taxi link behind the aircraft so that it does not push back.

As a designer I like to have the afcad look as realistic as possible. To me that means giving the taxi lines the look that they would normally have. But to do this and still include a break in the taxi link behind each aircraft, you have to get a bit creative and overlap the parking nodes on purpose so that in game, the taxi line appears to be unbroken, even though it really is.

Hope that makes sense.

Thanks Mike. Knew there was a reason. Makes sense.

I run AFX abnd there is a drop down in parking properties that allows the choice for no push back, left, right or both.

By the way, I run FSX.

Jumpshot724 wrote:....has anybody taken a look at this (the problem I posted above)??

It's starting to get very annoying.... (the problem, not you guys lol)

Joe,

I might have found the root of the problem, not sure yet, but just wanted to let you know the someone is looking into it.

eli wrote:Thanks Mike. Knew there was a reason. Makes sense.

I run AFX abnd there is a drop down in parking properties that allows the choice for no push back, left, right or both.

Hmm.....that's a nice feature. Does it work in FS9 as well? That might make me get AFX after all.

BTW, I found an even easier way to accomplish the same thing without putting all those extra nodes in there. So from now on, at least in my afcads, they won't have so many extra blue nodes floating around.