PDA

View Full Version : Create Tokens from Portraitfolder



Weltenbrand
October 26th, 2020, 15:25
Hello,
I have a list of "summons" which are located under the charater node.
I want the players/clients to be able to set the token for the summons from local images (like the portrait selection).

I tried to use User.requestIdentity + User.setIdentity but this creates a new entry under the charsheet node.
I do not wantneither a new node in the DB, an extra entry portrait in the character list nor an extra cahrater in the character selection, since it is possible to have several summons.

Is there an other way to create a token from a local image (and make it accesible to all other clients)?

Moon Wizard
October 26th, 2020, 23:50
No. The portrait tokens are limited and linked to PC records only. This is the only way that portrait tokens can be created automatically.

You'll have to specify tokens directly using token assets for anything else.

Regards,
JPG

Weltenbrand
October 27th, 2020, 08:58
Can token assets be shared from players?

An addtional question regarding requestIdentity, the wiki lists three parameters for the function call.
But it actually needs five, can you explain their meaning?

Edit: as a workaround I create the list entries as pcs and filter the charselection. Creation from clients is requested with an oobmeassage

Moon Wizard
October 27th, 2020, 18:36
Creating PC records for summons seems like a lot of overhead to manage internally; but it's up to you. PCs have a lot more internal pieces and graphics than other record types. I wouldn't recommend for distribution to others. It will cause complications; especially if they turn off extension.

The requestIdentity API has been five parameters for as long as I remember; so the doc link is wrong. Use the examples in CoreRPG instead.

Regards,
JPG

Weltenbrand
October 27th, 2020, 18:45
I know that the examples on Core work, but I still dont know what they mean.

What kind of overhead do you mean? If I never open the "charsheet" class on the summon nodes, the DB entries are not created. And the graphics are the portrait and the token, or is there anything else internally?

Moon Wizard
October 27th, 2020, 21:56
The PC nodes are treated differently within the system and the ruleset. For example, PC nodes will appear in the import window when opening in other campaigns, they have their own "color", they have their own "pointers", they have their own "portraits" and "portrait tokens", etc. They are a special case specially made for player characters. Ultimately, you can build what you want using the API, but my suggestion is not to add that layer of complication into the PC records for other users.

For requestIdentity, the parameters are:
1) identity ID (matches node name under PC list node, usually "charsheet")
2) (PC list node, usually "charsheet") (deprecated in FGU)
3) (PC name field, usually "name") (deprecated in FGU)
4) (PC import node) (If importing, this specifies the local node you want to import into the requested node.)
5) (Lua function callback) (Called when request complete)

As I said, you're best off not dabbling in this portion of the ruleset. These APIs are not something that are very flexible, as they provide a very base level feature that is already handled by CoreRPG.

Thanks,
JPG

Weltenbrand
October 28th, 2020, 07:57
What would be your approach to make it possible for players to use graphics from their machine?
I have met enough GM who are not willing or able to share tokens which are provided by players.

Moon Wizard
October 28th, 2020, 17:01
Going forward in the future (on FGU), the players should be able to use their own token assets installed on their own machine (once that portion is fixed in FGU).
Until it is fixed in FGU (and always for FGC), the GM will need to assign.

Regards,
JPG

Weltenbrand
October 28th, 2020, 17:11
Cool this Sound be awesome.
Do you have a idea when this feature will be available?

Moon Wizard
October 28th, 2020, 17:15
I don't currently have a timeline, as it has not been prioritized for a fix yet. But, it is on our list to fix.

Regards,
JPG