Tactics Plugin

[Canne]

I have finished testing both with recorded data and with boat instruments, merged on the trunk and tagged: OV50 dashboard_pi code back-port. "Based on upstream fetch from (approved) pull request tom-r#30, back-port from ov50 dashboard_pi, built and tested both on Windows 10 Pro v1809 and Lubuntu 16.04 LTS."

No issues nor with the Tactics WP on Linux nor with the laylines (only deprecated symbols mods). Had to port XDR code from dashboard_pi into tactics_pi to get my barometer work.

Please test and let me know for the eventual PR. You can find .dll and .so from the release link, if you like.

[RonSouthworth]

Originally Posted by Canne

I have finished testing both with recorded data and with boat instruments, merged on the trunk and tagged: OV50 dashboard_pi code back-port. "Based on upstream fetch from (approved) pull request tom-r#30, back-port from ov50 dashboard_pi, built and tested both on Windows 10 Pro v1809 and Lubuntu 16.04 LTS."

No issues nor with the Tactics WP on Linux nor with the laylines (only deprecated symbols mods). Had to port XDR code from dashboard_pi into tactics_pi to get my barometer work.

Please test and let me know for the eventual PR. You can find .dll and .so from the release link, if you like.

I will grab your commit Canne and compile

Re crashing on startup
It is a platform specific problem running on macOS

It appears to be the temporary tactics waypoint not deleting . it is not in the point being initialised

it is depending on what other plugins are also installed.

I will eventually track it down

Thanks for the effort, it is an excellent plugin.

[Canne]

Originally Posted by RonSouthworth

It appears to be the temporary tactics waypoint not deleting . it is not in the point being initialised.

Ron, I am not suprised. There are many stuff which have simply 'worked' in Windows but then jump on you on another platform. Like in this port, I was obliged to make additional checks against bad data which was pouring in into the performance history graph data set at startup on Linux.

In a multihreaded interrupt kernel module system like Linux and certainly likewise in MacOS (on which I have no programming experience) things do not happen in same order than on a Windows box. We are doing it the hard way, the hardest possible, I would say! But let's do it !

I was looking the code and maybe the destructor in macOS environment is not calling, or is not calling in the right order

bool tactics_pi::DeInit(void)

Put some log file debug prints around:

    if (m_pRoute){
        m_pRoute->pWaypointList->DeleteContents(true);
        DeletePlugInRoute(m_pRoute->m_GUID);
    }

Now, if that fails for some reason, maybe the hanging WP makes somebody else confused at next startup?

That's my five pence worth. Good luck!

[rgleason]

Canne, I am going to try your commits so far.


Right now I am considering making sure that Tactics has all data that the Dashboard instruments have, (albeit in a more consolidated form). Then a user could load Tactics and simply disable or remove Dashboard. This is less ambitious than replacing Dashboard completely, but does permit continued development free from the program releases, and provides for a period of testing, and does not require bdbcat or anyone to make a decision.

I have not compared the instruments in Dashboard to Tactics Instruments, but can do that. Canne and Ron, you've been more active on this plugin lately, have you already done this comparison perhaps?

[rgleason]

PS: Have you guys seen this PR to tom_r


https://github.com/tom-r/tactics_pi/pull/18

[rgleason]

The Dashboard Instruments that are not included with Tactics are:

1. Local GPS Clock
2. Local Sunsrise/Sunset
3. Moon Phase
4. Rudder Angle
5. Rudder Angle (dial)
6. Air Temp
7. Cursor
8. GPS Clock - Tactics has "Clock" which might be this one.
9. GPS in View
10. GPS in Status
11. Local CPU Clock
12. Sun Log
13. Trip Log

How hard would it be to include those in Tactics?

[rgleason]

Petri's [Canne] recent changes have been merged and built in my Canne-perf-improvements branch and the file in Appveyor Artifacts for those Windows Users who wish to test is https://ci.appveyor.com/project/rgle...4611/artifacts. Please add "-ov50" to the filename as it is for Opencpn v5.0 and is a beta test file.


@Ron and Petri
Tom-r Tactics Repository has "Issues"

https://github.com/tom-r/tactics_pi/issues
and I think some of them can be closed. Do you have any thoughts about these?

[Canne]

Originally Posted by rgleason

Canne and Ron, you've been more active on this plugin lately, have you already done this comparison perhaps?

I made the first attempt to a) isolate dashboard_pi, b) port tactics class modules I mentioned earlier. It compiles with stripped header files (here) and starts (with all tactics_pi instruments commented out).

