Addon update for Trajectories v2.4.0 #2747
Conversation
|
To match with almost all other angles in kOS it would be better if it took/returned the angles in degrees and not radians. As a result of kOS working with degrees is all most all cases if a degree to radian conversion is needed for a given API call it is much more covenant for the users if that is done automatically on the C# side of things as apposed to requiring the users to do the conversion. |
|
I don't use kOS myself and was unaware that kOS used degrees for most things, I'll add conversion to the addon as Trajectories uses radians internally. |
|
Is it possible to change |
|
@konstantinua00 There is already a 'GetVersion()' suffix that returns the installed version number as a string. tbh there is little reason to check the version integers, for functionality you only need to know if the correct version for the suffixes you want to call is installed, hence why the suffixes that return a Boolean are better suited. I suggest you have a look at the kOS addon docs for Trajectories. |
| var lng = Utils.DegreeFix(body.GetLongitude(worldImpactPos), -180); | ||
| Vector3d worldImpactPos = (Vector3d)impactVect + body.position; | ||
| double lat = body.GetLatitude(worldImpactPos); | ||
| double lng = Utils.DegreeFix(body.GetLongitude(worldImpactPos), -180); |
There was a problem hiding this comment.
BTW, thank you for this change.
The "var, go look up method elsewhere to see what type it really is" design pattern is one of the most annoying misfeatures of C#. I call it "IDE-think" - people think "well, the IDE tells me the type so I don't have to state it", which is a PITA when reading it somewhere other than an IDE, like on github diff output.
There was a problem hiding this comment.
The only place I consider it good is when calling a constructor, because there the constructor's name IS the type so it's already clear from that.
There was a problem hiding this comment.
I have to agree, I rarely use var, usually only when throwing code together quick, once I'm happy with how the code works I will change the var's to the actual types.
|
@PiezPiedPy I am considering taking the risk of merging this without me testing it, and taking your word for it that it's good. I don't normally use Trajectories and you are the expert here on it. Nothing in the code looks bad or out of place and I had a read through it. Are you okay with that? |
Added some return statements to DescentProfile setters to exit after success. Pro/RetrogradeEntry suffixes now pass their parameter correctly to Trajectories API
Also make TRWrapper a static class
|
@Dunbaratu I have no issue with a merge and have already tested so there should be no problems, but those pesky bugs always find a way 😜. |
An update to the addons for Trajectories, bringing in support for new API functionality in Trajectories v2.4.0.
See Issue #2263 - A few missing features for Trajectories Addon.
New Suffix's have been added as follows:
IsVerTwoFour()returns true if the installed version of Trajectories is >= 2.4.0GetVersionMajor, GetVersionMinor, GetVersionPatchreturn version information.GetTarget()returns theGeoCoordinatesof the set target.ClearTarget()clears the target.ResetDescentProfile(ScalarValue aoa)resets all descent profile nodes to the passed angle (in degrees).DescentAnglesreturns or sets all the angles of the descent profile nodes via a list of values (in degrees).DescentModesreturns or sets all the modes of the descent profile nodes via a list of booleans.DescentGradesreturns or sets all the grades of the descent profile nodes via a list of booleans.Documentation has also been updated to include the new changes.