Varmint007

Umm, no, not "whatever." We have approximately 11,000+ forum users and somewhere around 15,000 topics related to the Superbug. Please link me to a single topic discussing this alleged issue with unrealistic "ground effect" behavior, as surely it must be very prolific and prominent based on your description. Have you personally posted to this issue in our forums? Are you actually a customer? Jon Blum VRS

Thank you Jimmy:) It's not often people go out of their way to write something positive like that. You get a lot of the negative/neutral stuff, primarily because people are forced to post when they need help, coupled with the fact that it's a very comples simulation. So it's always a nice surprise when the positive stuff appears organically outside of our support forums. Glad you're enjoying it! --Jon VRS

A friend of mine working at MS Game Studios has passed along this horrible piece of news, which I have not seen posted yet, so unfortunately I will pass it along.Steve Lacey has died this afternoon in Kirkland from what appears to be a road-rage incident. RIP Steve and thank you for being an incredibly influential and important figure in our hobby.http://www.king5.com/news/Road-rage-suspected-in-fatal-Kirkland-crash-126093229.html

OK, sorry but I can't help myself. You mean the Torrent version from April of last year of course, because if you actually owned the product that would be an impossible statement to make. Please don't comment on our products when you steal them, because you have no idea what you're talking about. The Superbug is NOTHING BUT inertia when it's unlicensed, which you clearly are. The FBW system is completely offline and you couldn't run the aircraft manager with and electric can opener. Welcome to the Pirate Bay - everything is as it seems, right?

Mapping through FSUIPC is fine, in fact I do it that way myself. But you've got to use the FSUIPC option: "Send to FS as Normal Axis", or else we're never going to see them. Thanks to the FSUIPC interface, you can do this on an aircraft-specific basis as well, so there's no need to do it globally.

OK, I'm sorry, but that's simply not true. We have personally answered EVERY support question that's been posted to us in our forums, and yes, the forums are working fine: http://forums.vrsimulations.com/forums/phpBB3/index.phpEmail? We have answered every single one despite having lost 2 days moving to a brand new server.If you post your problem it will be addressed almost immediately, but that means you have to ask the question first. We cannot offer you support here on Avsim, so please go to our forums and you will be taken care of.

Absolutely stunning gentlemen. The runway outlining/lead-in stuff looks like it was especially challenging to hash out, but MAN that looks useful. Really really fine work there!

We had previous been obscurely developing Everlasting Gob Stoppers, so it's no wonder you hadn't heard of us.Vertical Reality Simulationshttp://www.vrsimulations.com

Actually I didn't realize that until you mentioned it. It seems the thumbnail images are classified as attachments and thus weren't visible to non registered users. I've reset the permissions and they should be viewable by all now...http://www.vrsimulations.com/forums/phpBB3...?f=1&t=2071Cheers and thanks,

Silly, but necessary. And it's not for registering, it's for forum access. We were besieged by board bots over the last month and we had to put a stop to it. Mathematical Q&As were tried first with little success (the board spam software can figure that out even easier than captcha). I finally settled on something that would be impossible to answer without human intervention and it's working very well. Inconvenient perhaps, but so is sorting through a hundred porn posts:(

Wow, thanks for all the great comments everyone! It's really humbling and inspiring to read them.Ben, thanks again for such a wonderful and thorough review. I'm really happy that Avsim visitors will finally get the opportunity to understand what we're offering.Ryan, what can I say. PMDG was my inspiration to develop for MSFS, and it probably wouldn't have happened without you guys to show me where the bar was.Cheers and thanks again everyone.

I have a question regarding the FSX view system. I've been unable to find a way to override the default "Cockpit" and Virtual Cockpit" cameras. Is this even possible? I can of course add additional camera definitions that have the desired view parameters, but it seems a bit unreasonable to ask the user to activate a second view just to override the (wrong) default views.In FS9 (panel.cfg) we had: VIEW_FORWARD_WINDOWS=VIEW_FORWARD_DIR=VIEW_FORWARD_ZOOM=VIEW_FORWARD_EYE=The zoom and eye allowed us to override the settings on a panel-by-panel basis. Exactly what I needed and wanted in order to correctly adjust for those running under different aspect ratios and to calibrate the 2D cockpit to the VC.The latter of these entries are now completely disregarded in favor of camera definitions as far as I can tell? If that is the case then why is it you can't define cameras at the panel.cfg level. Why must they be defined in the aircraft.cfg, and why can't you completely override the "Cockpit" and "Virtual Cockpit" views short of actually changing them globally?Unless I'm missing something horribly obvious, this actually seems much less flexible than FS9 was. Sure I can have some belly cam if I want, but I would prefer to actually have control over my PRIMARY views. All it seems you can do is define the global eyepoint. Offsets, Pitch and zoom (for VC AND 2D) seem to require a camera definition and even in that case they can't override the primary views.It seems I've formed this as more of a rant than a question, but I'd love for somebody to tell me I'm wrong:)

