[Admiral MS]

I wanted to fix dynamic waypoints for other sexps than set-object-position and scripting. Changing every scripting function and sexp and getting it to work in multiplayer are a lot of code additions so I thought: Why not fix that dumb coordinate transfer problem somewhere else.

As every modification of a waypoint position outside of FRED happens to affect only its corresponding object, I made this patch that applies these coordinates to the waypoint position every frame during object position update. Luckily this change also handles updating coordinates in multiplayer. Making my earlier sexp changes obsolete I reverted them.

The patch won't add velocities to waypoints but these could be added rather easy if someone wants them.

Once again I'm waiting for someone to review and commit the patch.


[attachment removed and sold on the black market]

[Echelon9]

My first thought is, does updating position in this manner every frame have a meaningful impact on performance?

[Angelus]

now that we have dynamic waypoints, can we has dynamic dockpoints now? 

[The E]

What would those be?

[Admiral MS]

Actually I'm not sure about this myself (and I wanted to ask but forgot to write it - blame posting such stuff late at night  ). While a lot of similar actions are happening during object update, this might have enough impact (especially during missions with tons of waypoints) to be considered a bad idea for just a few - if at all - waypoint position changes.
As an alternative I thought about comparing the positions first and only set them if they are not the same but again no idea if that's any better.

[The E]

Not sure whether a comparison before update is a good idea (Just remember to do a comparison by checking whether position A - position B > epsilon, floating point vars being what they are).

Thing is, a simple assignment operation may be less expensive than doing three float comparisons.

[Goober5000]

...Okay, the better way to do this is by correcting the waypoint usage in sexp.cpp, as opposed to piling on an extra layer of functionality that changes the object behavior without fixing the underlying problem.

This is what I meant in Mantis with the comment "Additionally, there are similarly slightly incorrect uses of OSWPT_WAYPOINT throughout sexp.cpp which will need to be fixed as well."