tkyler

Hello Bill. Textures are not usable across scenery packages. There are pretty good reasons for this though I can't recall what they are.....I only recall having a long conversation with Ben Supnik about it long ago. You can't have an object in one scenery package pointing/using a texture in another. "scenery package" in this context, of course, refers to a single folder underneath the "Custom scenery folder". Unfortunately, to use a texture from another location, you do have to copy the texture over as you discovered, but doing so might cause the texture to be loaded twice onto the video card. Whether or not it is loaded twice is dependent upon whether or not you have a library element in your scenery that also uses that texture. If you are only intersested in "on off" scenery for yourself...and not distributing it, then what you can do is go into the folder, "Resources > default scenery > airport scenery....and then create your own folder, "bill" and put all your objects in there. The "airport scenery" folder is basically it's own custom scenery folder and therefore any objects in there can use the textures in the texture folder. Now there's a caveat...if you create objects and put them somewhere under the airport scenery folder, then you must create library entries for each object as described earlier and put it in the 'library.txt' file in the airport scenery folder. This will make the object available in the WED resource browser...but of course this library.txt file will get altered at each x-plane update so you have to take precautions against this. This is why it really isn't suitable for distribution because you really can't expect folks to keep track of their own library.txt and cut and paste your entries after every update to make your scenery work. My suggestion Bill would be to create the aforementioned folder for yourself within 'aircraft scenery'...create your objects, refer to the textures in the 'textures' folder and then add library entries at the bottom of the library.txt file for each of these objects....and finally, after editing your library.txt file, duplicate it and call it something like, "bill_library.txt" so it won't get overwritten during updates......at which point you'd have to copy your entries from your backup to the new library.txt after the update. The library.txt file is growing constantly as I add new stuff to it, hence my suggestion to create a text file with only your library entries in it and copy it over to whatever the most current library.txt file is in the airport scenery folder. -Tom

So after some nagging...I got the guys to implement a "flashlight" feature for cold and dark starts at night where you need to find switches. When I was flying in the MU2, we'd always fly at night and basically break out the flashlight as soon as we crawled inside....makes sense to do it in XP. We have both red and white versions. It's pretty cool! Kudos to Ben and Chris Serio....those guys are something else! https://dl.dropbox.c.../Baron_58_1.mov Tom Kyler Laminar/IXEG

On some occasions Bill, there will be objects that LOOK like they're a collection of separate objects, when in reality, they are all one objects. As I recall, that hangar comes with some other pieces that just come with it..and is, unfortunately, the best we can offer at the moment. Are you referring particularly to the parking stuff?

Hey Bill. Peaked roofs are a no-go with facades. These roofs are created "on the fly" and it would be impossible to create a peaked roof and still maintain the flexibility of having users create their own shape. If a user decides to draw a hangar in the shape of a circle with a straight section, that would be a tough peaked roof indeed....so roofs on facades will have to stay flat. The height value in WED is not an absolute value. It simply takes your number and looks for the closest facade pieces to tht height. Facade heights are "hard created" in 3D so if I only create one height, then you only get one height no matter what you type in WED. Why is this? Well lets say if I have 15 facade pieces...and I want those pieces in 1/2 meter increments...say from 5m to 15m...that would be 20 height variations per piece...x 15 pieces..I'd have to create 300 pieces in Blender for that one hangar style. Create 4 more styles and that's 1500 pieces..for 5 hangars only. Start adding in some parking garages...more styles and the next thing you know, we're managing 10000 objects in a blender file and that gets to be cumbersome. The purpose of the library is to populate the default airports "more reasonably than FSX did"...and when the final implementation gets done, we will definitely see that. It isn't really designed for custom stuff. The more like reality you want to get, the more you will have to stray from the library objects when it comes to structures. They're there to help you fill in bits and pieces but not give you everything. Now over time, of course we'll continue to improve the flexibility and variety of the library so it indeed will grow...but for facades, roofs will remain flat. Tom Kyler

