Tactics Plugin

[tom_BigSpeedy]

Originally Posted by Canne

Yes, I was astonished to find the old code, since the O itself sends new format $OCRMB sentences. One of the joys of back-porting. Never mind, I was able to fix the class to support both RMB-formats.

Hi Petri,

well, I stopped synching dasboard changes into tactics more than a year ago, due to lack of time ...
They must have done it in the meantime ...

You immediately found the "weak spot", the 32bit limit for the number of instruments ...
I never got around this without reprogramming the whole software ...

If you have a solution now (with 64bits) it's great

I have some more ideas but missed free slots for new instruments ...

One which I'm really missing is : "Distance to layline" = How far to sail in time and distance, till you can tack.
I improved the "polar performance" code lately, that works reasonable now (except that the "total %" in the caption is influenced by maneuvers)

BR,

Thomas

[Canne]

Originally Posted by rgleason

...I found a new bug which upsets the dashboards when you delete an instrument, the vertical height sizing gets frozen. Then when you add that instrument back to the dashboard the vertical height unfreezes and gets sized properly...

Thanks, Rick, for the monkey, but this is a new bug for O v5.0.0 or probably for Dashboard in it, from which I forked. Same thing happens with Dashboard:

Now the dilemma: I did all the work for to integrate Tactics functions in Dashboard in order to profit from its stable and upadated code base. Should I now derive from Dashboard code to fix this bug in it? Maybe that's the right way to go.

Anyway, please file a bug in Dashboard plugin of O. Meanwhile, I can take a look at this, like for RMB and for VMG, no problem. But I don't understand about anything of this wxWidgets, I am a Qt guy at my best, a simple sailor! If somebody out there can give me a hint where to look in this unbelievable wxWidgets rain forest, I will try.

Originally Posted by rgleason

I wonder if it would be possible to save the location of dashboards even when they are not docked? Wouldn't that be easier for everyone?

Again, a feature of O: Remember that AUI-section in ini-file in which I helped you recently? All windows are stored there, Dashboard and therefore Dashboard-Tactics are doing nothing but naming the windows they use. O maintains their position and size. If you have a slightest issue with names in that AUI-section nothing will work with your massive number of windows. I have no issue with many windows reopening like they should, provided that I quit O correctly (so that it writes back to the ini-file).

Originally Posted by rgleason

PS: Perhaps I should make those changes for VMG that you suggest? Then try them?

Thanks, Rick, but no need for further tests. I have tested with so many RMB sentences now and the way the VMG instruments get updated from those is faultless. And when they stop flooding in, there is a watchdog to wind those instruments down (I had to modify the Dial instrument class for that, BTW: already I am modifying Dashboard). What that RMB-sentence provided VMG value means to each of us, I leave to wiser men than me to decide, I just show it.

BTW, you are not testing only Tactics, I hope, but Dashboard (for cruisers) and Tactics (for racers and technology freaks). Dashboard is not bug free, and can be improved like Tactics as suggested already by Thomas above. Maybe they can do that hand in hand. Maybe not.

[Canne]

Originally Posted by Canne

Aedan, I'll attack the bug you found and your crash issue now. For the crash I cannot reproduce on Win10 butI have a plan: I will test it on my Linux navigation computer.

Good news first, I've found a bug (fix): your instruments are sending a VWR sentence with AWS, and each sentence should re-arm the watchdog for that value. It didn't and every ten seconds or so, the AWS value was told to Tactics to be a NaN (not a number). Mea maxima culpa: this is part of the interface that Dashboard needs to keep running and call Tactics's virtual and active functions; a code block I should have added.

Bad news is that I was not able to reproduce the crash, both in Windows and Linux box your data works, and no crash:



SOG-box was the only box selected. (Sorry for the bad resolution in Linux, it is an 8-yrs old mini-laptop but is running strong as a spare navigation computer!). There is no polar performance since no STW (or it is 0.0). I hope you're looking for true wind active calculations only.

I can see that my latest commits have been built already: please try them from here.

Best regards,

Petri

[Canne]

Originally Posted by tom_BigSpeedy

...If you have a solution now (with 64bits) it's great...

The solution was to move form int to unsigned long long and shift 1ULL instead of 1. With that you can imagine the amount of work I've done since that "int st" is everywhere... A burden from the past. But now it is gone!

Originally Posted by tom_BigSpeedy

I have some more ideas but missed free slots for new instruments

I would be honored if you would fork my repository and give us the ordinary sailors a few new virtual instruments to play with!

[rgleason]

Canne thank you, see
https://github.com/OpenCPN/OpenCPN/issues/1425

[RonSouthworth]

Hi

Thanks for the efforts looking good folks.

I have loaded the prerelease version of the merged dashboard and tactics running side by side on macOS.

The chart is showing the new dashboard laylines.

Looks really good, a few things to sort out and it is there

I have captured the simulated message values on the first photo and the second shows what the plugins are displaying

So you can see what is displayed vs what is being sent.

[Canne]

Originally Posted by RonSouthworth

...So you can see what is displayed vs what is being sent.

Thanks, Ron, looks like a great tool for a developer! The numerous NMEA-files I've seen flying by are good for the final tests, revealing the cruelty of the real NMEA world. But for unit tests they are hell. For those I would really like to have such a tool! For Tactics, there is a need for ROLL and PITCH XDR-sentences to test its active functions response. Maybe those would be a good add-ons for the tool if you happen to be able to give feedback to its developer.

[rgleason]

Petri, for Dashboard-tactics, is there a difference between how an active waypoint and a dashboard-tactics wp is handled? I suppose I could just test..

[Canne]

