FG Spreadshirt Swag
Page 46 of 100 First ... 3644454647485696 ... Last
  1. #451
    SoxMax's Avatar
    Join Date
    Mar 2021
    Location
    Massachusetts, USA
    Posts
    154
    I think the best bet is still to have Extended Automation be a sort of "master extension" and then have Strain Injury and Alternative Icons be additional extensions to the core Extended Automation extension. This would maximize your code reusability and result in the fewest github repos to maintain. Though that would be a pretty big change for current users of your extensions.

  2. #452
    Quote Originally Posted by SoxMax View Post
    I think the best bet is still to have Extended Automation be a sort of "master extension" and then have Strain Injury and Alternative Icons be additional extensions to the core Extended Automation extension. This would maximize your code reusability and result in the fewest github repos to maintain. Though that would be a pretty big change for current users of your extensions.
    About the icons as separate extensions we once spoke, but writing straininjury as an extension on top would be a mammoth project since there are a lot of changes in StrainInjury also affecting the codes of extended automation (StrainInjury affects so many files that one could start to argue to make it a .pak I actually also plan to release my homebrew extensions which is straininjury plus extras, and I will probably release this as a ruleset instead. But this is just some fun project I may have)

    At the moment I may simply just keep one Extended automation and one version with straininjury Then the code pull requests can be added to them and the versions with other overlays are simple enough done manually as usual

    (About overlays: A separate extension just overwriting overlays still requires that the "alternative users" need to download certain files twice; and I am not sure how this affects the FG RAM usage because, if I am not mistaken, overlays are loaded into RAM, such that they are ready to use. I wonder whether overwritten files are not loaded into RAM? But if both versions are loaded into RAM, then I'd still prefer the current approach.)

  3. #453
    SoxMax's Avatar
    Join Date
    Mar 2021
    Location
    Massachusetts, USA
    Posts
    154
    Ahh, darn I hadn't realized how entwined StrainInjury was with the rest of the automation.

    For the overlays as far as transfer goes, you could have the core mod not have any extensions at all, or blank dummy files. Then make it so one must subscribe to an icon pack to get any icons. This would alleviate the transfer problem upon connection and allow you to maintain the code independently of any icons.

    But I may be overthinking it and just copying in new icons or using a packaging tool may just be easier.

  4. #454
    Quote Originally Posted by SoxMax View Post
    Ahh, darn I hadn't realized how entwined StrainInjury was with the rest of the automation.

    For the overlays as far as transfer goes, you could have the core mod not have any extensions at all, or blank dummy files. Then make it so one must subscribe to an icon pack to get any icons. This would alleviate the transfer problem upon connection and allow you to maintain the code independently of any icons.

    But I may be overthinking it and just copying in new icons or using a packaging tool may just be easier.
    hmm, this is actually a good idea, I didn't think about this

    Now I will think even more about it The only disadvantage may be of course that current users need to get aware of such changes if such a change is applied; but I will see

  5. #455
    Quote Originally Posted by Kelrugem View Post
    hmm, this is actually a good idea, I didn't think about this

    Now I will think even more about it The only disadvantage may be of course that current users need to get aware of such changes if such a change is applied; but I will see
    A solution to that would be a pop-up window that only shows up on first load which tells users they need to install an icon pack. But I think 2 extensions for everyone is perhaps worse than 2 extensions for some users. It would be great if you had stats on how many users use each version.

  6. #456
    Quote Originally Posted by bmos View Post
    A solution to that would be a pop-up window that only shows up on first load which tells users they need to install an icon pack. But I think 2 extensions for everyone is perhaps worse than 2 extensions for some users. It would be great if you had stats on how many users use each version.
    Hm, yeah, I see; by the forge the stats are currently: Original overlays at 199 subscribers, alternative one at 98, though there are surely people downloading both versions Hm, difficult to say what the best approach is, given that already many users are used to the given system

  7. #457
    SoxMax's Avatar
    Join Date
    Mar 2021
    Location
    Massachusetts, USA
    Posts
    154
    For generating multiple extensions from one github, I've been working on a packaging tool that could help.
    https://github.com/SoxMax/FantasyGroundsPackager

    It currently takes a directory and expects a single extension.xml file and pulls in all the files needed by the extension.xml
    It should be easy enough to make it so you can specify an xml directly and rename it to extension.xml during packaging. This would let you put the extension.xml for each version along with all the needed icons in one repo and then just point each extension.xml to the set of icons it needs.

  8. #458
    Quote Originally Posted by SoxMax View Post
    For generating multiple extensions from one github, I've been working on a packaging tool that could help.
    https://github.com/SoxMax/FantasyGroundsPackager

    It currently takes a directory and expects a single extension.xml file and pulls in all the files needed by the extension.xml
    It should be easy enough to make it so you can specify an xml directly and rename it to extension.xml during packaging. This would let you put the extension.xml for each version along with all the needed icons in one repo and then just point each extension.xml to the set of icons it needs.
    ah, nice, thanks a lot; I will take a look

  9. #459
    SoxMax's Avatar
    Join Date
    Mar 2021
    Location
    Massachusetts, USA
    Posts
    154
    Quote Originally Posted by Kelrugem View Post
    ah, nice, thanks a lot; I will take a look
    Sorry I just realized my post may be implying you can make that change to the packaging tool, let me know if you want me to make that change

  10. #460
    Quote Originally Posted by SoxMax View Post
    Sorry I just realized my post may be implying you can make that change to the packaging tool, let me know if you want me to make that change
    Oki No worries, I am not even sure whether I am capable of adding such a change (besides FG coding I basically never did any coding, so, basically unexperienced with everything outside FG )

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
  •  
DICE PACKS BUNDLE

Log in

Log in