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.

Sign up for GitHub

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

Jump to bottom

Enabling multiplayer AI after setting position #118

Merged
merged 2 commits into from
Jul 10, 2017
Merged

Enabling multiplayer AI after setting position #118

merged 2 commits into from
Jul 10, 2017

Conversation

MichaelRThompson
Copy link
Contributor

Update from NASA develop

@MichaelRThompson
Merge pull request #1 from nasa/develop
6632cfe 
Update from head fork 7/5/17
@MichaelRThompson
Enabling AI after setting position
49b4aa7 
Previously, the code enabled the AI before setting the position of a/c, which negated its purpose.
@MichaelRThompson MichaelRThompson changed the title Merge pull request #1 from nasa/develop Enabling multiplayer AI after setting position Jul 10, 2017
@MichaelRThompson
Copy link
Contributor Author

Based on comments in #114 , HandlePosi should enable the AI after setting the a/c position. The code currently enables the AI before setting the position.

@MichaelRThompson
Copy link
Contributor Author

And I'm not sure, but I wonder if this could have anything to do with #115

@jason-watkins jason-watkins merged commit fb73d5e into nasa:develop Jul 10, 2017
@jason-watkins
Copy link
Contributor

Yep, that's definitely backwards. Thanks for the fix. I will see if I can reproduce #115 with and without this patch included. I wouldn't think it would be related, but it's possible.

@MichaelRThompson MichaelRThompson deleted the multiplayer_ai_fix branch July 10, 2017 20:05
@MichaelRThompson
Copy link
Contributor Author

I keep second guessing myself about this commit. Maybe you can clear some things up for me.

I know for sure:
override_planepath turns off the physics sim for any one of the a/c

I don't know for sure:
Does override_planepath automatically also write to override_plane_ai_autopilot? The documentation here makes it seem like it might be the case, but I'm not sure.

But what I'm really getting at:
So even if the AI is disabled by override_planepath , why is in re-enabled in the HandlePosi function? This function never writes to override_planepath directly, and neither does SetPosition, SetOrientation, or SetGear, the only relevant functions called inside. The more I think about it, the more I think that this commit doesn't actually change anything, and in fact, a more appropriate place to enable the AI would be when the simulation is unpaused.

Am I missing something here @jason-watkins ? Is there a documented reason that the AI was enabled here when the position is changed?

@jason-watkins jason-watkins mentioned this pull request Oct 20, 2018
Merged
jason-watkins pushed a commit that referenced this pull request Oct 20, 2018
@MichaelRThompson @jason-watkins
Enabling AI after setting position (#118)
012df27 
Previously, the code enabled the AI before setting the position of a/c, which negated its purpose.
jason-watkins added a commit that referenced this pull request Jul 20, 2019
@jason-watkins
Version 1.3-rc.1 (#138)
a3be4cb 
* Minor improvements to the handling of landing gear by the SetGear and HandlePOSI functions

* sendPOSI command change (double for lat/lon/h) (#111)

* Updated POSI to use doubles for lat/lon/alt, as step size for floats was unacceptably large at high longitudes.

* Updated Java library for MATLAB, updated Java project, and updated Windows plugin binaries

* Rolled back Java version to 1.7 for MATLAB compatibility

* Update MessageHandlers.cpp

* Update DataManager.cpp

* Added pause functionality for individual a/c

Adds new cases such that:
0: Unpauses all a/c
1: Pauses all a/c
2: Switches case for all a/c
100:119: Pauses a/c 0:19
200:219: Unpauses a/c 0:19

Updates log messages.

Keeps the 0,1,2 arguments as they previously were.

* Finished individual pause functionality

* Update DataManager.cpp

* Updated flags to allow for individual pause commands

* Individual pause command documentation

* Updated flags to allow for individual pause commands

* Adding individual pause to documentation

* Updated flags to allow for individual pause commands

* Requested changes, cleaning

* Update CMakeLists.txt

Include "-fno-stack-protector" for linking and compiling for systems that do not have this have this flag as a default.

* Enabling AI after setting position (#118)

Previously, the code enabled the AI before setting the position of a/c, which negated its purpose.

* Updated XPlane SDK to version 2.1.3

* Resolve function ambiguity for std::abs on mac

Fixes #126

* Update copyright notice

* Update Windows binaries

* Update Linux binaries

* Update version numbers

* fix osx abs ambiguity (#142)

* fix indexing error (#143)

* Runway camera location control (#144)

* update ignore

* basics working

* set cam pos remotely

* log cam position

* keep default behaviour, if short view message is received

Compatibility with existing software

* all to tabs

* rename variable

* option to use camera direction fields

* Added UDP multicast for plugin discovery (#153)

* Added Timer

* Added UDPSocket::GetAddr

* Added MessageHandlers::SendBeacon()

* PoC of starting a timer on PluginEnable

* C++11

* Added Timer to xcode project

* C++11 in cmake

* added Timer to cmake

* use function pointer in Timer

* moved Timer to namespace

+ wait for thread to join when stopping the timer

* Windows: changed uint to unisgned short

* Windows: Added Timer.h/cpp to project

* GetAddr static

* Send xplane and plugin version with BECN

* SendBeacon with params

* fixed file copyrights

* Include functional

to fix Linux compile error

* review fixes

* Send plugin receive port in BECN

* review fixes

* Fixed tabs vs spaces indentations (#157)

* Java client BECN implementation (#155)

* Added MS Azure Dev Ops CI integration (#162)

* Do not build for i386 on macOS

Use ARCHS_STANDARD  to avoid the error “The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture.”

* Fixed missing include

The Visual Studio solution was not compiling

* Fixed isnan ambigious refernce

Ambigious reference when compiling on travis

https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it

* Set MSVC warning level to 3

Too many warnings were generated when building a Release build making Travis job to fail because of too much output

* Use default toolset for Visual Studio

AppVeyor recommends to set the default toolset

* #include <cstdint>

* Use MSVC ToolsVersion="14.0"

# Conflicts:
#	xpcPlugin/xpcPlugin/xpcPlugin.vcxproj

* Removed binaries from repository

# Conflicts:
#	xpcPlugin/XPlaneConnect/64/win.xpl
#	xpcPlugin/XPlaneConnect/win.xpl

* Added ms azure ci

xcode

linux

linux + macos

linux + macos

removed branch filter

win tests

win tests

Test all platfroms

artifacts tests

* output all binaries to ‘XPlaneConnect’

All platforms produce a binary in
xpcPlugin/XPlaneConnect/
xpcPlugin/XPlaneConnect/64/

* Added ms azure GH deploy

deploy stage

GH release test

trigger tags

* Clean up yml file

- Added variables
- Added job decriptions

* Ignore script to ignore .exp files

+ fixed output path

* Renamed ms azure GH connection

* Update service connection for azure pipeline

* Added Python3 compatible xpc client. (#156)

* Update Azure Pipelines service connection
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
resolution: fixed type: bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@MichaelRThompson @jason-watkins