Originally Posted by rgleason

Canne thank you, see #1425

Hi Rick, here's a fix: code+comment and Win build. Let me know if it works for you.

[rgleason]

The Right click > ^TacticsWP results in Laylines showing, whereas the OpenCPN normal Active waypoint shows the Console with XTE, VMG, etc and no laylines.


Petri, you are correct, the positions & sizes of the dashboards are all saved and return, provided you do not change from Tactics to Dashboard or Dashboard-Tactics versions. So its generally best to just use one of the versions I think.


BTW I have tried to get all the instruments showing for testing. That is not a normal setup.

[rgleason]

Petri,
Using your built version, it is better but not quite there yet. When I delete a Polar Compass, the height is frozen in the up direction.


If I resize the width wider, the two remaining compasses take up the height plus some. I can pull the bottom down to show the full compass at the bottom.

Then when I resize the width back to close to the original size, the height gets frozen in the up direction, as if the compass deleted was still there.

Also I cannot right click and pick preferences, but can do so on the other dashboards.

Hopefully these screenshots will show these situations.

[rgleason]

Changing the width

[Canne]

Originally Posted by rgleason

The Right click > ^TacticsWP results in Laylines showing, whereas the OpenCPN normal Active waypoint shows the Console with XTE, VMG, etc and no laylines.

Rick, Tactics has nothing to do with the Active Waypoint. Dashboard has nothing to do with the Active Waypoint, it is a pure O routing function.

But as soon as you have an Active Waypoint, O itself starts sending $OCRMB sentences (for the autopilot). Dashboard hears them like all other NMEA sentences. Among others, this particular RMB contain a value called "Destination closing velocity in knots" (O doc ref). For some people that is VMG (let's not discuss that now, please).

Here's the test "PASS" condition: in Dashboard there is an instrument called "VMG". It can be shown the same time as Active Waypoint Console, which also have an instrument called "VMG". They should both show about the same value (accept a few seconds delay in Dashboard). The average Joe would not be confused - same instrument title, same value.

This you can test easily with sample4, just right click "navigate to here" somewhere ahead of the boat and observe the two VMG value, that of Dashboard and that of Active Waypoint console.

Do not attempt that with sample3 since tom_r's NKE instruments are sending RMB sentences there which have a totally other meaning (like in Tactics).

^TacticsWP is for completely other purpose, it has nothing to do with O's routing functions. It has nothing to do with Dashboard instruments either. It is only used in Tactics active performance functions. If you use it, observe only its effects on Tactics instruments and performance functions.

This is not Tactics in steroids, this is Dashboard + Tactics. I can already see it is a confusing concept.

Originally Posted by rgleason

...the positions & sizes of the dashboards are all saved and return, provided you do not change from Tactics to Dashboard or Dashboard-Tactics versions. So its generally best to just use one of the versions I think.

Dashboard and Dashboard-Tactics are sharing the same name space for their windows from O's point of view. It would be wiser, indeed, to have only one of them enabled at time. Tactics and and Dashboard-Tactics are completely separated and can be used at the same time.

When you switch from Dashboard-Tactics to Dashboard, or back the other way around, you are likely to be forced to reorganize the instrument windows. This is O, there is nothing that can be done if we want to keep the same name space and compatibility with Dashboard.

Originally Posted by rgleason

BTW I have tried to get all the instruments showing for testing. That is not a normal setup.

I know, and I appreciate the huge effort you make. I was just pulling your leg!

[Canne]

Originally Posted by rgleason

Using your built version, it is better but not quite there yet. When I delete a Polar Compass, the height is frozen in the up direction.

I can confirm that the AppVeyor build behaves the same on my machine. However, the fix works on my local build when launched from VS... Some library compatibility or timing issue?

This is going to be nerve-racking! Thanks, don't waste your time more on this, we need some wxWidgets expertise. I will make some more tests while waiting that Dashboard bug request brings up something.

[AedanC]

Petri, Rick,



Sorry for the lack of feedback from me, I've been locked out of the forum for the last few days due to a security update of some sort, just got back now.

Originally Posted by Canne

Good news first, I've found a bug (fix): your instruments are sending a VWR sentence with AWS, and each sentence should re-arm the watchdog for that value. It didn't and every ten seconds or so, the AWS value was told to Tactics to be a NaN (not a number). Mea maxima culpa: this is part of the interface that Dashboard needs to keep running and call Tactics's virtual and active functions; a code block I should have added.

Good to know you found something and have a fix, I'm at work now, I'll try and give that a try this evening (European time).

Originally Posted by Canne

Bad news is that I was not able to reproduce the crash, both in Windows and Linux box your data works, and no crash:

Since I was last here I've tried rebooting and a delete/reinstall cycle of the plugin. I also tried deleting the old version of dashboard too. No change. I tried replaying a different file into OpenCpn using a python player over UDP instead of VDR and that also made no change, it crashes as soon as the data comes into OpenCpn. I'll try the latest build from your link and if it still crashes then I suppose the next step is a remove/delete/reinstall cycle for OpenCpn, unless you have other suggestions?


Can OpenCpn be started in a debugger? I have a small amount of experience some years ago with gdb, is there a windoes equivalent? That might at least give a message of some sort. It might also be worth starting it from the command box and seeing if I get anything.

Originally Posted by Canne

SOG-box was the only box selected. (Sorry for the bad resolution in Linux, it is an 8-yrs old mini-laptop but is running strong as a spare navigation computer!). There is no polar performance since no STW (or it is 0.0). I hope you're looking for true wind active calculations only.

Yes, the STW impeller was stuck that day, it usually works.



Thanks again for all your help.


Aedan