Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AIRBOSS: wire determination improvement #1788

Open
funkyfranky opened this issue Sep 25, 2022 · 10 comments
Open

AIRBOSS: wire determination improvement #1788

funkyfranky opened this issue Sep 25, 2022 · 10 comments
Assignees
Labels
DCS bug DCS bug. Please report on ED forum. Enhancement Moose code enhancement.

Comments

@funkyfranky
Copy link
Collaborator

funkyfranky commented Sep 25, 2022

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.

@funkyfranky funkyfranky added the Enhancement Moose code enhancement. label Sep 25, 2022
@funkyfranky funkyfranky self-assigned this Sep 25, 2022
@thebgpikester
Copy link
Collaborator

Where is this one going @funkyfranky ? Pretty sure arguments cannot be gotten, but if you wanted to make a plugin for it that might.

@funkyfranky
Copy link
Collaborator Author

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 :)

@funkyfranky funkyfranky added the DCS bug DCS bug. Please report on ED forum. label Dec 16, 2022
@funkyfranky
Copy link
Collaborator Author

funkyfranky commented Dec 18, 2022

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.

@Rolln-dev
Copy link
Contributor

Rolln-dev commented Dec 19, 2022

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.

@thebgpikester
Copy link
Collaborator

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.

@thebgpikester
Copy link
Collaborator

https://wiki.hoggitworld.com/view/DCS_func_getDrawArgumentValue maybe
let me check the model viewer to see if I can get the argument values

@funkyfranky
Copy link
Collaborator Author

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.

@thebgpikester
Copy link
Collaborator

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.

@Rolln-dev
Copy link
Contributor

I will take a look at it more over the holidays and try a few ideas.

@thebgpikester
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DCS bug DCS bug. Please report on ED forum. Enhancement Moose code enhancement.
Projects
None yet
Development

No branches or pull requests

3 participants