Sparker over at the org asked this question and since my posting rights are revoke over there, I'll answer it here. First, I could not agree with the statement more Bill....we need documentation and training and it is not an oversight, but simply waiting it's turn to be handled. We have a great idea for getting this underway, but as with anything it takes some time. We are currently working on the aircraft fleet, trying to get it consisent and cleaned up. The big thing we are waiting on for wanting users to make scenery is our automatic submission process through WED. If folks run off and make scenery that is a combination of their own work and the default library stuff, that can't be submitted and we would have quite a mess on our hands.Keep in mind that x-plane is still officially in beta and we are trying to get past that point. So once we get this feature into WED, we will make a very concerted effort to train folks in best practices. SOOOO, that being said, I will give you a "unapproved", "not sanctioned", and a "DO NOT DISTRIBUTE YOUR SCENERY OR IT WONT WORK" disclaimer. What I am about to explain for "extracting" objects from the AGPs is ONLY suitable for your own scenery. The reason it is so is because you must make a modification to a huge text file, "library.txt" and this is a file that is updated whenever you run the x-plane updater. This means that if you use this method, then run the updater, your changes will be lost and your scenery won't work...but there is a way around that also. We'll make a text file and put the entries in that file...and then copy it over to the library.txt file. Now here's the thing. WED purposely excludes objects that begin with a "com_" prefix. It was not always this way, this was added when were mid-way through the process of building objects for V10 and we had created and named lots of stuff. The problem was that I had LOTS of objects that were "components" using the 'com_' prefix that could NOT stand alone...and these iterms were cluttering the WED interface horribly. By excluding these objects from the list, a few objects like hangars that should be their own object got swept up in the cleanup pass. Now the good news, is that what I am about to suggest CAN be integrated into the official 'library.txt' file by us....but it will be a while as I really need to keep my head about me when I dive into those 3D files..and now I'm on planes. Now, refer to the picture of the folder structure. We are looking inside the folder XPlane > Resources > defaults_scenery > airport_scenery and here's what you can do for now. 1.) Open a fresh, empty plain text file...with nothing in it. 2.) In the empty text file, and for every "com_" OBJ that is part of an agp that you want to use by itself, you will create a line in your text file like this: EXPORT lib/My_OneOff_OBJs/my_category/my_object.obj Real/Path/to/object.obj Let's go over this line. First you have the directive "EXPORT" followed by a space. Next is the path you want to appear in WED followed by a space. It does not have to follow any naming standard...the only thing is that a slash equates to a "tree triangle" that you turn down in WED and is used for organizational purposes. Finally, after entering what we call the "virtual path", you then enter the real path to the object beginning with the folders listed in "airport scenery" folder. So lets see a real example. If I want a Small Gray Hangar only....and it is part of the AGP...I will write the following in my text file....note that neither the virual path nor the real path have any spaces in them..there are only two 'breaks' in the entire line. One after the word, "EXPORT" and one after the virtual path. EXPORT TomKyler/MyHangars/gray_hangar.obj Common_Elements/Hangars/objects/com_SmGrayHangar.obj THEN, I will save that text file and copy that one line to the BOTTOM of the text file called, "library.txt" shown in the image above. There are lots of files called "library.txt" in the x-plane folder, but we are concerned only with the one in this folder. This file is at the top of the "airport_scenery" folder. We copy it to the bottom simply because you are hand editing this file and it is wise to keep all your "non-official" stuff away from official stuff. Now the reason we write this line into a separate file instead of the library.txt file directly...is because IF we write something like 20 lines to build our own little WED library category...then the next time you update, that library.txt file will be wiped clean. By putting your entries into a text file separate from library.txt, it's nice and safe and when you update the next time, you can just copy and paste your entries to the bottom of the new library.txt file after the update. So here's what the library.txt file looks like for our example...(note the last line) ..and with that one line in there....launching WED brings up the following: So to recap. We are putting an entry in the library.txt file that maps a virtual path you see in WED, to a real path to an object in the airport scenery folder. The important thing to know is that your virtual path (after the word, EXPORT) can be anything BUT....BUT this virtual path must end with the suffix, ".obj", otherwise you won't see the entry in WED. Then you must type in the real path to the object where the first item in the path is a folder in the airport_scenery folder. Here's another example. EXPORT BillsCustomStuff/Towers/ModernTower.obj Modern_Airports/Control_Towers/objects/com_ModTwr2.obj Putting that line in the library.txt file will cause the category, "BillsCustomStuff" to appear in WED. You can verify it works when you see the preview of the object. OK, so this is a workaround and NOT officially sanctioned by Laminar. If you put something in WED and X-Plane can't find that object in the library.txt file....it can crash the sim on many occasions. Now say you make a nice scenery package and you want to distribute it eventually. Then what will happen in this case, is when we finally get around to separating these objects from the AGPs and making 'official' library.txt entries for them, you will have to go into your WED scenery and there is a text field there where you can change the name of the virutal path from your custom one that you make in this workaround to the "official" one we come up with in the future....so there is a recourse. Now if you decide to make an object with a component that doesn't stand alone very well...like an airconditioner unit with no building that it's attached to...well, your prospects for getting Laminar to support that is pretty low Hope this helps..use with caution! P.S. Bill, if you want to take the message back to the org, then Laminar will most definiitely get training out as soon as we can...we certainly won't ignore it and know how important it is.

