CT Sorting Bug

[Nickademus]

There is a bug somewhere in the sorting of the Combat Trackers when a custom sort is assigned and I can't find where it would even be. The code looks identical, but something is different.

Okay, so when I assign a value with CombatManager.setCustomSort(function), it uses that whenever CombatManager.onSortCompare() is called. The weird thing is, the Combat Tracker code and the windowlists inside the CT sort separately, yet both use the onSortCompare of the manager, but while both the internal sorted list returned by CombatManager.getSortedCombatantList() and the windowlist of host's CT display the proper order, the client's CT does not. Any entries that have the same initresult value are displayed backward to the clients. The picture below shows a custom sort that orders first by smallest initresult and second by highest dexterity score (and third by name). The order has been test and is properly displayed for the host (on the left), but as you can see, both of the duplicate initiatives on the client (on the right) are reversed.

Both CT lua files have the onSortCompare running the same code: "CombatManager.onSortCompare(w1.getDatabaseNode(), w2.getDatabaseNode())" so they should both appear the same. What could cause the two CT's to sort differently with the same sort function?

[celestian]

I use custom sorting because AD&D uses a lower is better initiative (reverse what 5E ruleset uses) and I had to use the custom sort function. I could have sworn it worked when I did this initially but perhaps something changed. I'm going to have to look on the client side and see if I see what you are.

[Moon Wizard]

I wouldn’t be able to tell without looking at the specific code.

Is this one of our rule sets, or an extension or rule set of yours?

Thanks,
JPG

[Nickademus]

I'm sorry. I should have specified. I'm using the 5e ruleset, but I believe all the CT code is from the CoreRPG CombatManager script.

[Moon Wizard]

Is this with a campaign without extensions? If so, could I get a copy of the campaign folder?

Thanks,
JPG

[Nickademus]

It is with an extension, as that is how you apply a custom sort to the Combat Tracker. I'll see if I can make a simple extension that does just the custom sort and see if it still happens.

[Andraax]

I noticed a similar thing with my updated sorting in Castles and Crusades. Sort is fine in the host, but wrong in the client. Was going to look at it when I got home from the con later this week...

[Moon Wizard]

Can I get a copy of one of the extensions or ruleset updates where you are seeing this issue? (and maybe a campaign as well for faster checking)

Thanks,
JPG

[Nickademus]

I feel like an idiot. I figured out where the error was. My understanding of the CT was wrong. Apparently the sorting function that the host and client CT use are not actually the same thing. The host sort is set by the host instance and the client is set by the client instance.

For some reason I had thought that setting the CombatManager on the host would affect the client, but the client has its own set of script objects. I needed to set the sorting function on the client's CombatManager as well. (At the time of posting this thread it was using a bugged version of the custom sort.) Updated the client's custom sort and it works fine now.

@Andraax
Make sure whatever modifications you are making to the sorting of the host is also affecting the client. If they come from separate files, make sure the sorting code is the same. If they come from the same file, make sure the function doesn't return early if the user isn't the host.

[Moon Wizard]

Yes, the host does not set any list sort order for the clients (for any lists). All sorting is completely defined in the ruleset code on each instance.

Glad you figured it out.

Cheers,
JPG

[Andraax]

@Andraax
Make sure whatever modifications you are making to the sorting of the host is also affecting the client. If they come from separate files, make sure the sorting code is the same. If they come from the same file, make sure the function doesn't return early if the user isn't the host.

I actually thought that was what the problem was, but just hadn't gotten around to looking at it yet. Probably tomorrow or the day after.

[Andraax]

Finally sat down and puzzled this one out. Turns out that the client and host were running the same code - however, the sorting routine was looking up the PC's dexterity, and the clients couldn't access that data, so they were always getting "0" for that value. I fixed it by adding a hidden field to the CT for the dex, and copying it in when a PC / NPC is dropped on the CT (actually I link those from the PC sheet, so updates to the dex are reflected immediately).

[celestian]

Finally sat down and puzzled this one out. Turns out that the client and host were running the same code - however, the sorting routine was looking up the PC's dexterity, and the clients couldn't access that data, so they were always getting "0" for that value. I fixed it by adding a hidden field to the CT for the dex, and copying it in when a PC / NPC is dropped on the CT (actually I link those from the PC sheet, so updates to the dex are reflected immediately).

I'm curious are you sorting initiative ascending or descending?

[Andraax]

Descending.

[celestian]

Descending.

Okay, was going to mention another issue I ran into with ascending but you'll not have that problem then ;)

[Andraax]

Well, it's always helpful to share information - I might run into a similar problem later.

[celestian]

Well, it's always helpful to share information - I might run into a similar problem later.

Think I mentioned it in another thread I had but it is in effects.

CoreRPG manager_effects.lua
Function "processEffects"

Specifically this line "if nEffInit < nCurrentInit and nEffInit >= nNewInit then" which had to be altered to "if nEffInit > nCurrentInit and nEffInit <= nNewInit then" to work properly.

Not specific to your issue here but if you had used ascending like I did you would also have this problem.

Effects would increment/expire on end of round but would not increment as they should on the initiative the effect was added/set. So if you had a "[ACTION]" effect that would normally expire on your turn... it wouldn't expire till the end of the round.

[Andraax]

I'm not changing the order in the original ruleset, so that is not something I would have to worry about, but I'll keep it in mind. Thanks.