Congrats Bill! Yeah, the speed of MakeMdl was the first really impressive difference I noticed when upgrading from a P4. Build times went from "go make a pot of coffee (and wait for it to finish)", to "pour a cup of coffee". Absolutely amazing.--Jon

What's interesting here is that my girlfriend (same house, totally different email) got one of these in addition to myself. Now that's just scary. She's never purchased a flight simulator product in her life. We're going to try to find out where she's been, but generally she's not registered for any flight sim sites that I know of.

Well just to follow up, I've narrowed it down to the normal map. As far as I can tell, and I really hope I can find a solution, if any VC material contains a normal map and a vclight.fx of any radius or color is turned on, you'll get the result in the center image above. Only the diffuse texture is output and it will no longer shade in any way, instead appearing washed out and completely flat.I've tried a sample test with a number of builds and the result is always the same regardless of the blending mode. Normal map + VClight = FUBAR :(

Right, that was something I tried right away, but unfortunately didn't solve the real problem which is why the specular maps are being tossed out the window when the vclight.fx comes on. If you look at the holes for the screws for example, you can see that everything is a uniform wash and the specular mapping is just not "on" any more. Conversely if a material has no specular map at all it's not affected by the vc light at all.I'm really surprised nobody has mentioned a problem with vclight.fx in FSX before. Maybe I'm just missing something painfully obvious (it's been known to happen!), but something is definitely broken here. All maps including specular and bump work just fine until you hit that damned cabin light. --Jon

Hi Bill,Yessir, I have no specular (for the lamps) and I even have "Ignore Background Specular" disabled. I think I've found a way around the problem by carefully adjusting the lightmap for that material. You see, the annunciator lamps aren't gauge maps at all. They're polygons which are shown/hidden with code. So instead of basically having a copy of the diffuse color in the night map, I went with a much less saturated version to compensate, and it seems to work ok, although not nearly as well as it did in FS9 by forcing the material not to shade (or get brighter). In FS9 the lamps were totally unaffected by ambient light after hacking up the ASMs. (which was wonderful).Unfortunately now I have yet another problem I don't understand. As you can see in the images, the center image is completely washed out by the vclight.fx. And I'm not talking about overall brightness, but the fact that the entire specular map for those materials is being ignored when this effect comes on. I have explicitly disabled background specular. So this begs the question, how are dome/cabin lights and the like actually working in FSX? Of course I could use night maps to simulate the wash, but I would like to have the entire cockpit light up without loosing all my specular maps! Do you know what's behind this?Thanks again,--Jon

Hello again Bill. Actually, I FUBARed my question. I should have said I was looking for a mode that doesn't do anythingto the texture, essentially leaving it alone in shade or light. Yes, additive works great for making things bright, but in fact that's the problem; things get TOO bright once the material is combined with the ambient light. Do you know if final render alpha or any other setting can cap or attenuate the final "combined" result of additive?Thanks again for your always helpful advice.--Jon

I'm wondering if it's possible in Gmax (FSX) to configure an emissive (non-gauge) material with self-illumination so that it simply doesn't shade? While emissive, every blending mode I've tried results in some form of shading, becoming brighter or darker based on VC attitude relative to the sun. I know it's possible with gauge materials, but I would like to apply it to non-gauge materials as well.In FS9 I did this by editing the material properties of the .X file before compiling externally with BGLC_9. But I'll be damned if I see a way to do it through the Gmax material properties?Thanks,--Jon

Hmm, maybe it's similar in quirkiness to the if{ 1 } els{ 0 } - sometimes it works, sometimes it doesn't? I do have a LOT of code in there, so it's possible a hair was out of place someplace else, but I can't think of what else I might have done to "fix" it.Anyway, I've got my kid gloves on now and I'll see if there's enough room between the fingers to cross them while I'm at it:)

