Starfinder Playlist
Page 1 of 2 12 Last

Thread: Ruleset bug

  1. #1

    Ruleset bug

    Hi, I'm seeing an issue with <script> tag in a <windowclass> merge="join" situation getting skipped and not run. ( caused by 2 extensions changing the same windowclass, I've made a cut down simple version.. )

    Included in the zip is a 'campaigns' folder and 'extensions' folder, with the data needed and some images.

    The 'ext' campaign, is configured to start with just 5E ruleset to show 'normal' operation... see included '5e.PNG'.. You should 'open' character 'bob' from the pc or hotbar link and open the 'actions' tab.. as this is tested with 'char_weapon' class...

    To see the issue, repeat loading the campaign but now enable 'ext1', see included 'ext1.PNG', this extension adds a script to 'char_weapon', and makes the damage view much taller than normal... and the script output 'ext1 - onInit', because this overrides the ruleset 'char_weapon.lua' onInit.. the ruleset version is not 'run' and you will see the 'damage' box showing 'No text'.. this is as expected..

    Now if you re-run the campaign, but DISABLE 'ext1' and enable 'ext2', see included 'ext2.PNG', this extension does not add a <script>, but does make the damage view 'wide', but because I have not used a script the ruleset onInit is called and you can see the damage text in a wide damage view.. this is as expected..



    Now the issue comes when you run the campaign and enable BOTH ext1 and ext2, see included 'ext1+2.PNG', in this you can see both extensions load, the damage box is 'tall and wide'...

    BUT you do not see the 'ext1 - onInit', which should be called and override ruleset causing no damage to be displayed... in fact you can see the damage line and the 'ext1 - onInit' output is missing from the chat widow.. because the 'script' has not been run...

    because the damage line is both tall and wide, its clear both extensions have 'merged' joined ok... but the ext1 'script' has not been called causing a functionality error..


    [ As an extra, if you edit ext1 to be <loadorder>80</loadorder>, so that ext2 loads before ext1, you will get a tall and wide blank damage line and the 'ext1 - onInit', see 'ext2+1.png', attached loose as I thought to add this after I made the zip. ]

    This is causing a 'conflict' error between one of my extensions, and a different persons extension, because my <script> does not get run and so does not patch up and merge functions to provide the extension on top of the ruleset.

    While I can change the load order of my extension, since only my extension is adding a <script> file, this should 'merge' in any order and make the same result ? ( Or I'm I miss-understanding how merger works some how ? )

    [ in reality, multiple extensions should be able to add <script> and merge ok with the ruleset ? ]

    Thanks, Pete
    Attached Images Attached Images
    Attached Files Attached Files

  2. #2
    If you use this version of ext1 in combination with the ext2 from the original post, and enable both ext1 and ext2, you will get a console error for a missing file which is the <script> file in ext1.. see file.png ( from FGU )

    I would guess that <script file="campaign/scripts/char_weapon.lua"/> been the name of the file in the ruleset, that maybe its falling back to 'find' the rulesset file instead of the one in the extension..



    If you do this in 'FGC' the clipboard show..

    Ruleset Warning: Could not load script file (Extension: ext2) (campaign/scripts/char_weaponP.lua)
    Ruleset Warning: Could not load script file (campaign/scripts/char_weaponP.lua)


    Which might be an issue because that file and the script tag in actually in ext1..... And so does not exist in ext2 folder tree...


    I dont think this is 5e rule set related, but i have not had any goes at re-creating in any other ruleset.

    -pete
    Attached Images Attached Images
    Attached Files Attached Files

  3. #3
    By design, onInit only gets called on the most recently defined script. If you want the extensions to work with each other, you'll have to each add "if super.onInit then super.onInit(); end" to the beginning of each of the onInit calls in each of the extensions. (or use load order to define a load order so you know for sure which one loads first.) This also applies to any other functions overriden in the window script.

    Regards,
    JPG

  4. #4
    Quote Originally Posted by Moon Wizard View Post
    By design, onInit only gets called on the most recently defined script. If you want the extensions to work with each other, you'll have to each add "if super.onInit then super.onInit(); end" to the beginning of each of the onInit calls in each of the extensions. (or use load order to define a load order so you know for sure which one loads first.) This also applies to any other functions overriden in the window script.

    Regards,
    JPG

    I think the fact that on there own both extensions work fine, but together I get,


    If you do this in 'FGC' the clipboard show..

    Ruleset Warning: Could not load script file (Extension: ext2) (campaign/scripts/char_weaponP.lua)
    Ruleset Warning: Could not load script file (campaign/scripts/char_weaponP.lua)



    The fact its trying to load the char_weaponP.lua from ext2, when its in ext1 is the reason it does 'load the script', and because it does not load the script it clear can not call onInit or super.onInit....

    either some odd reason why the script file should not load due to my source, or an issue at FG side...

    it fails to load the script in both FGU and FGC.... the FGC has been provided as it provides more details..

    -pete

  5. #5
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,362
    I see what you're saying.

    It looks like when joining/merging windowclasses more than once that the <script> file must be the same name as the underlying script file in the lower level <windowclass> entries.
    Last edited by Trenloe; September 15th, 2020 at 10:04.
    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!

  6. #6
    Quote Originally Posted by Trenloe View Post
    I see what you're saying.

    It looks like when joining/merging windowclasses more than once that the <script> file must be the same name as the underlying script file in the lower level <windowclass> entries.
    Hi, yep, if you use the ext1 from post #2, this has the renamed script which then causes the file not found..

    As you say when the filename is the same as previous <script> levels its hard to tell what FGC/FGU has actually loaded as the script file... it just looks like it does not work.. my guess is that it still does not load my <script> file and drops back to the ruleset base script source... but this is very hard to tell with no error output or init call.. ( and the ext2 no onInit and hence no super.onInit call in anyway.. )

    For me the fact that ext2 loaded second which has no <script> and hence has no "onInit", then if its not calling the super version, ie the one in ext1 loaded before it, then basically the ext2 'stalls' the onInit calling tree..

    A lot of the <windowclass> type scripts, just throw in local function direct in the scrip, and dont use the <script> include to set up bulk code... and normally dont have an onInit function, which will the cause 'inheritance blocking' lack of down the tree....

    So extensions that dont apply <script> tags need to have a low load order, but if its complex extension other parts of it might require a higher load order to load it later.. so you need to 'split' this into 2 extensions to cope with both requirements.

    Should <windowclass> that dont have <scripts> and no onInit, do these not by default just call up the 'super.oninit'... or in reality the lua should still be pointing to 'previous' <script> oninit loaded and call that ??

    [ Also not sure on your post above, my email notification gave me a totally different post from you 'I've loaded up the campaign and extensions from post #1 (thanks for providing this)...' which I can not see in the forum, did you edit the post ? ]


    -pete

  7. #7
    ive added a set of files with the renamed <script> file 'char_weaponP.lua' with both extensions enabled, load ext1 then ext2..

    in the png you will see unity 'fails to find the file' and hence can not even start to run my onInit. ( as you say this might not get called due to ext2 not having a <script> tag or providing any onInit/super.onInit call tree.. )

    I assume that because it tries to load the script from the wrong extension path location and hence does not find it, i 'ASSUME' when the non 'P' version of the file is in place and it 'SEEMS' to load it... its actually still not finding the file but silent from my view.. ( it might silently load the ruleset version that is called the same, so it 'finds' some previous loaded version to run.... very hard to tell from my side without log access for file opens.. )

    So we do need to find out if it 'needs' to be called the same, and documents need to 'insist' developers use that filename for ever... or we need to decide what happens with a <script> tag of a different name, and how that interacts with extensions that load later and might or might not provide <script> and/or use onInit tags etc...

    otherwise it very easy to 'break' extensions from loading... and its a constant issue to re-upload with different load orders to resolve it...

    made even worse, that these 2 extensions while changing the same <windowsclass> they change different parts which do not 'clash' in any way... but the current code is 'forcing' an implicit binding between the extensions which should not be required.

    -pete
    Attached Images Attached Images
    Attached Files Attached Files

  8. #8
    Thanks for sticking with this. Your simple example has allowed me to understand what you are saying; and helped me pinpoint what is happening. It's not that the extensions are forcing implicit binding; it's the fact that the script "file references" appear to be getting overwritten when merging window classes.

    Originally, I assumed that this was something FGU-related (because that's what I'm mostly focused on); but this one actually appears to be the other way around and inherited from FGC. It has been that way for many years, which makes this a little more complex. Window class merges were added on top of the original system, which didn't need to worry about script file reference merges (i.e. extensions originally had to fully define window class replacements).

    I'm actually surprised that this hasn't come up more; but I think that the very specific circumstances (extension only, multiple merge window class, scripts, load order) and the default ruleset file load prevented it from being that big of an issue most of the time.

    I'll look into what I can do; but it will take client updates on both FGC and FGU to address.

    Regards,
    JPG

  9. #9

  10. #10
    Quote Originally Posted by Nylanfs View Post
    Yay! Obscure bug, Corner case!
    I have another, but i'm keeping it for later !!

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
  •  
FG Spreadshirt Swag

Log in

Log in