Lorby_SI

Commercial Member
  • Content count

    1,077
  • Joined

  • Last visited

2 Followers

About Lorby_SI

  • Rank
    Developer

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Contact Methods

  • Website URL
    http://lorby-si.weebly.com

Profile Information

  • Gender
    Male
  1. Hello @ll, after discovering the next violation of the XML spec by a well-known product, I have decided to add an XML sanitizer process to the P4AO. This process will take a look at all the XML files that are supposed to represent addons, and it will correct all XML tags that are not as required by the specification. This is done to the best of its abilities, and there are still options to screw an add-on.xml up. I can only urge everyone not to handle these files like simple textfiles, be it manually or programmatically. Use proper XML serializers, obey the encoding rules and make absolutely sure that your tag names are as they should be according to the P3D Learning Center. And take note of the W3C spec what an XML file actually is. The new P4AO / Addon Organizer version is available for donwload on the Lorby-SI website, section "DOWNLOADS". Important: I can only test this tool with the addons that I have. So be careful when using it, especially now with the "sanitizer". Best regards
  2. Hello @ll, same problem as with ORBXs add-on.xml file. The tag names inside the add-on.xml that is generated by UT Live are incorrect. UTL is using "<Addon.Component>" instead of "<AddOn.Component>" (note the captial "O" in AddOn). As a consequence, the Microsoft .Net XML serializer cannot see those components, and they are ignored. When you press "Save" on the P4AO, the UTL xml is suddenly empty, and the UTL program will not start any more with the sim. The only work around that I can think of is to always start the UTLive desktop program once after you have used "Save" in the P4AO. It makes no sense to correct this file, as the UTLive GUI is constantly overwriting it. Sorry, but I am not going to try and sanitize the files of other developers. By generally accepted rules the XML tags are case sensitive - and the P3D Learning Center clearly states what these tags have to look like. That the simulator reads this file although it is incorrect, IMHO is no excuse to create an incorrect file in the first place. OK, I give up. Starting with version 1.25 of the P4AO I have added an XML sanitizer process that corrects these issues and forces the XML to show the values required by the specification. Issues like this one should be a thing of the past (the original XML file is still wrong though). Best regards
  3. First: the beginning is missing (the part before SimBase.Document) Second: In the <Path> tags there must be the actual file system paths, fully qualified (=starting with the drive letter). The (1)s and (2)s were only to illustrate that you have to put them there, these numbers are of course not part of the string. Third: you cannot have more than one Path in the same Addon.Component. If you need more paths, add another Component of Category "SimObjects" Fourth: Instead of trying to hand-write XML files, may I suggest that you use my P3D Addon Organizer tool? It is available for free on the Lorby-SI website. You must get the text encoding right too, and only advanced text editors can do that - meaning, you can't write an UTF-8 encoded XML file with Windows Notepad. Example: I don't have UT2 installed on this computer, and I have no idea where you have installed your stuff, but the file should look something like this. Please take note of what the <Path> tags actually have to look like and replace my example paths with the actual ones from your computer. Best regards
  4. Hello Ralf, no, that won't work too well. The more AI are deleted, the more UT will be fighting back. This will lead to significant stuttering. You can try the 50% reduction menu option, but it was my experience that UT will simple recreate the sleepers that have been removed. The only way would be to move those AI someplace where you can't see them, like 20nm from your position, and stack them there. Then UT probably doesn't realize that they aren't at their gates anymore. But you would have next to no performance gain, as they are still present in the sim. Best regards
  5. Hello Harry, a long time ago I was using some kind of a swiss army knife tool for FS9 and FSX aircraft. Raking my brain what it was called. FlusiFix? Probably not. Ultimately I have written my own tools to do this kind of maintenace. One of my payware addons does it too, but not as a batch job, you would have to adjust each aircraft individually. A few months ago I made a tool that adds the missing radios to all aircraft that don't have them, and which would be ideally suited for the brake scale too. But I haven't invested the time yet to make it fit for a public release. I can do that tomorrow if you are interested, it's not a big deal though. Best regards
  6. Hi, both files have a different focus: - C:\Users\...\AppData\Roaming\Lockheed Martin\Prepar3D v4\add-ons.cfg Contains all addons that P3D discovered automatically = which were established with an add-on.xml in \Documents\Prepar3D v4 Add-ons\. This file is automatically refreshed every time you start P3D and it browses through the addon folders in \Documents\Prepar3D v4 Add-ons\ - C:\ProgramData\Lockheed Martin\Prepar3D v4\add-ons.cfg Contains all addons that have been installed with the command line tools from the SDK. This file remains static unless some installer adds a new addon to it. Best regards
  7. I guess we will have to disagree then. Maybe I'm looking at it the wrong way, but aren't aircraft somehow part of AI traffic? As a customer I don't have any understanding for developers who are cutting short quality control because it is too much work for them or "impractical". Don't sell it, if you can't do it properly. Even if you would change the AI controlling mechanism, you still have to solve the interaction between adjustable parameters and the logic processing them. It doesn't matter how "good" you make the AI logic if an aircraft dev still has the option to undermine it by providing funny values. So nothing would change, even with a superior AI solution, You still need different aircraft behaving differently, and the developers of those aircraft still need to adhere to a rock solid spec and rigorous testing so everything works together correctly. That didn't work out too well in the past 25 years. Best regards
  8. So what you are saying is, that the result of incorrect parameter settings is the fault of the logic processing them? That is one way to look at it. Fact is, that setting the brake parameters correctly will result in a realistic AI landing. I'm with Nemo on this one: the AI package developers should invest the time to make their aircraft models land correctly. It is possible, it is just a lot of work. Can't see the "hack" in it, when the developer himself creates something that works out of the box. I would call that "quality control" instead. But I'm also a realist, so personally I have always been more than happy with adjusting the parameters. As far back as FS9 there always was a programmatic tool to do that. Best regards
  9. Hello @ll, so much for principles. After giving it a little more thought, the "RemoveAiSleepers" has been updated and it is again available as a free download on the Lorby-SI website. It will remove all AI from your simulator that is a) sleeping, b) has a departure scheduled later than the (adjustable) time frame and c) is in range (1-80nm). The tool still is a external SimConnect client, so it is not hacking into the simulator internals in any way. Please note: "RemoveAiSleepers" cannot work with any of the "Utlimate Traffic" products. Those programs inject AI aircraft without a schedule, so it is impossible for the removal tool to know when they should depart (also see the post from Pete Dowson). I have included an in-sim menu where you can cut the number of sleeping AI in half across the board, but that doesn't seem to have much effect on UT either - it looks to me as if they are constantly respawned after having been deleted. YMMV Best regards
  10. That can be adjusted. You need to alter the "toe_brakes_scale" (and possibly "min_throttle_limit") parameter in the aircraft.cfg of the AI planes. There are a couple tools doing that for you. Best regards
  11. In a little more detail: All "offending" AI are removed as expected. But. The AI aircraft that are initially loaded by the sim when you start a flight or jump to an airport remain active in the internal lists of the simulator - although they are gone from the gates. A program like STB will still show them, until the simulator decides to remove them for good (which can take a long time). Instead, all other AI that are created by the sim after the intial loading process are removed properly by the sim. Unfortunately my options with an external SimConnect client are limited, so I decided to give it a rest. Best regards
  12. Hello @ll, sorry about that, but after having checked with Ray, I have decided to withdraw the "RemoveAiSleepers" tool. It works, but the way that it works leads to side effects that I don't like. Especially programs like the STB have their difficulties with it. FSUIPC or Davids DLL are better suited for this task. Best regards
  13. Hello Jay, as I said, the sequence in which the AddOn.Component tags show up is completely irrelevant. XML files don't work like that. The defining attribute for the scenery priority is the number in the "Layer" tag. I would stay away from the XML files if I were you. Don't ever edit them manually. Best regards
  14. Hello Ralf, not sure if it is even necessary in UTL. The UT products shouldn't inject those sleepers in the first place, but I don't really know. I will check it out later today when I am (hopefully) flying in my sim. Gate reservation: that may seem like a small feature in WAMA, but it isn't. Programming effort was about 40 hours IIRC. Besides, as a general principle I don't just suddenly give away stuff for free that people have already paid for. As for the main feature of WAMA (I'm assuming that you are talking about the "fleet parking space" database) being irrelevant for airliners - that depends on what kind of pilot you are. Take me for example, I don't have the time or the nerve to operate airliner flights realistically. I am lucky if I can manage to use my sim for its intended purpose once in a week. But I like to fly tubes from time to time, and then I like it that they still are where I left them. So for me that feature is a bonus in all situations. On my virtual home base of choice (LIEO) there are only two gates left for AI, the rest of the gates and most of the parking spaces are occupied by my own fleet :o) Maybe I should add yet another feature to WAMA, where the airliner that you flew in on departs automatically to its next destination an hour later (= a variation of the fleet transfer feature). Or at least changes the gate at the airport at random, so when you get back from your hotel the next day, the plane is in a different spot. On second thought, probably not such a good idea. Best regards
  15. Hello Gerard, I'm afraid that you misunderstand me, that is not what I meant. What I am proposing is being able to trade places with the real flight. Assume I am approaching EDDF and I see LH492 near me, going there too. Then I would like to tell the program that from now on I am LH492. It then removes the real flight, warps me to its last position and I can fly the approach in its place. I should even have a free gate reserved for me, right? Best regards