ivanwfr

It's good to read some objective considerations at this stage and, even if it this is no solution for our problems yet, this is what modders need to know. Only someone involved in technical design can have a grasp on what is relevant to security in addons scope. Modders don't need any access other than what the sim is ready to communicate about in and out. And, once more, I think that socket can provide means to settle some API based on simple commands+args semantic as well as separate module responsibilities completely. LUA sockets is nothing more than any other implementation of socket layer... open, connect, read-write, close... Socket Hello-world are nearly one-liners and no one should be allowed to say I don't know how to use them more than once per lifetime ;)

Yea, I've done that too but, I've been told (by someone who knows ;) ), that Hog's ILS needles are a bit wild at the moment... So, I went back at day time with some amount of visibility to avoid still being chasing them a few seconds before flare time. But, I'd enjoy watching your tracks as it's always very satisfying to see how others can have some problems too ;)

I +1 for localhosted LuaSocket for USB devices script/driver comm... and maybe missing print workaround.

Hi Sabre, my first contact with the Mission Editor was motivated by the amount of frustration I got from a huge number of failures I had with your #6 mission ... and I feel lucky enough from having such a good reason to be persistent on that task as it looks like programming with assembly language. You really have to know what you're doing to get any consistent result. So here I am with 2 questions: #1 WTF those heading parameters that look like their effective-value has to be the complement to 360! :cry: Any comment on that ? #2 is about BFT06's Flags 41 and 43 heading triggers: It would make more sense if Flag 43 heading was exactly the same as Flag 41 heading. That would simply be facing the same quadrant with a banking angle in the opposite direction while getting back on course. ...and this could be related to... Flag 43 UNIT'S HEADING LIMITS MIN=165 is greater than its MAX=95 Everything would be easier if both headings were MIN:165 MAX:275, meaning: MIN=(360-165) = 195 MAX=(360-275) = 85 :book: That would be facing SE near lazy 8 start and end. - facing SE, turning East from initial 210 heading (start check). - facing SE, turning West back on course to 210 (end check). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [edit] In the mean time, I cheat with my debug Lazy8.miz in which I added some means to restart the lazy8 test if you bank upside down and get back to 210-8000. + With banking white messages above hard deck 4600, heading messages every 30 deg boundaries below. + Flying above the landing zone above 5000 will restart the landing test. ...but no qualification or mission goals. Lazy8.miz

I don't know how to alter F4 function iCommandViewChaseArcade. But we know how snap views work and one of those 10 views could be given customized parameters. Some dedicated switch would make what you're seeing to be that snap view. It boils down to assigning the following two keystrokes sequence : PULSE+ L_WIN+ KP_DYNVIEWNUM ... to select the "Snap View of Interest" PULSE+ R_ALT+ KP_0 ... to "Save Cockpit Angles" for that view

Do you mean that you're looking for some extra snap view?

As I said, everything is fine in all Sabre-TLA's missions. It's just a question of how this is working internally. But I'm about to find out with added on screen messages with triggers based on heading sectors : "c_unit_heading" "min_unit_heading"] = 1, ["max_unit_heading"] = 30, ["comment"] = "HEADING 1-30" "min_unit_heading"] = 31, ["max_unit_heading"] = 60, ... "min_unit_heading"] = 61, ["max_unit_heading"] = 90, "min_unit_heading"] = 91, ["max_unit_heading"] = 120, "min_unit_heading"] = 121, ["max_unit_heading"] = 150, "min_unit_heading"] = 151, ["max_unit_heading"] = 180, "min_unit_heading"] = 181, ["max_unit_heading"] = 210, "min_unit_heading"] = 211, ["max_unit_heading"] = 240, "min_unit_heading"] = 241, ["max_unit_heading"] = 270, "min_unit_heading"] = 271, ["max_unit_heading"] = 300, "min_unit_heading"] = 301, ["max_unit_heading"] = 330, "min_unit_heading"] = 331, ["max_unit_heading"] = 360 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Got it: UNIT'S HEADING IN LIMITS params = 360 - Effective heading But it remains to know why it works this way?

Hidden, under the Download line.

Exactly my point! But if you are heading 300, you get caught by the second rule of the trigger and you get the message telling you to turn to 300 :doh: I was suspecting some sort of mixed unit issue for heading (radian, mils, ...) as the one we have with altitude in meters for trigger rules and feet in message to pilot... Nothing makes sense on that path and I still can't figure out what I'm facing here.

UNIT'S HEADING IN LIMITS Could somebody explain how comes a MESSAGE like this applies to RULES like those? (and I know it does): RULES: UNIT'S HEADING IN LIMITS, 1, 49 OR UNIT'S HEADING IN LIMITS, 61, 360 ACTIONS: MESSAGE (You're heading off-course. Turn to 300) I just don't get the numbers :huh: (...this comes from Sabre-TLA's BFT06 - Advanced Handling)

Yes Yammo, with more time spent dealing with all kinds of adjustments, what you describe seems about right. We are more trimming than siming. Once more, back to my motto: software should not be granted more license to be dumb as hardware is. Should we have our cars be as unreliable, human lifespan would be near 18. I'm pretty sure that some kind of "back to reset parameter drift with time" would be smart enough to restore a neutral position when errors accumulate. The thing is that I'm not sure if it would be reasonable to expect being heard by TrackIR devs... Anyway that's something worth investigating, and this would be in some NaturalPoint's forum.