Hey Chris. There's no breakdown of the art assets. Mostly just play around in the miscellaneous buildings section of the library and also the ramp stuff where there's new cargo elements. We plan to consolidate the assets as some point. When we started, the tools were new and best workflow practices weren't developed yet. We pretty much knew that we might get far along and have a handful to organize..but really had no choice. My facade building skills are much more advanced now and I plan to go back and clean up yet even more..and also develop some more. Once the beta run is over....I'll begin looking into documentation and training...though seems you're doing more than fine Chris! Tom

We're not even remotely there or thinking about that. The primary goal is to get the aircraft working as accurately as possible. Everything else on top of that related to "cool features" or convenience won't be addressed till well after the product is out, well - proven and stable.

no screenshots yet (because we won't show them..not because they don't exist) , but we are well into the process of developing separate CDUs and also separately controllable ESHI displays. How that integrates in to future collaborative simming I'm not quite sure, but we do have an open design with the possibility in mind. The EHSI features are just wonderful....like nothing I've ever experienced in flight simming. Currently we see no surprises, stumbles or bugs and things just rolling right along -Tom Kyler Laminar/IXEG P.S. Here's some fun for you cerebral types. See attached screenshot. Given the line segment from A to B....and with an aircraft position at point, C. What is the true course from north...to fly from point C....such that you will intercept the line segment A-B at an angle of 30 deg? Guesses no good....give us 3 decimal places! OK, maybe 2. Heck, I'll even take one. This is but one of the many relations we have to develop in order to provide real time flight path calculations.

Of course its impossible to question preferences. Some prefer blondes, some brunettes, some fast, some slow, etc...these are questions to which we can't really ask why. X-Pilot really cannot take original credit for that Steven ....this lesson has been taught for generations at our beloved org by the dear leaders long before x-pilot came along. A whole new generation of x-plane users are getting schooled on this lesson this very moment in the 757 thread over there. This is a development universal for the most part....but one thing rings true and that is work is getting done...every year sees stuff not offered the previous year.

Greg, I believe it is a young man named Tyler. I have yet to look at the docs but certainly will take a peak. I'm still slated to do tutorials and might be able to do that shortly. The library is getting a pretty hefty upgrade with V10.10 and KATL and that might be a good time for me to focus on the docs also. Tom

ah..that explains it. We were scratching our heads going, "I"m not sure what he means".. I said, "I think I know and then tossed out a response as best as I could make fit to your statement". It makes sense now...too funny! Tom

A paradigm here that is usually overlooked is in the area of "customization". When Austin says that aircraft functionality are preserved between versions, what he means are "planes designed within the bounds of plane maker design"...and unfortunately, these are relatively simple behaviors when weighed against an in-depth simulation of a specific aircraft. When a aircraft author implements a plugin to customize and aircraft, all bets are off as far as Austin is concerned and claims of "austin breaking things" just does not hold true. It would be more proper to say the aircraft author broke things by overriding x-plane in areas and it's to the authors to fix these..and that is where I find myself. As to TOBS point about promises....I agree with TOBS that promises should not be made; however, the market is just that way. On the one hand...best not to say anything while on the other, we have guys asking for updates. It's just the nature of the beast. I can understand how users would worry bout whether an aircraft they really want are going to "make it through"...so it's nice to get reassurance as vaporware is always a threat. All I can say is that as long as I am able to work on my stuff, I will keep working on my stuff. Yes I shift my priorities a bit as a family man, but my commitments to my projects don't wane. My current commitments are to the IXEG 737, the MU2 and some scenery work, all other projects I've posted about are "off the table"....and what I work on any given day between those three changes based on several factors. But no more promises from me. Tom Kyler Laminar / IXEG

It's simply a statement I made based on what I thought, nothing more or less. Happy doesn't dictate if a paint is good or bad. It either is or isn't. The inability to separate emotions from reality are what make me unhappy. Tom Kyler Laminar / IXEG

