-
Posts
2,818 -
Joined
-
Last visited
-
Days Won
577
Content Type
Profiles
Forums
Latest X-Plane & Community News
Events
Downloads
Store
Everything posted by tkyler
-
I see his Ben's points, but the rheotoric does seem unusually heated today. When I started the MU2, one of the primary goals was to show the FSX community what x-plane can do. Exposure is never bad, this is the way..you MUST sell your wares, you must throw them in front of people, most will not come looking. We need regular simmers and we need impulse buyers to put enough money in our pocket to make it to the next and better product and so on and so on. Besides, Pete doesn't strike me as a guy who does this to leech freeware. There was a quote I read in a book and I can't remember who said it that said, "Conversation is king...content is just something to talk about" and if Froogle is conversing about x-plane, then there is nothing bad that come come from that IMO. As far as these customers being "far away", they're actually only one sale away. I know a lot of folks who came to x-plane when the MU2 came out....you get converts one person at a time. I'm all for getting in front of as many FSX folks as we can. I have plans to teach folks x-plane in a new way but we need the audience. TomK
- 78 replies
-
- 12
-
I downloaded and dumped it 6...count it, "SIX" times before I finaly stuck with it. I would not describe blender as unnecessarily complicated because anything you don't know how to do can be labeled as such, but what is lacking is decent information and communication about it and how to get things done and where the pitfalls are. There is a lot to take in so posts are a difficult way to convey the potential pitfalls along the road. In 2014, I hope to start a comprehensive training program on developing for x-plane and through videos and blogs, provide step by step information on how to do things. While Dan has provided his great aircraft series, its a narrow range of information he covers and all the pitfalls are not discussed, nor advanced techniques. I reallly want to make it my mission to get folks having fun developing for x-plane. If you use the blender 2.4 series, then you need to use the Blender 2.49b version. You can find it by googling for older blender installations. If you use this older version of blender, then its probable you must have an older version of python installed on your system, like Python 2.7. It is entirely possible than blender 2.49b will not work with the newest versions of Python. If you have multiple versions of python installed on your systems or you have a newer version only, then there is probably some magic dance you have to do to get the older system on there and TELL your system which version of python you have to use....indeed these are the initial headaches. I've been working on the older version of pythong 2.7 for a while now...I know this works with blender 2.49b. Once you get the proper versions of blender and python installed, then you have to obtain the proper scripts and locate them in the proper place. This is different on windows than it is on mac...and furthermore, you have the ability to set a path in blender to point it to the scripts so really...while there is a "proper place" for scripts...technically, you can leave the blender2xplane scripts anywhere you want and point blender to it through its preferences pane, which can confuse things a bit more. There are lots of buttons to push and lots of things to check along the way which is why a post is not a good way to convey. A video would be better and I promise one day I'll have one. The next "surprise" might be that after you get these scripts installed and try to import stuff, you'll find that these old scripts do NOT support a lot of the newer commands that OBJ files have so the script will 'choke' when trying to import objects....and in those cases, you have to go into the OBJ text file and strip out the lines causing blender to choke. For simple mesh objects that do not have complex animations though, the import usually goes fine. The final surprise is that when you do an import, the mesh is imported relative to blender's 3D cursor position, so if the cursor is NOT at the 0, 0, 0 position, then the mesh will import in the wrong location and when you export it back out to replace whatever it is you were trying to improve, then it will be in the wrong spot....and on and on it goes. Liser has a good summary above....and will work if none of a few potential "gotchas" crop up but you can address those on a case by case if needed. TomK
-
AJ. There are, no doubt, areas of the Saab that cause "frame rate hits".....one component being the new sound engine; however, my little bitty mac i3 with 512MB video card, even with the unoptimal code can get 10-11 fps, not quite single digits. So I think there is a line here somewhat between your "single digits" frame rates vs. everybody else who reports frame rate hits. Agreed that many see frame rate hits so you're not crazy there, but what you are describing does seem to be in a class by itself given your hardware description and inconclusive as to whether such a hit is "Saab only" since most everybody else doesn't quite get hit as bad as you describe...indeed a mystery currently. Also agreed that the 'next step' is to wait for the update to see what the effect is on your machine. The sound code has been reworked and we've seen vast improvements on several machines already so I'd guess you'd see some improvement there...but can't say for sure if that will solve all your ills. This type of troubleshooting is usually a "one step at a time" approach. TomK
-
I myself would like to, but its one of those things that we'd save for the very last and see how it goes. Its just a bit more mesh work, and one of those things we'll look at later and if the mesh rework doesn't bring up any surprises, we'll slip it in. Just know that we have no objection to having that option. We're inclined to simply provide a preference that will toggle the windows "on or off" as it were. TomK
-
This is a quick "where are we". There are some aspects to projects that are slow to get past. This occurs generally when you do not have the proper information, or proper reference photograph in order to do a task...so you kind of "guess" and if its wrong, then you have to redo and redo and it bogs down quick. For a while now, I have been chipping on the flap animation. The team is super-picky about visual realism and trying to animate the flaps such that everything looks and works and you have no mesh collisions or overlaps, especially in the super-tight tolerance areas of the flaps has been a real challenge. I've walked away more than once. If the flaps aren't right, then you can't do the mechanisms right and all this stuff is visible when the flaps are deployed so if you want to get it right you have to build it right. Well I am happy to report than the flaps have been "substantially" done. This means all the surfaces, fore/mid/aft flap have all been animated and their motion is such that the mechanisms can now be animated and all the motions "jibe" with real mechanism properties...i.e. the hard part of the wings are done. What remains on the exterior is quickly coming to a close...some misc mechanisms to model and texture...some gear well stuff, a few odds and ends and finally the door animations. Inside we have the aft cockpit to texture, the aft galley to UV and texture and then we will be in '3D scrutiny' mode to see what we need to add, or re-UV map, increase or decrease in detail / resolution. That will substantially conclude the 3D. I keep using the word "substantially" because the work is never done...we touch up here and there, probably till the very end, but all the pieces are in place, no more difficulties remain etc. At that point, we'll go back to the programming and work on finishing up the FMS and begin testing all the systems in order to get ready for a beta test. Again, NO telling when this will be. We can see the end of the road, but aren't quite sure how far away it is. Getting pas the flaps was a big hurdle to jump. I'll include a work in progress screenshot below. Texturing on a lot of things is "quickie mode" and we'll be adding higher detail in the upcoming weeks. TomK
-
Indeed you must manage "roll trim" all the time, even with the AP on, including coming in for landing....the autopilot will attempt to level the airplane to counter any roll trim inputs. When approaching for landing, the torque is typically very low since the power levers are retarded, hence the roll tendency will be low, hence the roll trim input should be very low. If you mind the details, then turning off the AP will not be very eventful. A good rule of thumb...is when the autopilot is on, adjust the roll trim to keep the yoke relatively level. If the yoke is turned with the autopilot on, then too much roll trim will be the culprit. TomK
-
mabye.....but catching bugs "pre-customer" is something we specialize in I very much try to do things most customers won't even try....ever and put my code through a pretty hard wringer. We do expect hardware related bugs, possibly sound or graphics related....usability bugs, but as far as aircraft complexity or systems bugs....of course we will get a few, but not as many as folks my think IMO. Jan knows how to break stuff like nobody I've ever seen. TomK
-
We cannot really put a label on it that would mean anything. The 3D is nearing completion and the sounds are just amazing. it quite feels the most immersive thing I've ever experienced on the desktop in a flight simulator. I honestly believe this is something special. There are some unknowns that keep us from putting a label on the stage. I don't think we'll make it this year, we'll be close then, but not done. I think by years end though the product will be visually complete and look like a finished product and we will be in the last phase of tidying up the FMS system, unsure of how long that will take. Once that is done, we'll enter beta testing....but with the grand-daddy of all beta testers on our team, I don't think that might be terribly long. He beta-tests as we go. That's the best I have. We are closing up some holes in the work though in preparation for Jan to do some more movies showing the progress. I'd like to see that in the next few weeks. I'd say we're in the final phases for sure...but the final phase tends to be an unknown time-wise. TomK
-
Why is that Tom? don't take that the wrong way at all.....Consider it a marketing question...is the NG just "cooler" with the electronic displays? winglets? HUD? I'm curious what exactly it is about the NG that folks like. I myself like the NG's winglets and some of the VNAV info you get with the NG's EFIS system.....the cockpit is a bit "cleaner" looking too with some of the trim.....but the Classic has grown on me with its combo EFIS and steam gauges...more than I thought it would anyhow. TK
-
So one thing that is important to us at IXEG is that we try and get the interaction with the cockpit as realistic as we can..and still feel natural in feel, look, sound and operation. The flap lever in the 737 is gated...so in reality, you have to pull it up out of its gate, move it to another position and let it slip back into the new gated position. It has a very distinct motion and sound but at the same time, its a relatively smooth operation so the challenge was to recreate the motion / sound / feel in sim......and it has to work with both the mouse and default flap buttons (1 and 2 keys). The video below shows using the mouse manipulator followed by the default flap keystrokes. (11.2mb) https://dl.dropboxusercontent.com/u/955680/flapslever.mp4
-
We have very much considered many types of users, including beginners. We are endeavoring to provide a series of documentation and tutorials that will help ease folks into the complexity of the product and also get enjoyment out of it even without having to dig deep. We will not just be copying Boeings manual and our manual will be significantly less than 1000 pages . Jan's insight is extraordinary as is his delivery...he just has a way of explaining things and knowing what folks want to know that make it easy to understand and we are going to try and capture that in our docs. I envision other methods of teaching folks....I think teaching material can be entertainment in and of itself (think AoA media)....but of course this all takes time to develop and it is my thought that we'll probably see more training tutorials after the product is out and we can facilitate a nice delivery mechanism....but we are indeed thinking of the "complex simmer first timer"......After all, I am one myself. TomK
-
Ok....Here's a few in-progress shots just to feed the hungry and prove our time is well spent. We are texturing and adding detail in the cockpit and cabin. There is still some programming to be sewn up though so we've a few months yet...not sure how many and I won't say because I don't know. We move steadily and you can see form the exterior/interior shots we're are plodding along. We are absolutely insistent on maximum immersion visually and audibly and it just takes a while. Tom Kyler IXEG / Laminar
-
You certainly have that right and privelege and will judge products from that particular view....though I don't believe a majority share it. The things is....we hear from a lot more users than you do most likely. Sure you get a few in the forums here and there, but we get the emails you don't get and don't see...the private messages, etc and coming up short is just a "no-no" for most users. TomK
-
Because this view is the minority and you can do a lot of damage to your reputation. Most folks, when spending this kind of money expect it all to just work...no surprises, no gotchas....things need to look right, feel right, work right, work as expected, etc etc and that takes quite a while. We're very much in the details stage and for those who know the adage, "The devil (or God) is in the details", then you understand that this phase drags out a while....but is the phase that makes the difference. Its what you don't normally notice that has to be right. You guys will be glad we did! TomK
-
Agreed, but not that often. If all licenses are "used up", then yes, you can ask for another one though XA reserves the right of refusal. I've not seen any reasonable situation refused though, certainly we want customers to be happy and not inconvencienced....and by reasonable, I mean we're computer savvy geeks and pretty much know when licenses are being abused vs. bona-fide use cases that causes licensing issues....though we don't see as much of that now as we used to due to improvements in the system. Its not unlike iTunes authorization of machines.....its generous enough for normal, honest situations and the occasional "stuff happens" is infrequent enough that both a customer and XA can stand a email exchange to resolve the issue once every 2-3 years for the frequent "computer swapper"...which we know there are a few out there. TomK
-
ha....definitely got a laugh out of that. Thank you much Leglaude! My wife categorizes me today as "officially" over the hill. TomK
- 1 reply
-
- 1
-
Rene, there are several reasons why a remappped command might not work on a custom programmed add-on. The most likely reason is that a developer uses a custom dataref for a switch/button and executing a default command does not change their switch by default. It CAN be made to move a switch though in code and is the responsibility of the aircraft author to program in that type of functionality....it it not something you have control of as a user, the developer must provide the functionality for you. As an FYI, a developer has two options here, 1.) provide a custom command which you have to select or 2.) Re-write the default behavior of a default command to work their custom datarefs. Whichever they provide should be conveyed in their product documentation, especially if their methods/commands deviate from 'x-plane default' Tom Kyler
- 3 replies
-
- Keyboard shortcuts
- Keyboard
-
(and 2 more)
Tagged with:
-
Not part of the Saab team, but certainly deal with these two issues as a custom developer. These are somewhat "sore spots" for a developer for a few reasons. 1.) Custom sounds can't be "sped up" or "slowed" down in x-plane so in a replay situation, if a user selects anything other than normal forward speed, the sound will be off. In addition, replay mode is what Laminar calls a "limited mode" and several sources of data that are depended upon to program in additional accuracy aren't available in replay mode. Basically my personal opinion is that replay mode was/is cool....but was designed as a 'compliment' to the default aircraft and getting it to work consistently for highly customized aircraft is a decent sized problem in and of itself. One CAN program to allow for replay mode to a limited extent though the problem there is its a whole other programming paradigm that has to be added to the developer workload for little return. As a developer, you approach "replay mode programming" after the fact and add in "what you can"....its hit and miss to see what you can make work. My personal opinion for developers....at least at this stage of the x-plane game is to get these products on the market, get revenue going to better self-sustain and with the "funded time" then take closer looks at these replay and "mid-start" situations. Laminar's architecture works great with its simplified default aircraft, but these highly customized ones present new challenges that teams have to take looks at for the first time and generally end up trying to"reverse engineering" x-plane or engaging in conversations with Laminar. I'm sure the Saab team will put these on the list to "look at". TomK
-
-
I've heard similar descriptions when multiple instances of x-plane are running....I can't be sure though, this is a "back of my brain" weak memory response. TK
-
well blender and AC3D modelling is "unitless" per se...at least with regards to the OBJ format as there is no unit information inherent in the exported file. So as long as whatever you are exporting from blender/ac3d is "100 units long", then it will be 100 meters in x-plane. I'm not sure than the *.lwo format supports unit information so its might be that as long as whatever you export in Maya is 100 "anything", then it will come into blender as 100 units and thus exported out to 100 meters for x-plane. The only unknown here is if you set units to meters in maya, will maya do some kind of conversion on those numbers when exporting to some intermediary format like *.lwo to get into blender. My guess is no and that using meters in Maybe would be fine. Sometimes, when I want to model in blender in feet...being that its unitless (at least 2.49 which I use is, not sure about 2.6+)...I'll do just that and right before export, scale the whole model by 1/3.28 to "convert" it to meters and then export that out. TK
-
X-Plane uses a proprietary 3D format called 'obj'...not to be confused with wavefront OBJ. The xp obj format is simply UV mapped triangles so you can, of course use any 3d program to create and UV the geometry. the trick is exporting the geometry into x-plane's format. Currently that is done with either Blender or AC3D, both of which have exporters for x-plane OBJ format available for them (add-on, not native). The OBJ format has several "directives" as part of its specification...one of which is called a "draped poly". A draped poly lays flat on the terrain and this is, therefore, what you would be looking at for runways. Applying these "directives" to the 3D geometry in order to tell xplane how to handle the geometry is inherent in the workflow in AC3D/blender....inherent through the exporter scripts that is. Usually, you apply properties to the geometry, maybe a string property and this will cause the exporter to output the proper commands to the OBJ file during export. Because the OBJ is just text though, its possible to edit the file by hand, but this is where the explanation gets a bit more lengthy as many more questions arise. So for you, I'd recommend you'd model / UV / texture it in Maya, export it out in some poly format that will import cleanly into blender/AC3D....usually *.lwo or *.obj (wavefront) works fine. Then once in blender, you can apply any directives that x-plane provides and export out in OBJ(xplane) format and use WED to place it. The OBJ format is in meters. TomK
-
---
-
yea...it was basically a "screengrab" showing some testing of the gear and how the gear rates change with hydraulic scenarios. Not really what most folks are interested in and there was a lot of "loose wires" hanging out so to speak and folks will make conclusions about the product based on what they see and we're not quite ready to show some aspects in unfinished states. TomK