Jump to content


Commercial Member
  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Varmint007

  • Rank

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
  • Virtual Airlines
  1. He's not talking about dual core "support", nor is he spreading "misinformation". YOU misinterpreted his comments. He's talking about the inherent efficiency of the newer architecture. Cycle for cycle, the Core2 processors smoke the older P4s, and he's 100% correct in saying a 2.4Ghz Core2 (using even a single core) will be faster than a 3.2Ghz P4. Cycle for cycle, these processors perform many more operations than their predecessors and they do it far cooler as well. --Jon
  2. I would have suggested AvHistory.org as it was a rich source of information for many years. Unfortunately it recently came under the gun of a "facelift" and apparently they saw fit to completely hose all the old topics. I honestly wish that was a punishable crime...I do not believe there's an archive of that information, so the next best thing I can recommend is that you take a look at some of the information Herve has on his site: http://pagesperso-orange.fr/hsors/index.html
  3. I'm not sure if you ever actually got the solution to your DME question, but this should work for what you're trying to do while still avoiding unnecessary conditionals.(A:NAV DME:2, nmiles) (A:NAV DME:1, nmiles) (A:SELECTED DME, enum) 2 == ? If the selected DME is 2, it will choose the top (former) value, otherwise it will choose the latter. Of course this only works for 2 possible values.If you had a series of values you needed to check, you could use the case structure:(A:NAV DME:3, nmiles) (A:NAV DME:2, nmiles) (A:NAV DME:1, nmiles) 3 (A:SELECTED DME, enum) 1 - casecase is limited to a linear series between 0 and 23 (possibly 24), so the value you're checking against must conform to that (hence the 1 -).--Jon
  4. I can see right through this; You're just looking for a place to park the Enterprise because the airport fees are getting out of hand. Admit it!--Jon
  5. I'm also intrigued by this idea JeanLuc. I think it could certainly offer advantages unavailable in XML-only gauges.Like Tom, I'm a firm believer in the strengths and performance of XML gauges. These are commonly dismissed as being useful only for rudimentary gauges, and I strongly disagree with that. I probably have at least as much experience with them as anyone else, having used them since introduction in FS2002.With a little bit more flexibility in terms of C-->XML interaction (perhaps the ability to bypass C++ altogether for the novice) and 'compile' into .gau or .dll, I think it would be a far more attractive and flexible solution than conforming to the new bloated ACES syntax and converting to .spb. At least in terms of security.It may even be possible to extend the "real" XML syntax this way, thereby providing a means to perform GDI functions from XML scripts. What's lacking in XML now could be boosted/augmented into something resembling a robust graphics set. For example defining pen styles for polylines, or adding the ability to define start and end points dynamically.Anyway, I think it's a great idea, with a great number of possibilities...--Jon
  6. Wow, that's really looking superb! I guess next you'll have to start thinking about the flight model:-hang
  7. Ah thanks, Bill. I was actually working with FS9, but if there are ANY variables that do work, then that answers the major part of my question regarding the use of custom animations; they should work so long a they use "compatible" variables.Thanks,--Jon
  8. Hi,Well I'm actually asking about the level of customization possible by way of makemdlparts for multi-player. Do I HAVE to use l_aileron (stock animation with no keyframes and no makemdl code) in order to have it show up on another aircraft in MP.Or will this more flexible keyframed (A:Var version) work as well:blah...(A:AILERON LEFT DEFLECTION PCT,percent)0100..blahWhere as I KNOW that this will not work because it uses an L:Var.blah...(L:MY AILERON LEFT,percent)...blahIn a nutshell will custom parts and animations work in multi-player so long as they DON'T use L:vars?The reason I ask is because I have some complex animations (i.e. ailerons with hydraulic and spoileron mixing) set up and they don't work if passed L:vars. If they'll work in MP as custom animations but restricted to A:vars I can probably live with it, but I'm not sure they will? The only reason I'm posting this is because I don't have ready access to a multi-player testing.Anyways, appreciate any insight here...ThanksJon
  9. Quick question here, hoping I don't have to do a build to find out:Regarding multi-player and makemdl parts (FS9). Clearly custom variables do not work, but do ANY parts that are not STOCK animations work? For example will custom keyframed animations work as long as they only use simulation variables?Thanks!--Jon
  10. >BTW, as a useful "tip" for cleaning up a project from deleted>and unused Materials...>>Save your scene to an incremented file (use the "+" button>unless you have "Autoincrement" enabled), then click the "New">button to revert to an empty scene. "Merge" your saved scene>file into the empty scene, and only the "active & used">Materials will be present... ;)This brings up a long-standing problem I've always had with Gmax, but never found out how to cure; Is there any way to "re-map" material IDs globally? For example replace every material ID for every object using a given multi-material in the scene. I've got a multi-material using "deactivated" materials and I'd love to wipe those old materials, rearrange the existing slots, and then re-map all th IDs in the scene. Right now the only way I see to do that is on an object-by-object basis by going into sub-object, selecting all the faces by material ID and changing them - for every single object, one at a time. Since I've got such a large number of objects, it wouldn't be trivial. Is there something basic I've missed? Something that would simply allow you to reassign material IDs globally?Edit: A bit unrelated, but I've got a number of materials with specular maps which are just instances of the diffuse map. I seem to remember from way back that these "specular maps" were necessary (FS9) in order to have ANY specularity despite the fact that they're not really specularity maps, just diffuse maps assigned to that channel. I can't help thinking these may be responsible for consuming resources in FS. Are these really necessary and/or do they reduce performance in any way?Thanks,--Jon
  11. Hey Bill,>The "Mirror Tool" actually mirrors both the object and>the object's properties, including normals and animations. The>result is precisely what you'd see if you held the object in>front of a physical mirror.I understand what you're saying about the mirror tool "mirroring" the normals. But it's not "flipping" the normals (at least not in the viewport). Why then do they appear "flipped" (inverted) as well as mirrored once exported. For example if I were to take that same mirrored object and export it to pretty much any other 3D app, it would have correctly aligned normals. It just seems like a bug to me that they're exporting with their faces inverted when clearly they are not inverted in the scene. The animations I can completely understand, since, as you say, the axis is mirrored as well.>>Animations will also be destroyed by mirroring. Animations>>need to be done independently for each half, and there was>no>>solution for that (at least in FS9 compiles).>>That is not entirely accurate either. Perhaps you've not seen>my latest "mini-tutorial" posted at FFDS: All I can say is, I wish I'd seen it about 3 years ago when I was painstakingly doing it by hand:) I can remember scouring the internet for days wondering how this could possibly so...Anyway great tip, and I stand corrected (as usual).Cheers,Jon
  12. OK I'll try to shed some light here, but first I'm curious as to how you created a 140,000+ polygon model and are just now wondering why things don't work. Let me rephrase: Had you only just now tried to compile your model for the first time? If so, how can you create a model, especially one that large, without first having done dozens of compiles to see how things were progressing?What I'm trying to get at here, is why this issue just now cropping up for you. Unless you're using the term "create" loosely, and are really just having trouble getting an imported mesh to compile? Nothing wrong with that of course, but it just boggles my mind that you'd be asking these things now, having just "created" a 140,000 polygon model:) It's been a long time, but I personally wanted to see how things looked at LEAST after the first lowly 10,000 polygons or so...Generally when you're over budget on verticies, you'll get a log entry just as you described - index buffer too large. Why the model actually finished compiling I cannot say.Invisible faces aren't actually invisible if they're casting shadows. Their normals are likely inverted even though they may look perfectly normal in 3DS. This is (or at least was with makeMDL) a bug related to using the mirror tool (from the toolbar). How could this bug have existed for so long when clearly aircraft are so perfectly suited to mirroring? Ask MS. The solution is to use a mirror modifier instead, and apply at the sub-object level.Animations will also be destroyed by mirroring. Animations need to be done independently for each half, and there was no solution for that (at least in FS9 compiles).Cheers,--Jon
  13. I have known Ron now for about 4 years. I have worked with him extensively on our products and even flew down to Dallas a couple of years ago to meet with him.He was a very brilliant man and I considered him a great friend and colleague. I will miss him very much, and my deepest condolences go out to his friends and family.I also hope Avsim will consider a tribute of some kind (if they haven't already) to his exceptional body of work within our hobby. I can think of only a handful of individuals who have contributed so much.Go with the angels Ron, You'll be very much missed...--Jon Blum
  14. Yet another outstanding contribution, Bill. I'm sure it'll go a long way towards helping me (and others) with our FSX conversion(s). I've been dreading it, but I'm sure the process will be much smoother with the aid of your "road map".I really appreciate your efforts here! Thanks again,--Jon
  15. Now that's a cool project. Please keep us posted with how it's working out.
  • Create New...