The download hangar is currently disabled. We're doing our best to bring it back as soon as possible.
Luke AFB package by MAIW
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?
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.
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 G.
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Won't affect all landclass files, only ones that call a texture.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.
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.
- petebramley
- MAIW Developer
- Posts: 1529
- Joined: 17 Jun 2007, 16:05
- Version: P3D
- Location: EGBG
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.
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.
-Mike G.
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
-
- MAIW Veteran
- Posts: 159
- Joined: 30 Apr 2007, 01:52
- Version: FS9
- Location: Los Angeles, California
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.
Sure I read somewhere that the memory leak issue can also affect VTP2 polys.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.
Only sure way to avoid it is to not have a Texture folder.
- Jumpshot724
- Major
- Posts: 767
- Joined: 16 Feb 2008, 20:20
- Version: FS9
- Location: New York, USA
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.
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.
-Joe W.
"I love the smell of jetfuel in the morning....smells like VICTORY!!"
"I love the smell of jetfuel in the morning....smells like VICTORY!!"
- Jumpshot724
- Major
- Posts: 767
- Joined: 16 Feb 2008, 20:20
- Version: FS9
- Location: New York, USA
- Jumpshot724
- Major
- Posts: 767
- Joined: 16 Feb 2008, 20:20
- Version: FS9
- Location: New York, USA
Overlapping Nodes
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'?
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.
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.
-Mike G.
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Joe,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)
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.
Last edited by MIKE JG on 09 Feb 2009, 18:32, edited 1 time in total.
-Mike G.
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Hmm.....that's a nice feature. Does it work in FS9 as well? That might make me get AFX after all.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.
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.
-Mike G.
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log
Recovering flight sim addict, constant lurker.
Check out my real life RV-8 build here: RV-8 Builder Log