Sasquatch upgrade to LW2020 compatibility?

[vncnt]

I just sent a desperate email to [email protected] begging for an upgrade from Sasquatch 64-bit to get LightWave 2018/2019/2020 compatibility.

Hence, I wonder if more users would be interested.

See also https://forums.newtek.com/showthread.php/163411-Uh-ohh-Sasquatch-in-LW2020

 

[Markc]

I didn’t think Worley where even about any more.....
I have FPrime and Taft from way back, but havn’t worked on Mac since about ver 9.6.

 

[Sensei]

I have FPrime and Taft from way back, but havn’t worked on Mac since about ver 9.6.

Because each version and revision NewTek developers are changing nodal access structure without maintaining compatibility,
so there is required update of the all nodes and the all node editor using plug-ins to handle new bigger extended structure..
In LW 9.x ... LW 2015.x it was called LWNodalAccess,
in LW 2018-2020 it was so dramatically changed that even changed name to LWShadingGeometry.

 

[jwiede]

Because each version and revision NewTek developers are changing nodal access structure without maintaining compatibility,
so there is required update of the all nodes and the all node editor using plug-ins to handle new bigger extended structure..
In LW 9.x ... LW 2015.x it was called LWNodalAccess,
in LW 2018-2020 it was so dramatically changed that even changed name to LWShadingGeometry.

Actually, no. The reason Worley plugins are broken on the Mac side past LW9.6 is because the LWSDK HostDisplayInfo return type changed when LW moved from using Carbon frameworks to Cocoa frameworks in LW 9.6.1, and Worley never got around to updating his Mac plugins for Cocoa-based HostDisplayInfo. Even if that were fixed, they'd also need fixes for subsequent UB64 and Mach-O changes in order to work on current Cocoa-based Mac LW 9.6.1-2015.x.

To work in Cocoa-based Mac LW2018+, they'd also need the changes Sensei mentions, but that's not what caused the break asked about (post-LW9.6).

 

[Sensei]

Actually, no. The reason Worley plugins are broken on the Mac side past LW9.6 is because the LWSDK HostDisplayInfo return type changed when LW moved from using Carbon frameworks to Cocoa frameworks in LW 9.6.1, and Worley never got around to updating his Mac plugins for Cocoa-based HostDisplayInfo. Even if that were fixed, they'd also need fixes for subsequent UB64 and Mach-O changes in order to work on current Cocoa-based Mac LW 9.6.1-2015.x.

To work in Cocoa-based Mac LW2018+, they'd also need the changes Sensei mentions, but that's not what caused the break asked about (post-LW9.6).

Worley in the all his plugins used some proprietary UI instead of what LW delivers. Porting from Windows to Mac is as easy as recompilation, if you're not using OS directly to do some stuff. But if you use some proprietary UI toolkit... you've damn troubles..

LWSDK's HostDisplayInfo global just contains window pointer. Pretty meaningless for 99.9% of plug-ins. Because you never ever touch OS directly.. but custom made UI toolkits may need it...
I could count on one hand how many times I needed HWND window pointer in some plug-in..