Main work will be to strip from tactics_pi the code for the instruments which are already in dashboard_pi (which I back-ported last week in it...). Not negligible effort is with the huge number of persistent parameters and settings tactics_pi is having compared to dashboard_pi.

In the test above I was thinking to launch tactics_pi classes only if user wants them: they have all timed call-back functions which are pretty active. They don't even go away when you close tactics_pi! Non-performance oriented user does not want to see all that blinking. But tactics classes would belong to dashboard_pi. This would meet with your requirement

Originally Posted by rgleason

...making sure that Tactics has all data that the Dashboard instruments have...

That's going to be a background project because the current situation is not maintainable and I feel quilty (but only a little bit) . However, it is not the end of the world to use both: tactics_pi for the fun and the built-in dashboard_pi when cruising.

[Canne]

Originally Posted by rgleason

PS: Have you guys seen this PR to tom_r https://github.com/tom-r/tactics_pi/pull/18

Yes, and I agreed with tom_r comment to it: "tactics_pi is a fork of dahboard_pi, I want to keep both in synch as much as possible, I will merge your pull request as soon as it is merged in dashboard." - that was motivating my back-port effort: it should be fixed in dashboard_pi first and if considered necessary there, it shall go back to tactics_pi. Was it considered in dashboard_pi during the past three years since the aforementioned pull request? If yes, now I've back-ported it (without even thinking).

In the long term, this back-porting thing is doomed, of course. Too much and too error prone copy-paste work.

[rgleason]

Originally Posted by Canne

I made the first attempt to a) isolate dashboard_pi, b) port tactics class modules I mentioned earlier. It compiles with stripped header files (here) and starts (with all tactics_pi instruments commented out).

Main work will be to strip from tactics_pi the code for the instruments which are already in dashboard_pi (which I back-ported last week in it...). Not negligible effort is with the huge number of persistent parameters and settings tactics_pi is having compared to dashboard_pi.

In the test above I was thinking to launch tactics_pi classes only if user wants them: they have all timed call-back functions which are pretty active. They don't even go away when you close tactics_pi! Non-performance oriented user does not want to see all that blinking. But tactics classes would belong to dashboard_pi. This would meet with your requirement That's going to be a background project because the current situation is not maintainable and I feel quilty (but only a little bit) . However, it is not the end of the world to use both: tactics_pi for the fun and the built-in dashboard_pi when cruising.

Petri, I'd like to understand your current effort with regard to tactics and dashboard.

Main work will be to strip from tactics_pi the code for the instruments which are already in dashboard_pi (which I back-ported last week in it...)

• I agree about the points about maintaining the code
• So to run Tactics..you will need to also have Dashboard open to get those instruments?
• Also Tactics has consolidated and improved many instruments, so I hope that functionality won't be lost.
• Certain instruments may have additional functionality to show things graphically at the boat.

Not negligible effort is with the huge number of persistent parameters and settings tactics_pi is having compared to dashboard_pi.

• This is what I am concerned about losing.

In the test above I was thinking to launch tactics_pi classes only if user wants them: they have all timed call-back functions which are pretty active. - They don't even go away when you close tactics_pi! Non-performance oriented user does not want to see all that blinking.

• This is a reasonable point. RPI users might not be too happy about it.
• I thought the main issue is the History Graphs and you guys just fixed them.

Call back functions -- They don't even go away when you close tactics_pi!

• That doesn't sound too good. Why don't they? Which Instruments?
• If there were a way to fix this programmatically, couldn't we just add the functionality of the unique Tactics Instruments into Dashboard and allow the user to select the instruments they want? Then RPI users could chose whether or not to Add an Instrument!

Additionally, Ron was talking about WatchDog being the Alarm and History Graphs and having a Instruments History Database that could be accessed. We also have a request for longer histories. There is one other history type plugin that should be looked at while thinking about the big picture and that is Sean's "Plots" which is pretty good and Sean has programmed these plugins through many iterations and he has used low powered computers pretty much exclusively.

I think Sean uses some different programming techniques for Plots that might be better, but you guys would know better than I.

It is certainly worthwhile thinking and discussing about the bigger picture and having an approach before going off willy nilly programming wholly new stuff.

[rgleason]

Originally Posted by Canne

Yes, and I agreed with tom_r comment to it: "tactics_pi is a fork of dahboard_pi, I want to keep both in synch as much as possible, I will merge your pull request as soon as it is merged in dashboard." - that was motivating my back-port effort: it should be fixed in dashboard_pi first and if considered necessary there, it shall go back to tactics_pi. Was it considered in dashboard_pi during the past three years since the aforementioned pull request? If yes, now I've back-ported it (without even thinking).

