DICE PACKS BUNDLE
Page 3 of 7 First 12345 ... Last
  1. #21
    The client-side CT functionality is still broken, working on a fix...

  2. #22
    I might need an assist. Now that combattracker_client has merge="join" on it, I can't figure out how to change the ordering of the labels and the client_ct_entry controls. I've been trying to figure this out for a couple hours now, and I guess I just don't understand how the merge stuff works. If someone could pop open the extension and look at ct_client.xml and clientct_entry.lua and give me a hint, I would really appreciate it.

    For the column labels, what's currently in the extension seems to produce a union of what's in 3.5 and what's in my extension, which I assume is the default join behavior. The two problems are 1) getting the Injury label to appear at the right instead of next to Order, and 2) removing the nonlethal label.

    When I tried to do 2) with merge="delete" it seems that the label is implicitly referenced somehow? I got script errors saying it was nil, but when I searched the 3.5 ruleset I didn't really find any other references to it.

    I couldn't figure out any way to do 1), neither merge="add" or merge="resetandadd" seemed to make any difference.
    Last edited by darrenan; September 25th, 2017 at 07:04.

  3. #23
    The 'merge="join"' means that it is making changes to the same windowclass in the CoreRPG ruleset. That's where you'll find the controls and code you are looking for.
    I never claimed to be sane. Besides, it's more fun this way.

  4. #24
    That part I understand, I wasn't looking for the windowclass in corerpg. I'm asking how to correctly change/override it to match the previous functionality of this extension.

  5. #25
    Maybe my confusion is coming from the interaction between merge semantics and how extensions operate. I thought that extensions simply replaced entire ruleset files all-up i.e. no layering. But that doesn't seem to be the case. When replacing a windowclass that already has a merge on it, is it then doing another merge as part of applying the extension?

  6. #26
    Extensions are really just another layer, so they work almost identically to the ruleset layers.

    Since multiple ruleset layers and extensions can all use the same file names, you can't just replace files wholesale. You actually need to re-specify the asset tags for which ones you are trying to change. Even if you are just overriding a script file, you have to update the asset tags. Asset tags include global scripts, window classes, templates, fonts, icons, frames, ...

    For window classes, you can use no merge tag (to replace fully), merge="join" (to modify in place) or merge="delete" (to remove). When using "join", scripts are nested (like templates), and controls within sheetdata tag are matched by tag name and name attribute.
    For all the other assets, you can only replace.

    Hope that helps,
    JPG

  7. #27
    Ok, so in the 3.5 ruleset, the combattracker_client windowclass is defined in CoreRPG, and then 3.5 merges in some additional elements using merge="join". What I want to do is replace/overwrite the stuff that 3.5 joined in. That would be a skip-join for lack of a better term i.e. join my new windowclass with the one in CoreRPG, and bypassing the 3.5 stuff. Is that even possible?

    It also seems very hard to insert elements in a particular place. In this case, the definitions of the labels and controls in combattracker_client and client_ct_entry are very order-dependent and I'm having trouble figuring out how to get my new Injury label and control to render in the right location relative to the other ones.

    What happens if I define windowclass combattracker_client in my extension with no merge attribute (where the corresponding 3.5 element has merge="join")? Does it replace everything from CoreRPG and 3.5? I'm beginning to think that doing a hand-merge of those two windowclasses from CoreRPG and 3.5, then applying my changes, is the only way I'm going to be able to get back to my previous functionality.

  8. #28
    Is it intentional that the client CT is using the CoreRPG string "Order" instead of the 3.5 string "Init"?

  9. #29
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,362
    Quote Originally Posted by darrenan View Post
    It also seems very hard to insert elements in a particular place.
    This is something I sent to Dulux Oz over a year ago:

    So… looking at the 3.5E ruleset, there’s a new field I’ve never seen before:

    <button_checkbox name="showonminisheet" insertbefore="carried">

    So, it can be done. Here’s the new merge windowclass just to add one button before the carried control:

    <windowclass name="char_invitem" merge="join">
    <sheetdata>
    <button_checkbox name="showonminisheet" insertbefore="carried">
    <anchored width="12" height="12">
    <top offset="6" />
    <right parent="rightanchor" anchor="left" relation="relative" offset="-5" />
    </anchored>
    <default>1</default>
    </button_checkbox>
    </sheetdata>
    </windowclass>

    Awesome! That will make relative anchoring through templates/merging a lot easier. ��
    Sorry that is just a contextless copy/paste from our discussion - I'm super busy at the moment. But the insertbefore tag should help to add new controls.
    Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!

  10. #30
    Thanks Trenloe. I had glossed over all the usages of insertbefore thinking they were related to screen layout/positioning, then, lightbulb...

    Unfortunately, the embedded scripts in ct_client.xml means I need to do a complete replace on the windowclass anyway. Even if I add a new version of the problematic function, the old one still exists as a super and references the inexistent control causing script errors. So, I'm doing the hand-merge of combattracker_client and client_ct_entry and completely replacing both of them. It's going to make forward compatibility a bear, but I don't see any other way around it.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
STAR TREK 2d20

Log in

Log in