This is a dead end Joe...Nicola is not the problem and you know it.....and I know you know I know it. For over a year I've been minding my own business and out of the blue I get a email from your boss 3 days ago because of a "not org friendly" PM I sent to a user around 1.5 years ago who recently sent it to him. So your boss contacts me out of the blue on this 1.5 year old PM that really is a long dead topic to me (but one he assumed was recent)....dredges up the past with his big mouth, and then finishes the email exchange with "quit wasting my time" though he's the one who contacted me on a knee-jerk reaction. This is a mentality I cannot comprehend....there is either no accountability or no comprehension of accountability and both are deplorable. Sometimes, you guys seem like you would watch someone kick a dog...and then blame the dog when he bites in retaliation. Sometimes the antagonist deserves to be bit...and maybe one day he'll learn to quit kicking dogs. How about for once in pubic, one of you guys say, "hey boss, leave the dog alone!"

What can I say...THAT is a nice paint job on the B17

Seriously?.....tell me you didn't get banned for simply voting on an aircraft?.... Did org admin give you a reason in writing? Tom

No word on how the automatic submission is coming along. There's lot of things being worked on for V10.10 and I have no idea where on their plate that is. For my part at the moment, I am using KATL as a R&D airport to diversify the library pieces. I'm making new pieces all the time....mostly new facades as they're the most flexible. When KATL is finished (hopefully this week), then the next update will contain a lot of the new facades. I also have to write a blog on "thinking in facade" because using them is a bit different than just placing buildings, especially since there's not preview of those just yet. Anyhow...here's a screenshot of KATL using nothing but library pieces...no custom stuff whatsoever.... so any user with WED and XP could make this once these new pieces are distributed. Better than an empty airport anyhow. The intention is to get them in before 10.10 ships....but if not, then I'll push for a small patch update when the pieces are ready. There is lots of quality control to be done with the library pieces yet.

Chris and crew. Awesome effort here! Very nice to see the collaboration.

I could not say for sure. As a vendor, I see much more feedback than many on the forums here and sometimes it appears that many can be satisfied by taking a particular course of action when in reality, that is not the case. There are very large number of customers that very much want the MU2 to work with V10. Creating two separate versions is not very feasible unfortunately. I am truly sorry that the situation is the way it is, but also my experience shows that when it is done and done right, it will be worth the wait and also any criticisms endured then. Releasing a incomplete work will most assuredly cause many times the headaches than the current delay causes.

I really apologize. I was under that same assumption. Here's what happened. I generally test my work very very thoroughly in just about every situation and my updating the MU2 happened during the V9/V10 transition. The V9 version, the basis of most of my work worked very well, but the V10 version did not work well at all. The data at both Laminar and X-Aviation show that people are moving to V10 such that most everyone wants a version that works for V10. Saying that V10 "broke" my MU2 is not an accurate way to describe the situation. V10 improved areas of the engine model....areas that I had programmed around since V8. The engine model for V10, while improved, still does not simulate the MU2's Garretts exactly. So what this means is that I still need a custom solution for V10....and the one I used for V9 no longer works. So I have to basically "throw out" my old code and start over. This really wasn't known until I started V10 testing. Because the MU2 update was very close to release at the same time V10 was coming out, I didn't catch the problems until it was too late. I have assessed the MU2 in V10 and made a determination about the best tactic to take to fix it. The problem right now is that the fix involves new areas of coding strategy for me and a reasonably significant investment in time. Because I promised a free update (which I will honor), the recoup on investment of time isn't worth it at the moment. This does not mean that I will abandon it.....what it means is that I am at a critical cross-road in X-Plane growth and opportunity and where my time goes now will have a huge impact on where I'll go with x-plane add-ons in the future. Certainly I did not set out to deceive anyone on the MU2...it's just one of those things that happened as V10 came out. The MU2 is still my favorite aircraft and I will pursue it's development until it sits at the pinnacle of add-on quality..... and I will still honor the free update when I complete it. At this moment though, I must tend to other projects and priorities as my family is directly affected by these choices and they must come first. As an aside....the problem is the engine model. I need to override several ares of the engine and prop model and take control of them directly. My work with IXEG has proved to be absolutely invaluable in this regard and when I get the time, I will apply this knowledge to the MU2. I do crack it open occasionally...did so last week and am still auditing the code like a surgeon to know what to cut out and what to add in so as to not break something else. The absolute minute I know what code I can cut out without breaking other stuff...then that's when things will move. Cutting out code and causing a bug somewhere else really drags out the time...so I am pretty cautious at the moment. Tom