OK! Looks like it's sorted out.For some bizarre reason code within <Code> tags like this:<Code>Some code</Code>Was not parsing (probably throwing a syntax error without any feedback). But this works:<Code>Some code</Code>It seems without the line breaks, and only in the case of a visibility structure, it wasn't working. The really strange part is there ARE example <Code>somecode</Code> structures in the default modeldef.xml, but it seems they only exist in that form (on the same line) when they're part of a containing animation and not a visibility-only.Gotta love the quirks :(, and thanks for your help Bill!Edit: I'll also bear in mind what you said about explicitly adding if{ } els{ } to the boolean code. It's hard to accept superfluous things like that since they're so inefficient when used by the hundreds, but lesson learned.--Jon

Hi Bill!Right, I think I understand the differences pretty well now (GUID required for animations, none for visibility alone, etc.). And as you say, the only "guaranteed" value for an L:Var is zero, which is why it's driving me nuts trying to understand why some part would be visible under any circumstances once tagged with a value I know to be zero. Indeed, I've even tried explicitly using a zero value "0" in the the <Code> elements and the part still shows up! Again, it's like it's not tagged at all or somehow the tags aren't being compiled.Is there any way (using Gmax) to examine the X file? It looks like it goes stright to .MDL and you can only get access to the .X file if you use the 3DS exporter. Do you know if I'm right about that?Thanks my friend,--Jon

Hey guys,I've got some strange things going on in a Gmax project that I just can't figure out. I'm just now getting into the FSX (acceleration) SDK, and the differences from FS9 in terms of modeldef.xml seem easy enough. It seems like I've figured out the whole attachpoint/animation manager paradigm and I can get custom animations to work as expected. The trouble I'm having is with visibility attachpoints.I define the visibility condition in modeldef.xml <PartInfo><name>some_visibility_label</name><Visibility><Parameter><Code>(L:some custom variable, bool)</Code></Parameter></Visibility></PartInfo> In Gmax:I select an object, then select the attachpoint tool.some_visibility_label appears in the list of visibility items.I choose it and press attach to selected geometryI then do a properties on the object and confirm the userdefined entry for the visibility condition.Compile the model.When run, the object is always visible, as if the visibility attachment never stuck.Now I'm no noob to XML and FS9. I've been doing it for 5 years, so I know when XML code is well formed or not, and my visibility code is also fine (at the very least an object would be INvisible if that was incorrect). My problem must be with not understanding how to properly tag an object, although I'm doing exactly what the SDK says to do.In fact I have an animation which has visibility associated with it: <PartInfo><Name>some_animated_part</Name><AnimLength>100</AnimLength><Visibility><Parameter><Code>some_visibility_condition</Code></Parameter></Visibility><Animation><Parameter><Code>some_animation_code</Code><lag>30</lag></Parameter></Animation></PartInfo> That visibility condition shows up (and WORKS) just fine when using the attachtool. So what is it about attaching visibility elements by themselves? They don't have a GUID associated with them that I can see from the sample modeldef. They show up in the list, the code is well formed, yet once you attach them they have no effect. So here are a couple questions that are killin' me!:1) Why would an object which has been tagged with visibility and is confirmed to have been tagged by verifying it through the object properties, ALWAYS appear after having been compiled? At the very least one would expect that A) The visibility "object" must be well formed in order to show up in the attachtool visibility list at all, and B), even if the <code> was incorrect (which it's not), the object would default to NOT appearing because the resultant value would always be 0. Again, I know the XML is well-formed and I know the code is correct. I have even tried simple "0" or "1". The visibility tag isn't sticking to the object after compiling.2) What is the purpose of the Attach Name field? The SDK says nothing about it and it always produces the same value (undefined_6) after tagging. Even if I type something in there it invariably appends _6!. Where is this used and why?3) What is the purpose of the Create New Attach Point! button? Again, simply not in the SDK and despite repeated trials, I can't figure out what that option does.Thanks guys, I'm just stumped on these. --Jon

Wow, I remember that one.Only, I think I'd want to precalulate EVERYTHING in there.For example: (A:Plane heading degrees gyro, radians) pi 6 / 0 * - /-/ :( Becomes: (A:Plane heading degrees gyro, radians) /-/ :( --Jon