[fixed] Path information for mixed movement group

[Lee]

Fixed bugs reported in this topic

Moving forward, "[fixed]" (on my posts) will refer to an issue fixed, but with the patch for it following at a later time as the file also includes other unrelated changes which I have not documented and fully tested yet; in other words, this post is a placeholder/notice for now, so that other devs will know what's been already done.

Using the supplied campaign file found on the post above, the group is made up of tokens that are either detached or snapped to the grid. The following are screenshots for proof-of-fix:

[spoiler=Movement led by unsnapped token][/spoiler]
[spoiler=Results][/spoiler]
[spoiler=Movement with way points][/spoiler]
[spoiler=Results][/spoiler]
[spoiler=Movement led by snapped token][/spoiler]
[spoiler=Results][/spoiler]
[spoiler=Movement with multiple steps][/spoiler]
[spoiler=Results][/spoiler]

Lastly, [wfunc]getMoveCount[/wfunc] now returns a value of 0 for newly dropped tokens on the map. If there are any questions, do feel free to ask.

[tiorthan]

This seems related to viewtopic.php?f=3&t=22719&p=232390#p232390

[Lee]

yes, I think it is. I hopped in here to grab the link to put it on that post to let you know that I was in that code area and will look into it

[jfrazierjr]

...stuff..

Replied to Private Message, hopefully with something helpful.

[Lee]

Thanks JFJ. It was.

Can I get this thread moved to the developer notes section? I think it being here without a patch to test makes it the wrong place for now. Changing the OP and title to reflect [fixed] instead of [patched]

[Lee]

@aliasMask Continuing on the fix illustrated on the first post, I was able to return precision as well have handling code for each mix context (e.g snapped key token w/ unsnapped followers). The problem with it was that I had to crossover the threshold and make changes to some critical model classes such as ones for Token and Path. An example was to incorporate an origin point for path computation. One would think that it wouldn't be needed, but it turns out that the token's coordinates get updated during the drag, losing valuable reference points along the way.

Since I mentioned that I was releasing 2 builds with all the fixes (1 for each UPnP candidate library), this is the last one I'll be applying before building the releases. So the question is, which is the preference here?:

a. Apply the simple fix mentioned on the 1st post and release the more complex path fix in my fork after 1.3 final.
b. Apply the "complex" fix now, knowing that it might not make it into 1.3 final. Due to it's nature, it'll take more time to do this.

On a side note, the problem with FoW and getMoveCount mentioned in related discussions have also been handled. Let me know what's okay with you. I'm partial to a., if only to have something out right away.

Thanks.

[aliasmask]

At this point we've lived with it the way it is for awhile, so the simple fix to get things out sooner is preferable. The path update has a work around as well and it is also in relation to a semi-fringe case.

[Lee]

Alas, I spoke too soon. After extracting the fix from my fork, even the simpler fix made a change to the Token model. I'll detail what this means for people who don't know on the patch post.