I'm sorry Oscar, you are way ahead of me on this one. Thus far, I've just been cranking out scenery and the ATC programmer has handled the ATC layouts for me (KSEA only so far). I am doing KATL now as an example of a "library only....no custom" airport and have yet to get to the ATC layout part; however, it is upcoming for me very soon and I will take your questions to the ATC programmer and see what I can dredge up...good questions all! Tom

E. yes, the prop locks are the feature where you have to put the power levers into reverse or else the props will feather. The code I wrote all those years ago were workarounds to the flight model...and at the time, my skills and experience wasn't as it is today (isn't that always the case). Anyhow....I pushed those techniques as far as I could and now they're just getting in my way. It's one of those things where I need to "go down to the studs" in order to do the remodel right....but for now, we'll throw on one more coat of paint.

I did some comprehensive testing the other day and have come up with a conclusion. I am going to remove some of the new engine features I put in for the update....these new feautures are what is causing the problems I am having. The thing is....these new features are ones that are not in the current MU2 and therefore, will not be missed. I am speaking of the prop locks. The prop locks are an integral part of real MU2 operation, pertaining to engine start and shut down procedures....however, given that 99% of one's time in X-Plane is probably NOT startup and shutdown, I can't see the logic in not releasing based on a feature nobody has ever used thus far anyhow...only because I want to be anal retentive. I will still have to rewrite some code, but not a comprehensive rewrite as would be required to implement the prop feature. In this way, folks can get the new 3D and a few other features like the ADF and such without having to wait for a little known feature. On another day in the future, I will rewrite the engine code to make it more realistic. As usual, no date on release; however, before the other day, I honestly didn't see it happening till late in the year...and that was unacceptable...so hence the decision to remove a very small feature in order to get this thing moving. I still think the quality level is 10 orders of magnitude higher than what is out there currrently and that is more than enough. I'll keep posting here as I work on it. Tom K

Sorry for the late reply....just noticed your post. Let's take a look at a object in the default library called, "Cargo_container_6.obj". This is a group of 6 generic cargo containers with a draped polygon ambient occlusion shadow underneath. The cargo containers themselves use one texture and the draped polygon with the baked AO uses another texture. First...we start with the header" TEXTURE ../textures/Common_Airport_Elements.png TEXTURE_NORMAL ../textures/Common_Airport_Elements_NML.png GLOBAL_specular 1.0 TEXTURE_LIT ../textures/Common_Airport_Elements_LIT.png TEXTURE_DRAPED ../textures/Draped_Ground_Elements.png TEXTURE_DRAPED_NORMAL 1.0 ../textures/Draped_Ground_Elements_NML.png EXPORT lib/airport/Ramp_Equipment/Cargo_Container_6.obj Ramp_Equipment/Cargo_Container_6.obj POINT_COUNTS 175 0 0 318 There is a lot going on there. But the pertinent stuff for draped polygon is "TEXTURE_DRAPED". That specifies the texture to be use for the draped polygon and "preps" the OBJ to use ATTR_draped. There is no reason it cannot be the same texture as the object itself......it just so happens I keep my draped texture separated for some optimiztion reasons that is too much detail to go into here. Now lets look at the commands at the bottom of the OBJ file: ATTR_LOD 0 500 # Image: //../textures/Common_Airport_Elements.png TRIS 0 312 ####_group DP_1 ATTR_draped # Image: //../textures/Draped_Ground_Elements.png TRIS 312 6 Ignore the # sound lines as those are comments only. The key here is to note that there are two sets of TRIS commands. The first set are the polygons themselves for the cargo...THEN we execute a "ATTR_draped" command. All TRIS commands after this command (assuming no ATTR_no_draped) will be "squashed" onto the ground. If you are going to hand edit the OBJ files, the trick for you is somehow being able to isolate the triangles when you export them so that you can identify which "TRIS" line in the text OBJ represents the draped polygons If you use Blender to export, you can assign the draped polygon to a group...and name the group something like...."zDraped_Polys"...at least for Blender 2.49. The blender exporter (for version 2.49) exports groups in alphabetical order which is why I precede my own group names with a z. In the example above though, I happen to use the group name, "DP_1" and you can see the exporter writes the group name to the OBJ file so it can be identified easily for hand editing. Now if you are using something other than 2.49 and the original "blender2xplane" scripts...like say the scripts developed on the org for version 2.6+...then I really don't know what features that exporter provides. TomK

Pretty cool Larry. Here's the fixed OBJ with the exhaust fixed. http://dl.dropbox.com/u/955680/FALCO_wings.obj.zip