Workaround for lost functionality of preventing them from moving Parcel - keep it non public as long as you can. Not really a work around - but meh - best can be done.
Printable View
Workaround for lost functionality of preventing them from moving Parcel - keep it non public as long as you can. Not really a work around - but meh - best can be done.
I like this. Glad FGU did this as I think it fits more inline with the rules. If you want this. Turn on party movement.
What are you talking about? I had an option that I could make fixed map parcels the party could not move. Like things to heavy etc. Turn on party movement? That destroys all ownership Assistant GM advantages and I NEVER use that as its a horrible option that lets others see things they should not as the only way to get NPC control (weak control).Quote:
Originally Posted by MrDDT
You replying to correct thread?
I'm finally removing FG Classic APIs that have not been documented in the wiki for 7 years. I tried to save all the API deprecations for all at once in the FGU client.
You can use tokeninstance.setPublicEdit to get the same behaviors.
Regards,
JPG
Wish I knew that before a few hours before game. I’ll try to reimplement the removed functionality later this week.Quote:
Originally Posted by Moon Wizard
V1.51 - FGU change - put back functionality removed in V1.50 - replaced tokeninstance setModifiable with setPublicEdit.
Functionality restored.
I've been using this recently as my players have a base now with parcels used as storage, mailbox and personal inventory. However it seemed that the players clicked the parcel TOKEN i assigned to it and them ran away with it. Any way to lock this without breaking their legs first?
There was but I guess you’ll have to check based on last few posts here. Last I checked it worked. But I guess if the lock button and tooltip describing it on map parcel sheet is broken again then it’s news to me.Quote:
Originally Posted by Indivi_duel
Since the last FG update, I now get an error when using this extension on every NPC tab. Control (npc_inventory) anchoring to an undefined control (contentframe) in windowclass (npc). This is with no other extensions enabled. I get a lot more errors when opening a parcel about (weight_label) and (encumbranceload) in (treasureparcel).
Honestly its been 3 years since DMSG forced all my extensions off their platform meaning noone could have bought one except from forge since then - GP has had 90% sale on forge since then for people to transfer over at least twice - i out of the goodness of m heart kept updating them for 2 years after DMSG as an extra pain in my *** - then 6 months ago those updates stopped working with tickets to DMSG with no results - i continually add new functionality to my extensions for my own needs which people get to take advantage for nothing….
GP is diplomatic. I am not. DMSG is dead to me ive gone above and beyond tring to managae this stuff.
When i get back im blasting those unbuyable misleading DMSG entrees to the outer rings of hell so they cease to exist.
Have a nice day.
I assume you were responding to me, but I don't know what you mean by at least half of that. I bought the extension from Fantasy Grounds Forge. Are you saying you will not be supporting the extension anymore because it is too much work?
If you have forge and the version number matches last delivered number on page 1 in the forum and you are testing with no other extensions then it works. Given the number of tepeated posts about dmsg whivh no longer gives correct version - and people running with oth othrr known busted extensions from meandunique i tiook a guess which of the common mistaken claims it was.
Well at least I have some context for the hostility now.Quote:
Originally Posted by SilentRuin
So I am on v1.52, running no other extensions, errors on npc pages and lots of errors opening parcels. This occurs in an existing campaign or a brand new one I just created right now. No chance that the bugfixes they released today caused more bugs or am I just lucky and the only one getting undefined controls?
If they truly busted this with FGU update out of the blue without even a grace TEST period after having just busted everything several weeks ago - they my level of pissed off just went through roof to point i need to consider whether i want to do tis extension stuff anymore at all. As it is im out for weeks yet and words cannot describe how screwed over i feel at this point.if what you are telling me is true.Quote:
Originally Posted by dmssanctum
I just tested ... I got no errors for any of that stuff in a new campaign OR an existing campaign. I'd guess dmssanctum has his copy of Map Parcel from the DMsGuild, so it's actually not updated because their system is still all f'd up ...Quote:
Originally Posted by SilentRuin
OR, it's another extension causing the issue. -- EDIT: According to Discord, this has been confirmed. It's another extension.
I can understand your annoyance, I used to maintain a small extension for attunement till they added it. I don't know why they mess with the anchor code so much. I don't know if their bugfixes caused new errors, or if I'm somehow getting an error from a bad version somehow. All I know is that a brand new campaign tonight still throws the same errors after multiple FG updates, verifying the extension version, and only running this map parcel extension. Perhaps someone else can test and report if it works or is broken for them too.Quote:
Originally Posted by SilentRuin
OK, so it was my own fault for tinkering with extensions again. I had an extracted version and so it was loading the old version not the updated one. I have got to remember to extract to another folder. Sorry for the confusion. At least I assume that will fix it after it redownloads all the vault files I deleted to verify they were updated.Quote:
Originally Posted by dmssanctum
Hello SilentRuin,
I really love this extension as it eases the "Loot Drop" a lot and characters can "find" chest etc on the map.
I am using it in conjunction with the "Monster Loot" modules from Anne Gregersen. The modules contain tables which generate the loot for all monsters with the "output to parcel" option.
The problem is: the loot tables contain random dice roils, so I really need to generate them individually per session which results into a "[RESULT] <Monster Name>" parcel.
I now can either
a) drop the parcel onto the monster on the CT (caveat: some items are "broken" equipment and change the AC or weapons of the real monster)
b) rename the parcel to "[MP] LOOT <Monster name>" (caveat: I also need to set the visibility, lock the movement, drag an icon onto it, unlock the parcel, etc - a lot of manual polishing)
Option a) is unusable to me: I know I can disable the option to apply item properties from the NPC inventory to the NPC, but it is so helpful in other cases that I did not want to.
Option b) however has many manual tasks which I did mostly in advance of the session (or during session when things go.... into different directions)
This workflow was
table name -> press 'output to parcel' -> parcel "[RESULT] <table name>" ----[manual update of icon, lock status, etc.]----> parcel "[MP] LOOT <table name>" -> death of CT entry "table name" -> loot parcel on map
I have searched the Fantasy Grounds documentation, but was not able to find anything indicating that the output of a table roll can be manipulated (through an API).
I therefore would like to understand if you know a way (likely with a new extension) to "output to parcel" (from the "Monster Loot", but potentially any other tables) using your "[MP] LOOT" (or another) template to create a parcel matching what you use as input for the LOOT parcel. Building the Map Parcel extension, I consider you the expert on handling parcels :D
This would nicely daisy chain everything together:
table name -> press 'output to parcel' -----[template X, setting icon, lock status, etc.]---> parcel "[MP] LOOT <table name>" -> death of CT entry "table name" -> loot parcel on map
What I already did is updating the "onDead" function in your Map Parcel extension's "mapparcel manager" script to also check on parcels with name "[RESULT] <CT entry>", and adding the content to the one from the actual "<CT entry>", then applying the "[MP] LOOT" parcel (template) defaults, but as all table rolls to parcels start with "[RESULT] " in the name, this is not a clean solution (it fundamentally works but I remain afraid that I add something "odd" to a monster after a table roll with a coincidental name match).
Any idea if above workflow in green is possible?
Forgot to mention: if you want the code to add to your paid extension, let me know. No strings attached, I will transfer all rights to you (this is a minor change, after all). My gain is that I do not need to patch after an update :)
Caveats about unintentionally handling a RESULT parcel remain as described above, but you can easily add an option to switch this feature on and off.
Just write a simple extension on top of mine and have it do what you want it to do. I know some other loot generator does something to put out map parcels but don't remember what its called.Quote:
Originally Posted by Arnagus
Honestly, I keep telling people should just configure the extension by making their own extension on top of it. I mean I'm using coreRPG which is overridden by 5E which my extensions overrides both to do what I want. All you need to do is make a simple extension that overrides the coreRPG/5E/<my extension> and does what you want with minimal impact. Then use it or put it on Forge for free or sell it there as it is required to have coreRPG/5E/<my extension>/<your extension>.
I also keep telling people to do the same if they want to make it work with another ruleset - coreRPG/5E - <your ruleset>/ <my extension>/ <your extension>. Nobody listens.
Probably for a very good reason as its a royal pain to keep up with every other ruleset changing on a whim and you being broken - having to deconstruct what changed and reconstruct how to make your stuff work again is making me become a very jaded extension developer, if I were not using this stuff in my own games I'd throw in the towel for sure.
I've always been honest and up front - I do my extensions for me and my players - I have given Grim Press the rights to sell it as they see fit but my main concern is me and minimizing the work I have to do - which seems to increase every time FGU updates.
Your free to tag along with what I have for my uses - or overwrite them for your own uses - but unless I need it - I'm afraid I'm keeping my code as simple to maintain as I can.
And if you make your own extension instead of just changing the code directly (a simple thing to do really) you don't have to patch after every update - unless of course... someone changes something on a whim in FGU. Or even on my side - that breaks you. Life in extension land I'm afraid.
If someone remembers the shop extension that uses map parcels let this guy know though it may already be buried in this forum thread somewhere likely already.
Own extension on top makes sense - as long as you do not change the functions which I need to replace (too often)
Will check the extention you mentioned - hope I can find some code examples to see how RESULT parcel names generated from tables can be changed.
Found it: NPC Random Treasure Drops
It’s not shops exts it’s random npc loot parcels
Okay, have now done this (will not post here as it contains a copy of your copyrighted/paid onDeath function).Quote:
Originally Posted by SilentRuin
I have also looked into the NPC Random Treasure Drops extension description, but decided against it as it does not change the parcel names from table rolls, but introduces a complete new type of parcels. Might potentially be configured to do what I need, but too mighty/many other features which I do not (yet?) need.
I have however a fundamental question: in your onInit(), you are registering a handler pointing to said onDead function. I tried to point it to my modified customOnDead function by replacing the reference during my own extension's onInit():
Still - the original function is called from the handler.Code:origOnDead = MapParcelManager.onDead;
MapParcelManager.onDead = customOnDead;
It only worked when I was registering my own handler and removing yours (during my extension's onInit()):
Any clue how to avoid this registration/unregistration and rather replace the function directly?Code:DB.removeHandler("combattracker.list.*.status", "onUpdate", origOnDead);
DB.addHandler("combattracker.list.*.status", "onUpdate", customOnDead);
You have my permission to use post whatever - that you find useful. Im not territorial like some devs - we are all building on someone elses work - through example or unique effort - feel free to use what helps. Ill look later today if i can figure out what your talking about but you should always try to override and call the original code if you can as many share the same code space and you dont want to stomp on their changes if you can help it. Ive posted on this in these forums if you can look it up.Quote:
Originally Posted by Arnagus
Anyway i suspect you should be doing that im sure map parcels gas examples of where im doing that exact type of thing. Also leaves less of an impact or footprint in the code meaning you will less likely damage or be damaged by others code changes.
Handlers are sometimes tricky in this regard but ill take a look later today.ive found some db things dont get initialized until ondesktop init which can drive you nuts.
Ok in regards to your handler issue. Your solution is fine - but in the end the cause is that onDead function is put into the handler (the pointer) BEFORE you override it. This means while you did override the function its not the pointer (I'm guessing here) that was added into the handler trigger.
Your solution is one way to address this - another is to move the add handler code into the onDesktopInit (or whatever they changed it to these days I still use my original definitions). Personally, I'd stick with your solution though as either way your going to have to remove the handler I made so that your onDead override is the one that gets added into the handler.
Its all in the weird way that onInit and onDesktopInit have different things intializing in them. If you have other of my extensions you can see where I've done some pretty wild things to get around these type of issues.
But gist is - you hack/slash/burn the code till it works "good enough" and call it a day.
Perfect is not my goal - nor understanding why I had to do the worst workarounds imaginable to get things to work (think polymorphism). Nor will I try to to figure it out.
Good enough. As is your solution.
Clear - thanks for the explanation. I suspected the reason might be something like that (order of things, and thus timing) but hoped there would be a more elegant way. But as you said: good enough :)
Will likely look into what you did in Polymorphism nevertheless to learn more options to “work-around” things.
Reminds me: many thanks to keep things out of the vault - this helps a lot! Still trying to sync MNM’s downtime manager to progress with ClockAdjuster, which is a pain as it sits in the vault. Different story (does not belong here); but again - many thanks to ease access to your code!
Thanks for your permission. Extension is attached and adds an option (in MapParcel section) to switch transferring the content of the "[RESULT] <CT name>" parcel on or off. It also respects to delete then empty [RESULT] parcels.Quote:
Originally Posted by SilentRuin
Updated: moved to Forge, hence attachment removed.
Feel free to drop it in forge if you wish to maintain it for anyone else - I warn you - that can lead to being a pain in the you know where though.Quote:
Originally Posted by Arnagus
V1.53 - Bug - The following was fixed - weapon and armor drops into NPC will now only apply bonus if ID'ed - shield will now respect bonus (if ID'ed) - dexterity bonus will now be applied properly based on "dexbonus" yes/no text and limited to max if present.
As usual dropping weapons/armor onto an NPC is just to help build the NPC easier. For armor, as it always has been, there is no way backwards to recalculate the previous AC it can only move forward as you add new armor in or manually edit the fields. Same if you have EE (equip/unequip armor) it will only update the AC with the new equipped item - never reset AC back to some previous setting. As its always been this is just a tool to make editing an NPC main page easier with drag/drop of item onto it. Its not magic. You still have to pay attention.
Thanks! Awesome work.
V1.54 - Bug - Display Name for IDed items was not working properly due to missing string definition which only existed in equipped effects (some code had been copied to map parcel to do a similar ID check). Fixed.
Most obvious in Party Sheet inventory when name of ID'ed item would always be the non ID name. Only works with equipped effects as code copied from it was missing a string definition that only EE had.
V1.55 - Update - An "[MP] LOOT" template now not only supports exact name matches, type matches, and default matches for the loot template but now will allow names (only) to support a trailing * so that a name match can hit everything up to the * (including spaces) to indicate a match. For example, if you have in the CT <name> 1, <name> 2, etc. you can now make a loot template that "may" cover those by defining it as "[MP] LOOT <name> *". The order templates are processed are if an exact name match is found the checking of templates stops and that is the one used. Otherwise if a name *, type, or default match the search will continue for template matches until all are completed and the last found one will be used (always been this way except I added the name * option to this keep searching till done list). Basically, you don't use this don't worry about it nothing will change for you.
When I say good enough it means you can screw it up if you use it carelessly.
I tested with CT NPC Orc then defined "[MP] LOOT Orc" then tried "[MP] LOOT Orc *" then tried "[MP] LOOT Orc*" then tried "[MP]LOOT Orc Eye*" - etc. some at same time. Not perfect but better than it was and without a "*" in template it will only do exact match - and exact match will automatically stop searching. Templates of name followed by *, type, or default matches will all search everything and pick last match.
Looks like the update today broke this EXT, no longer can add tokens, or add items to the parcels while its loaded, also can't add items to NPC inventories.
You can add items directly to the NPC main tab.
The update was very minor. The only item in the update that could I could imagine possibly affect things would be:
[DEV] DB/databasenode - getCategory/getModule - Updated to return empty string as default value.
Regards,
JPG
Yep busted. And rulesets did not change so must be in Engine code. I'll have to see why by debugging. The token field in map parcels is no longer even being shown - whatever decision tree I have for determining if Parcel is read/write is busted I suspect. I'll have to look. Literally its just showing FGU parcel form as if it were read only and no longer displaying map parcel form when read/write.Quote:
Originally Posted by Moon Wizard
Yep previously you checked for nil to determine if was not returning a module. Now its returning blank - which of course busts any decision trees trying to determine if DB.getModule returned a module or not. Sounds like they decided to make some output to something not have to worry about printing nil instead of interpreting it as blank. Of course any code from past checking for nil is no longer valid.
V1.56 - FGU busted - DB.getModule returns changed from nil to blank - all code checking this had to be fixed to respect new values.
(sigh)
Thanks for the fast fix.
I only just learned today that support for this extension and other Grim Press extensions on DMsGuild ended in May, and that there was a 3-day window to buy these extensions at a discount on the Forge. While I would say that I definitely got my money's worth out of these extensions, and it's not a huge loss, as I've been moving away from D&D, and at the end of the day, it's my own fault (and the fault of my health) for not keeping up with the news better), I still think it would have been nice if this had been announced in the forum, where I might have had a chance to see it.
Email went out through DMsG to all owners of the ext, it was also 2 weeks on sale.Quote:
Originally Posted by similarly
FORGE also has a limit of how often we can put them on sale. I'm sure they will go on sale again (maybe not as good but pretty good for this one)
That's a good call on making a post on the forums next time, we will be sure to do that.