The inside the core tool paths still use the API tool path functions. And the core tool path properties (color, line width, etc..) will be the default for any newly instantiated tool path control in the screen editor. We decided to move the tool path code directly in the GUI for a variety of reasons. Not the least of which is making a remote GUI that can operate the control on the machine. It is in the latest builds. I call it Mach4GUIR.exe. Very original. Not many people would have thought about appending an R to the Mach4GUI.exe.
Anyway, all jokes aside, GUIR doesn't currently have a tool path. But it will soon! And that just couldn't be done with the tool path in the local core.
But a version of the tool path does still exist in the core. It is just that our main GUI doesn't use it anymore. However, the static wxMach.exe GUI still uses the core's tool path.
We originally put the tool path in the core so that people who wanted to write their own GUIs didn't have to mess with OpenGL. They simply use our API.
You can't really create a new tool path control on the fly. But you can have one that is hidden and then show it. Mach Motion uses that technique in their screen sets.
I loved Mach 3. What a masterpiece it was. Art simply did an amazing thing when he created it. But Mach 4 is doing really well now as most newcomers are simply not going for Mach 3. And despite what people post here, there are a lot of people that were running Mach 3 making the move to Mach 4. Especially if they need something custom.
You are welcome for the new stuff. It is my pleasure. Stuff I have in mind for the future is 3rd order planner, tie the multiple instances together for true multi-path capabilities (Screw machines, Mill/Turns, etc..), and kinematics.
Steve