In the long term, this back-porting thing is doomed, of course. Too much and too error prone copy-paste work.

Thanks, we are in good hands I think, and I agree about the maintenance issues. If we can clarify that it will be a step in the right direction. We just don't want to lose Tactics functionality.

-- So if tom_r consolidates an instrument IE App/True Wind Angle & Speed Dials or App/True Wind Dir & Speed Dials or App and True Wind Angle and those can be moved to Dashboard without affecting Tactics features, that would be fine!

I guess Tactics_pi then becomes the key essentials:
Graphics at the boat (laylines, polar, etc)

• Average Wind (?)
• Actual CMG
• Actual VMG
• Polar Performance
• Polar Speed
• Target CMG
• Target CMG Angle
• Target VMG
• Targe VMG Angle
• TWA to Wpt
• Leeway
• Heel
• From Ownship
• ...?

Without reduction in the key Tactics features?
Then Dashboard is for cruising and not taxing on the CPU.
Tactics added for Racing instruments and boat graphics?


BTW - Please note how Tom-r defines VMG and CMG and don't get them mixed up!

[Canne]

Rick, regarding my intentions I can only refer to my previous brainstorming

Originally Posted by Canne

...IMO the best approach would be to import the four main Tactics_pi functions into Dashboard plugin. Not that big task - polarcompass.cpp, bearingcompass.cpp, performance.cpp, avg_wind.cpp: class tactics.cpp (ex. tactics_pi.cpp) would be the carrier for those. It would be instantiated only if "Dashboard performance mode" or similar would be selected, in which case boat's polar file would be asked to feed tactics...

I cannot explain the non-functional part better, see draft code's dashboard_pi.h which includes tactics_pi.h - that says it all. Functionally, nothing will be lost, none of the Tactics functions or algorithms will be lost and all tom_r's efforts will be conserved since they would run in different namespace than Dashboard. This approach would make, however, that one cannot mix instruments from two classes, tactics and dashboard in the same instrument window pane. That can be a show stopper.

I don't even yet know how to launch Tactics optionally from Dashboard but that would require reinforcement of its constructor and desctructor of the former: I am referring to its timer based functions which are drawing, among other things wind barbs, polar circle, and even laylines continuously around the own boat even if the tactics_pi has been stopped. TBD if this is a mandatory requirement.

I will try, slowly, to integrate one single instrument or function from tactics into dashboard_pi. Then we will see. Meanwhile, anybody brave enough can fork my early attempts, the GUI is pain in the neck for me...

I am not competent to put my nose in the system architecture discussion since I am only studied the instruments part, but I agree with long-term overhaul suggested by transmitterdan in an earlier thread. I would add in the wish list a global state machine for the opencpn engine and clear requirements for the plugin-specific state machines and transitions between them. This way, one could run plugins and even single instruments à la transmitterdan in their own threads so that they could be forked, started, stopped and killed as the opencpn main process wishes. Maybe for ov60... for now, I forget what I said!

[transmitterdan]

I think we need to slow down a little and decide what is the end game here. For example, we should not remove true wind gadgets from tactics_pi. That is because tactics generates true wind if it can whereas dashboard does not.

I have a suggestion but it requires David R. to decide if the suggestion makes sense. My idea would be to make dashboard_pi into a plugin that uses a plugin framework and links to a panel and gadget library as a dll or shared object. This is kind of like opencpn.lib works now but as a shared library. The gadget library could also be used by other plugins and those new plugins could add new gadgets by deriving from them. This is a lot of work and may exceed the collective talent of the current set of tactics_pi contributors.

[rgleason]

Petri and TDan, thank you both for all your contributions. Petri's approach seemed fine to me, but TDan's suggestion also sounds good. The discussion has moved beyond me. I'll just listen and help where I can.


Petri thank you for describing what your plan is/was, I liked this part too "all tom_r's efforts will be conserved since they would run in different namespace than Dashboard" and I thought the approach would be workable from the user point of vidw. I understand the programming aspects were being worked out.

[Canne]

Originally Posted by Canne

...it is not the end of the world to use both: tactics_pi for the fun and the built-in dashboard_pi when cruising.

Progressing slowly is fine with me: I will study if the painful back-porting can be avoided in the future by merging the common parts; maybe I will fail. A solution exist for the performance hungry, so the merger is only a background project for me; the end user does not care. I am available if I can help further with tactics_pi, like for bug fixing, of course.