![]() But unfortunately without any good result. So Far So Good!īut I have problems using datarefs of type TEXT and I think I have triedĪll that I can think of, in order to make it work. I have programmed a lot of commands in VoiceAttack, that works very wellĪs long as I use datarefs of the type INT or FLOAT. X-Plane 12 FlyWithLUA SPAD*Next snVoiceAttack_Plugin.dll VoiceAttack I have been working on an automated Co Pilot in X-plane using the following tools: Profiles, Commands and Plugins > Plugin Discussions That might help a you a bit.Xplane - Spad*next - VoiceAttack problem with datarefs of type txt Everything I have found I had to make up by myself since the very little info I found on the subject seemed to work nothing like it did for me.Įdit: And there's also an attachment there which shows how the interface to DCS works. I will document all these as well as part of the program. It's difficult to explain fully how it works and how to use it since you need to edit a lot and create an entire program (hence A2DCS.) The Master Caution Light is event 404 IIRC. The UFC is done and can be found at in the attachment. I have to search through many files and folders to find what I need and often just end up looking through log files. I agree with metalnwood about them not documenting anything like this. I don't use any of the joystick mapping but tap into the a which allows you to control everything and read everything.ĭCSW uses what are called Controller IDs, Event IDs and values for input and then Argument IDs for output. So once the stick config file is setup with:Īnd so on, that won't be affected by any update and no-one should ever have to map all the buttons again, unless they want to change them of course. I think this would not only make it easier for pit builders but also for stick owners, as it would allow for a separate app, whether official or third-party, to map stick axis/buttons to these commands, which could be a lot easier than doing it in DCS's current GUI and even if commands are added in future, the existing ones would stay the same. There will be some commands/datarefs that only work/apply to some aircraft but that shouldn't be a problem. Would work fine and be translated internally to the relevant switch (or ignored if the aircraft doesn't have that function). ![]() I figured we might need to specify the aircraft at the second level but maybe that's not necessary and just using In X-Plane, you can just tick the data you want enabled (or displayed on screen for testing purposes) which is so much easier.įor the commands, we could have something like: I don't see why special export files should need to be created to make the data available for display in other programs or pit instruments/displays. With all the difficulties in DCS with editing lua files to enable exporting data and commands changing, so that people have to edit the files again to get things working that have been broken, I've been wondering if DCS wouldn't be improved and made easier to manage if it just used a similar method to X-Plane? A simple explanation and examples are here: X-Plane uses what it calls datarefs for sharing instrument (and other) data and commands, all with permanent names, for actions the sim can take.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |