FlightControl-Master
AIRBOSS: wire determination improvement
Idea by sickdock: use getDrawArgumentValue > 0 to determine caught wire.
- In the _GetWire function one could check for the animation argument and return the wire number of the one that is > 0. If all are still 0, nil is returned.
- In the _Trapped function one would not need to check for the speed any more. Instead it could be checked, if a wire is returned. If a wire is returned ==> done, if not call _Trapped again after a delay (as it is done now, just with a velocity check).
This would make the wire calculation much more rigorous. (Independent of SP/MP and airframe).
The beauty of your idea is that we completely get rid of all the wire distances. These are always the hardest to get for a new carrier. Which brings me to the point, that the animation arguments are hopefully also available for other carrier such as the Forrestal.
EDIT This might not work in MP with a dedicated server. Even though other graphical elements (e.g. doors for helos) work.
Where is this one going @funkyfranky ? Pretty sure arguments cannot be gotten, but if you wanted to make a plugin for it that might.
Where is this one going @funkyfranky ? Pretty sure arguments cannot be gotten, but if you wanted to make a plugin for it that might.
Bug was reported to ED by Grimes. So there is hope that it will be fixed at some point. Therefore, I'd like to leave this here in order not to be forgotten :)
Where is this one going @funkyfranky ? Pretty sure arguments cannot be gotten, but if you wanted to make a plugin for it that might.
It is reported to ED that you cannot get the wires. So I'd like to leave this a reminder for me to implement this procedure as an option.
Where is this one going @funkyfranky ? Pretty sure arguments cannot be gotten, but if you wanted to make a plugin for it that might.
I think you may be able to get arguments by using dostring_in('export', ???) from the Mission environment. Would have to test.
I was using this method for a landing weight script I was working on and could tell if the pylons were drawn or not. So not sure if it could be used to get draw arguments of other aircraft other than your own.
Well this is why I asked, dostring_in used to be solely the NET environment until last year when parts of NET, but not all, was added to the mission env. Can it be confirmed how this can be executed? I would love to see an example poc as it opens more things for the mission environment to use.
https://wiki.hoggitworld.com/view/DCS_func_getDrawArgumentValue maybe let me check the model viewer to see if I can get the argument values
https://wiki.hoggitworld.com/view/DCS_func_getDrawArgumentValue maybe let me check the model viewer to see if I can get the argument values
This is what I used. It works in SP but not in MP.
Balls, I went and wrote something already. :) It worked in SP, didnt try MP. DId it break in dedicated server or both? S_EVENT_LANDING_QUALITY_MARK - we are saying this is sometimes incorrect? ANyone ever considered this is different because it is measured server side and the graphics are local to the player? What else have we looked at? I'm on holiday so I don't mind spending some time but I clearly need to catch up.
I think we need ED's help on this. It's reasonable to consider that on a norender dedicated server, models do not actually move in the same way a client sees them. Additionally, it might not be known to most but DCS doesn't follow normal client-server rules. In some cases Client is authorative and what a client sees is reported as fact to the server whom accepts these things. The proof of that is where you see missiles flying differently - I myself saw a missile miss me and I blew up a second later because the client saw me die. The solution must work on dedicated server. Therefore we need to prove it does not currently work by getting data that reproduces the issue. Working any differently is most likely going to lead to a long chase and defeat. We can't ask ED to fix anything without the reproducing of it.