Thanks Headspace for your attention :thumbup: If you are looking at my call to GetDevice(0).get_argument_value(800), it comes from there: This, and the Export.lua LoGetAltitudeAboveGroundLevel() -- (args - 0, results - 1 (meters)) which I could turn into visual cue with blinking leds ont TM Warthog throttle console as an alarm based on approach altitude -- BTW, I was just playing some fancy application, not to be seen as an attempt to provide a missing A-10 feature! But, most importantly, all I've done so far is to explore what could be worth exporting data back to TM Warthog throttle, stick and console lights. The main goal would be to get an overview of what could be done with some sim feed back to the input device, instead of the standard one way communication. And until previous patch, it was promising. All I'm looking for is a solution to get back on track from that point.

In fact, socket may not be at stake here. At that time, all I could see was that I had nothing getting through anymore. And without print to tell me what was working and what was not from Export.lua side, it was just an assumption that socket too was away. Since then, I could replace the missing print function with io.write to trace what is happening and here is what I get: get_argument_value is the missing part and the socket code part is not even reached. Code attached in PNP_ivanwfr_110725.zip. The relevant code sample: The 1109 log: The 1108 log I get from a stub that mimics a short sample session: And the TARGET log from the other side of an UDP socket : PNP_ivanwfr_110725.zip

I see no chaos from where I'm reading but rather a bunch of facts causing some trouble for people that are exactly as passionate about the subject as you moderators and devs are! With time (only 2 days till now), patience and some deep breathes, I'm pretty sure the outcome will be constructive and the experience be seen as a step forward. My single Export.lua had no chance to be one of devs priorities but this one and other tools can't be collateral damage unnoticed with modders kept waiting silently. Should it look like there is some emotion involved in the process, well, I think we are fortunate it is so! All these posts are about getting a sign for some amount of attention coming their way. Praise for ED devs work is a constant in these forums. And I'm one of those who knows how well deserved they are. But, I'm sure devs are also ready to pay attention to more than correcting bugs or getting the most from the technology. A community is an asset, and Apple knows what I'm talking about. As you said, we can help each other to help each other. BTW, I try to shave off bad words that comes out under my fingers before I hit the submit button but please don't ban me right away if I miss one.

Support for what? I agree, there should be a place where to put what has been disrupted by the last patch. But I'm not sure how that should happen and who has to do that in the first place. Before those undocumented disruptive changes introduced by 1109 patch, Export.lua functions like the one I've pointed in my previous#44 post used to work nicely. They don't anymore. What else needs to be said? And I'm pretty sure there are others still to be discovered as not working anymore. That's a what. Devs' say something/keep silent about what? (...) could you link it for me please? Shall we get something a bit fresher that those outdated Export.lua comment lines about how to use those functions in Lock On version 1.2? -- Data export script for Lock On version 1.2. -- Copyright (C) 2006, Eagle Dynamics. (...) That's another answer to what? And the current online related page is the exact replica of Export.lua comment lines. Eventually, I'll have the comprehensive list of what does not work as it used to before the patch. But it takes time just to add code to assert what is gone from ED Export.lua interface. And if devs don't have time to check those themselves, that by itself will be a part of the answers I'm looking for. That's a link.

Thanks for the insight! Those layered contexts are indeed to be considered separately and yes, my point was only referring to the one where Export.lua operates where print has been banned as well. But there, os and io were not. Kind of closing a door and leaving the key in the lock. Well no luck then for your print. But my print was not what I was the most worried about. Export.lua does not export anymore to my UDP listening TARGET scripts and that's what bothers me right now and I'm trying to make an opinion on how reliable is ED modding support, or lack of. We are going to know more in the coming days, should devs say something or keep silent, in both cases we'll have our answers.

No need to wait for a restored print function, here it is: local logFolder = os.getenv("DCS_LOG_FOLDER") or "."; local logFileName = logFolder .."/".."Export.log" local logFile = io.open(logFileName,"wb"); print('Export: print redefined to write into ['..logFileName..']'); function [b]_G.[color="Red"]print[/color][/b](s) if logFile then logFile:write(s.."\n"); end end But here are some long time supported Export functions that are now gone where print currently is: local getArgVal = [color="Red"]GetDevice[/color](0).get_argument_value local getAltRad = [color="red"]LoGetAltitudeAboveGroundLevel[/color] ... and probably more

So far, all I'm seeing is that either socket don't do their job or, even more likely LoCreateCoroutineActivity() is not supported anymore as a result of some undocumented add-on support changes. Even if I don't think we can get any good from nonconstructive augmentation, I can't refrain from saying that we can see that add-ons are not first class priorities to say the least. Export.lua is a peace of history with it's copiright from 2006 and one of the major "advertised" function named LoGetMechInfo() missing since a few years and related forums questions about its disappearance still left unanswered. Would Blizzard behave this way with World of Warcraft community, this could be their doom... If one thing is for sure, they won't! they are too smart for that. And please note that what I'm saying here are simple facts that can be taken care of or neglected but also ignored. And I'd rather vote for premium consideration concerning a documented DCS API. It would then be natural to have related changes well documented in release notes instead of being a matter of nightmares for some of us.... until they give up. Ivan

I saw first post title. Nice :smartass: ...don't bother, it does not hurt so much anymore, got used to it :) ...voted for the new one, I always vote for new stuff anyway. :geek:

I see many more mistakes when they are made out of my own language. And I know yours is not really one, it would be your keyboard's fault, no doubt. But I think you don't need a moderator to change the title as when you edit your first post, you are given the opportunity to change it.

Then, I hope they're going to chime in before it gets too ugly ;)

Alright, positive thinking it is: I would also be very pleased when I see socket communication restored for my plugin called by Export.lua. At first I did not understand what Speed meant as I could see some of my print at work in dcs.log... until I realized they were obliterated during the whole session, only to be restored at stop time. But Sockets are not there either... Do other mods relying on socket work for those who are aware of this requirement for their running configuration ?

Could you come with a disclaimer or will this be an end for many roads?

Please, could you cange your thread's title, my eyes heart every time it gets updated ?