PDA

View Full Version : Question about Modules



heyhogan
December 11th, 2014, 03:28
I have noticed that if I edit a module while in one campaign, these changes persist even if I close the module and open it again in the Library, or enter/exit the campaign. However, if I exit the campaign and start a new one, the module is back to the way it originally was. Is there a way "update" a module, or do I need to open the original adventure module, make changes, and then export it again?

Also, I noticed that a lock icon appear in the upper right hand corner. It appears to lock or unlock editing of the entry. Was this done to avoid accidental changes? Lock a story entry after you are finished and happy? Any other best practices on using this lock icon?

dulux-oz
December 11th, 2014, 07:04
I have noticed that if I edit a module while in one campaign, these changes persist even if I close the module and open it again in the Library, or enter/exit the campaign. However, if I exit the campaign and start a new one, the module is back to the way it originally was. Is there a way "update" a module, or do I need to open the original adventure module, make changes, and then export it again?

Also, I noticed that a lock icon appear in the upper right hand corner. It appears to lock or unlock editing of the entry. Was this done to avoid accidental changes? Lock a story entry after you are finished and happy? Any other best practices on using this lock icon?

Any data in a Module is Read-Only. However, FG is smart enough to save any changes made to Module Data in the Campaign Database, which "takes precedence" over the Module Database (the data in a Module is stored in a "Module Database" that is "merged" with the Campaign Database when you open a Module in a given Campaign).

Hence, if you "change" Module Data in a Campaign the changes will be "remembered" by that Campaign - and ONLY that Campaign. If you open the Module in a different Campaign the "changes" won't be "remembered" ie the Module Data is as it was originally.

Note that if you do make changes to Module Data in a Campaign then you can "reload" the Module Data so that the Campaign "forgets" the changes.

To enforce a permanent "update" on a Module (ie permanently change a Module) the Module needs to be opened up, the changes made and then the data put into a new Module (or the old Module needs to be re-saved/re-generated/re-exported).

Yes, the Lock is there to do basically what you said :)

Does that all make sense?

Cheers

damned
December 11th, 2014, 07:09
when you edit a module in your campaign the extra changes are in your campaign data file and not in the module itself.
in most cases to edit the module you would need to edit with a 3rd party editor like notepad++


EDIT: ninja'd

dulux-oz
December 11th, 2014, 07:13
when you edit a module in your campaign the extra changes are in your campaign data file and not in the module itself.
in most cases to edit the module you would need to edit with a 3rd party editor like notepad++


EDIT: ninja'd

Beat you too it! :P

heyhogan
December 11th, 2014, 14:35
OK Thanks. Hope the developers consider making a /updatemodule command in a future release so I can fix the typos without having to open up the ZIP files and use Notepad++.

Trenloe
December 11th, 2014, 14:42
OK Thanks. Hope the developers consider making a /updatemodule command in a future release so I can fix the typos without having to open up the ZIP files and use Notepad++.
Add it to the FG wish list: https://fg2app.idea.informer.com/

Of course, the problem here would be if you make lots of changes in one campaign, it might break the same module data already being used in another campaign. It would have to be done at an entry level only (i.e. not deleting entries, just modifying the bodies of the entries).

dulux-oz
December 11th, 2014, 14:45
Add it to the FG wish list: https://fg2app.idea.informer.com/

Of course, the problem here would be if you make lots of changes in one campaign, it might break the same module data already being used in another campaign. It would have to be done at an entry level only (i.e. not deleting entries, just modifying the bodies of the entries).

Even that might break some existing campaigns (depending upon what the Module holds and how its put together).

Trenloe
December 11th, 2014, 14:54
Even that might break some existing campaigns (depending upon what the Module holds and how its put together).
Yeah, it would probably be better if it left the original module and made a new one based off the original. If "it" is ever developed... ;)

damned
December 11th, 2014, 22:26
Yeah - I think it is a deliberate design decision. Both ways have pros and cons. I hear rumours of some alchemy in the works that might make this sort of thing lot easier in the future...

Ikael
December 12th, 2014, 08:27
OK Thanks. Hope the developers consider making a /updatemodule command in a future release so I can fix the typos without having to open up the ZIP files and use Notepad++.

Remember that if it's commercial module then next time you update your FG you would lose all your custom changes. The best way to deal typos is to let module maintainers/developers know about them so they can incorporate them into module. Just let us know which module where and what.

Nicohdemus
December 15th, 2014, 20:36
Remember that if it's commercial module then next time you update your FG you would lose all your custom changes. The best way to deal typos is to let module maintainers/developers know about them so they can incorporate them into module. Just let us know which module where and what.

OK, well here's a small typo... the Rippers module ranged weapons table lists the "Pistol" as 1d6 damage when the book says 2d6. :)