FG Spreadshirt Swag
Page 3 of 4 First 1234 Last
  1. #21
    You can do the brute force way I do it with common code. You make sure its copied everywhere you need it. That way an extension is self contained. Nothing is more irritating and confusing (and likely to cause problems for users) than making something dependent on something else to run when it could run on its own. Especially the load order works (someone can always sneak in between your code and your "common" code).

    Now if you plan on always delivering your common code with your other code and have that code validate that it is out there before it blows up trying to do something with a message stating it can't run because extension xyz has to also be loaded and your careful to call the original code your overriding (if possible) - then you can get away with what your doing without confusing things.

    Personally I like brute force stupid way I do it and just copy any shared functionality - especially because experience has taught me even shared functionality eventually diverges. In my world anyway. Good luck with whatever you decide to do, choose what YOU are most comfortable with.

    [And of course I can imagine no greater nightmare than having one up to date and one out of date - safer to just put in common .lua and include with extension.xml]
    Last edited by SilentRuin; October 3rd, 2022 at 16:30.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  2. #22
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,361
    Quote Originally Posted by UrsaTeddy View Post
    Extending LUA objects is expected in LUA development AFAIK.

    However I understand your concern and if I ever get to the publishing stage, I would most likely change the extending of the LUA objects to something else if it was an issue.

    I have created an extremely stripped down pair of extensions that show the issue very simply.

    Load each one individually you will see output in the Console.

    Load them together and the Console will open with an error.

    DSC_SWADE_105.ext

    DSC_SWADE_110.ext

    For some reason the URL tags do not load the attachments, however if you copy the URL and paste it in a new window it does.
    Thanks for providing this - it really helps in troubleshooting and being on the same page.

    If you change the 105.lua code to use the _100_string Global Script Package, it works fine (running the code from 110), that is: Debug.chat(_100_string.concat('---','one','two','three'))

    EDIT: see next post.
    Last edited by Trenloe; October 3rd, 2022 at 17:01.
    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!

  3. #23

    Join Date
    Mar 2020
    Location
    Sydney, Australia
    Posts
    247
    Sorry, I should have added in another library file instead of just string and table.

    It occurs with my own libraries, not just extended LUA types.

    In this case any aliases I create within my own libraries fail when loading both extensions.

    The updated extensions are in the previous locations ...

    In the updated code, if I access inc.constant (which is an alias to inc.add) it fails when both extensions are loaded ... if I access the original method it succeeds.

    This is definitely not expected behaviour ...

    As Moon Wizard suggested, I think this has to do with the "overwriting" of the common library code when the second extension loads with the "new/old" common code. Thus the onInit() of the original loaded code from 105 is not executed since it was replaced by 110.
    Thanks In Advance,
    D

  4. #24
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,361
    Follow up... thinking about it, the issue is probably related to the order of overridden script being executed - not related to overriding the LUA string object. Moon Wizard should be able to comment on that.

    If all you want to do is override the LUA string object then you can do that in the onInit function of Global Script Packages with different names - you can still use the functions in the same Global Script Package _100_string, that would be overridden by the later loaded extension but the public functions would be accessible, but you'd need to run the onInit code that extends the LUA string object outside of _100_string
    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!

  5. #25
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,361
    So, do something like this in a LUA file that won't get overwritten:

    Code:
    function onInit( )
    		-- Extend LUA string
    		string[ 'mid' ] 		= _100_string.mid
    		string[ 'left' ] 		= _100_string.left
    		string[ 'right' ]		= _100_string.right
    		string[ 'split' ]		= _100_string.split
    		string[ 'trim' ] 		= _100_string.trim
    		string[ 'concat' ]		= _100_string.concat
    
    		-- Convenience alias
    		string[ 'fget' ] = Interface.getString
    end
    You could even check if the extended function has already been instantiated. For example:
    Code:
    if not string[ 'mid' ] then
         string[ 'mid' ] = _100_string.mid;
    end
    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. #26

    Join Date
    Mar 2020
    Location
    Sydney, Australia
    Posts
    247
    Yes, however that would mean that every extension I write would have that specific onInit code written multiple times in non-overwritable files.

    One question.

    You will note that in my files I have a semaphore indicating if that file has been executed or not ... that semaphore is not set in the global space, so if I renamed the file and loaded it under another name, all the code is executed again and the semaphore is reset to false.

    Is there a global space to do this in? Or do I have to make my own system?
    Thanks In Advance,
    D

  7. #27
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,361
    This all goes back to what I said in my earlier posts - everything is loaded into FGs memory first - with Global Script Packages being overwritten by later loaded files, and windowclass/controls having layered scripts; then once all files have been loaded, the files are executed in order.

    In this instance, as the string['mid'] is only setup in the onInit function within the _100_string Global Script Package, and the active file for _100_string is in the 110 extension, the onInit function of _100_string only gets executed when the code in 110 is executed (not when it's loaded into memory, when it's executed later) which is after the not overridden code in 105 is executed. So, making a call to string.mid in 105 results in the error. However a call to _100_string.mid in 105 works, as the public functions of _100_string are loaded into memory and accessible.
    Last edited by Trenloe; October 3rd, 2022 at 17:24.
    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!

  8. #28
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,361
    Quote Originally Posted by UrsaTeddy View Post
    Yes, however that would mean that every extension I write would have that specific onInit code written multiple times in non-overwritable files.
    Yes, or move to using Global Script Packages rather than overriding LUA objects. Then you won't be instantiating overrides in onInit functions, you'll be making calls to the a specific Global Script Pacakge name (e.g. _100_string) which will point to the last Global Script Package of that name loaded into memory.
    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!

  9. #29

    Join Date
    Mar 2020
    Location
    Sydney, Australia
    Posts
    247
    It doesn't matter if I am using LUA objects or not ... as in the newest version I uploaded, it happens in any global object that gets setup in an onInit() ... in my case the inc object I created and any aliases to it which are setup in the onInit().

    This strictly has no connection to LUA objects but rather the method in which FGU overwrites scripts - which is perfectly fine and now that I know about it clearly enough, I have found a workaround that gives me what I need - a centralised code base - and handles the overwriting part of loading extensions.
    Thanks In Advance,
    D

  10. #30
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,361
    Quote Originally Posted by UrsaTeddy View Post
    It doesn't matter if I am using LUA objects or not ... as in the newest version I uploaded, it happens in any global object that gets setup in an onInit() ... in my case the inc object I created and any aliases to it which are setup in the onInit().

    This strictly has no connection to LUA objects but rather the method in which FGU overwrites scripts - which is perfectly fine and now that I know about it clearly enough, I have found a workaround that gives me what I need - a centralised code base - and handles the overwriting part of loading extensions.
    Sorry, I didn't spend the time to look into your newer files in detail. I was still carrying on the thought from the previous threads. I was just saying that the specific errors from the earlier thread aren't present if you move to using _100_string.mid instead of trying to use the extended string.mid before it's created.
    Last edited by Trenloe; October 3rd, 2022 at 18:00.
    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!

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
  •  
5E Character Create Playlist

Log in

Log in