Linking - reusing the custom private tables

[hkokko]

Created a few private jsons as separate tables. Would like to use some of them together. Would be nice to be able to that via Generator service (just refer to existing private ones when creating a combined ones). Is that possible now?

[JochenLinnemann]

Not currently, but we are working on it.

[evesala]

I realize I'm getting ahead of things, but have you already finalized the syntax for this?

This would be an important feature for me as well, and I could already take this into account when planning new tables. (Although the functionality is not there yet, I could for example name my subtables in a way that would be logical for the upcoming syntax.)

[JochenLinnemann]

I just finished the far backend calls and run all unit tests successfully. Now working on the gateway and then adding appropriate UI elements.

I decided to keep to "private:" as discussed elsewhere. So instead of "lib:" for public libraries you need to use "private:" for your private library tables.

You won't be able to call into a generator's sub-tables directly as I think this would fix a generator to a given internal structure which seems not appropriate to me. Instead you will have a library of standalone tables, collected into one JSON into which individual calls can be made. And yes, the private tables can reference each other (without needing to add "private:").

[evesala]

Good progress then, nice to hear!

But did I understand correctly that one can only have a single JSON file for private use?

Hopefully not, as that would not work very well. And how would for example result patterns work?

After rereading I think you mean a single JSON file 'frontpage' that lists all the private generator files, but just checking to make sure...

(By the way, have I missed some public discussion about this, since I don't recall hearing about the private: label before?)

[JochenLinnemann]

I used the "private:" label one or two times in comments on this topic over on G+.

You will be able to use as many generators as you wish, this one won't change. You will get an additional private library which will contain ALL tables you want to call with "private:".

[evesala]

Thanks again, I'm eager to test this functionality.

I guess there is sometimes confusion over what constitutes a 'table', in my interpretation at least.

I'm not always sure if it's a subtable feeding results to a main table, a single main table in a JSON file (there could be several), just the single main table called by the result pattern, or the whole JSON file (which I think is officially called a 'generator').

The proposed capability to call subtables across JSON files could add to the vagueness, so maybe a terminology section in the documentation would be helpful? :)

[hkokko]

sounds lovely as the path with Latex & Pandoc to ascii seems to be fraught with difficulties (there seems to be either a bug or very difficult to use feature on this combo). Would rather have simple toolchain embedded in Campaign logger in handling the private libraries than an additional toolchain that would enable

[hkokko]

so my need is: use any private table of mine (from a multitude of Json files and generators) from another private table.

[JochenLinnemann]

To keep things simple, I need to compromise on this. You will need to move all your private tables you want to be callable into one place. These tables are then callable using "private:" from any of your private generators.

[evesala]

Again to clarify: Is the 'one place' for private files for example an index file listing all the private files, a directory, or a single file containing everything (directly or via includes)?

Sorry to ask so many questions about this!

[hkokko]

Ouch. that is going to be one mega file to maintain. For example currently I have my name tables for a few cultures. they might be quite long. I have all my city encounter stuff, all my tavern stuff, all my jungle encounter stuff. It is going to be bit of a pain...

I have 1700 lines in my daily encounter material for jungle

My scenario background generator is 1000 lines and it is just started...

My city stuff (without taverns) is already 3000 lines and it is just started.

Could it be a namespace - for example have "names" in one file, "city" in another "overlandJungle" in another... etc. Somehow domain specific.

Compile these together with a tag or keyword...

[evesala]

If the private library indeed is a single file, I'm afraid that I too am going to have problems, both in technical and usability sense.

If I extrapolate from the results of my early testing, in the long run a single humongous file could even lead to memory management problems on low end tablets.

Not to mention how inconvenient editing just one big file would be. My planned private tables are much more than a small collection of short lists. :(

I see subtable calls to also private generators quite an essential feature also from the manageability and organization perspective.

But I hope I have understood something wrong.

[JochenLinnemann]

Memory isn't normally a problem on the client as the generator isn't loaded in full. It is processed on the server, except when you open a generator/library to edit it in the UI.

Besides that: I hear you! We just need to iterate to reach the final goal. I prefer small steps which deliver features and improvements instead of long cycles to build the One True Solution (TM), which probably never gets finished or used.

So next step will be: a) multiple private libraries which get merged into one on the server b) call into private generators via namespacing c) a combination of a) and b)

Currently the generator service is stateless and private generators live in user-specific data spaces. Some kind of communication is needed for selective loading (like in b) or a lot of upfront loading (like in a). Being a distributed system, I prefer chunky over chatty communication for CL. These are just my current musings. We are on our way, but we will need just another step (or maybe two).

[hkokko]

Evasala's concern are mine as well. I have been overdoing quite a bit my other project (myths encounter generator) so would expect there to be in the long term more than hundreds of tables, some more, some quite large and quite a bit of reuse - would expect some of the tables to remain very stable (name tables), some stabilising over the time and some being in fluctuation over a long period of time. I really appreciate the tool - it has already given me lots of possibilities of overdoing and combining stuff both for my sessions and preparations for them. Cool direction, thanks

[JochenLinnemann]

Besides {private:tableName} for private library tables, there will be {gen:generatorName} and {gen:generatorName#tableName} for accessing private generators and their sub-tables available in the coming update of mid-October.

[evesala]

Yeehaw! These will be long 4 weeks. 😃

But good to know the syntax. That way I can have something already finished when the update hits.

[evesala]

Again, a clarification request..

In the {private:tableName}, {gen:generatorName#tableName}, and {lib:generatorName#tableName} calls, the tableName and generatorName are what has been specified as the values of the name keys in the JSON file, right?

(A file name would not really work, but I'm asking ask just to be sure... I'm currently updating my tables to use this external call functionality and would like to get the syntax right. :)

[JochenLinnemann]

lib: uses the name of the library file without extension, the generator name is ignored gen: uses the generator name (there are no file names here)

so it is effectively: {private:tableName} {gen:generatorName#tableName} {lib:fileName#tableName}

[evesala]

That's how I figured it out. (There was a recent G+ discussion about this:

There are no file names in the Custom Generators list, so the name property is used in the {gen:table} call.

And when I upload a generator to the Campaign Logger server and call it with a {lib:table} call, that uses the file name.

The differing call functionality is a bit of a dilemma, this is not very intuitive and will cause problems if some users are calling the same table from their personal installation (perhaps slightly modified) and some others are using the library version.

( https://plus.google.com/+HannuKokko/posts/acfgHALX9Qr )

It can be a problem that the table call syntax changes based on the location of the called table. For example if a user grabs library tables from the GitHub repo, modifies them to better fit his own purposes and stores the generators in his personal CL instance.

I have mentioned this in the documentation, but this could still cause hair loss.

Also, users have no access to the CL server and therefore cannot really be sure of the file names. Sure they can check the GitHub repo, but not all of the generator files on the server are stored in the public repository.

Would it be possible to change the library table calls to be based on the name property as well? This means that the present tables will have to be modified, but it's better to do that now than later.