manuskript
manuskript copied to clipboard
"Permanent" items
This is just a random idea. I'll write it because it seems interesting, though it could be hard to implement.
How about creating an option for a "permanent" item that could be modified in the editor?
I could, for example, create an item "Possessions" or "Purse", toggle it as permanent, and have it shown in every Scene's Metadata. In there, I could modify that item description.
That way I would always have on hand what my characters have in their "Purse", "Wallet", or wherever else, and modify it.
I was also thinking about having a field, in World, that shows all the content in every chapter where there's been a change.
For example, I create this "Wallet" item in World, and make it "permanent". Then, in Chapter 1, I write 15€, and in every Chapter I create I always see those 15€. Then in Chapter 6, I'll change it to 4€, and that will show until Chapter 9 where I write 60€.
If I go back to look at one of the precedent Chapters, I will still see the money my character had until it was changed. For example, in Chapters 1, 2, 3, 4, and 5 I'll still see 15€, in Chapters 6, 7, and 8 I will see 4€ and from the ninth forward I'll see 60€.
If I go to the item in World, I will see where I made changes. Chapter 1: 15€, Chapter 6: 4€, and Chapter 9: 60€.
It could be interesting to have something like this one day.
That would imply a linear progression of the story, wouldn't it? In the case of flashbacks, for example, or multiple strands, the system could get confused if no time information is available and evaluated (as proposed with #155).
Also, in this #155 Issue @siliconserf has mention Metafields, when we make them configurable, the user can store everything what is needed in it!
Which is also needed for Plugins (As soon we have the needed API), which help to track such information!
@peter88213 yes this is a flashback! ;-)
That's right, such freely configurable metadata fields could be used for this purpose, i.e. to add information to the scenes. But you have to consider that these proposed fields have no semantics for the application, i.e. the algorithm for automatic filling is missing as well as the assignment to further elements of the world building, or to characters.
The full functionality as suggested by @FastusBellrune requires a multidimensional data structure. I guess a relational database could do something like that.
However, it seems to me to be much more efficient to simply use a spreadsheet. The rows would be the scenes or chapters, and the columns would represent the "permanent items" such as a character's assets. It would be worth considering whether a table export could be provided for this, actually only for a csv file with chapter or scene titles. A third-party tool would also be an option, e.g. a Python script that generates spreadsheets from the Manuskript files and possibly updates existing spreadsheets.
By the way, this solution also applies to #1230.
@peter88213: That's why I said make it configurable
Name Type: INT;REAL;STRING;LINK;INTERNALLINK Validation:REGEX;MIN-MAX
Then add a little GUI for the validation for the validation, with prepared REGEX or the possibility of predefined REGEX (Also with a way to add them from PLugins!), so We have a Date validator, Names of people, Things or Place should be INTERNALLINKS.
So we have full flexibility and also some of the needed data quality which is needed!
Regards
Also, later a Plugin can just read out all this data and make it an Overview/Spreadsheet or what ever!
Sounds quite interesting. Where can I obtain information about the application's Plugin system? Unfortunately, I couldn't find anything in the code.
Sounds quite interesting. Where can I obtain information about the application's Plugin system? Unfortunately, I couldn't find anything in the code.
It's planned for the Gtk port. So it hasn't been implemented yet.
That's a fascinating topic. Is there already a concept of how you want to implement the plugin system? Are you going to import the Python modules from a separate directory when the program starts, so that each user can install his own plugins? How does the plugin module gain access to the API?
Unfortunately not yet @TheJackiMonster has an idea how to do it, but unfortunately I don't have a clue.
There's much discussion all over the place in multiple issues now: #1118, #1229
It still needs implementation and I currently work on another project. Also it still takes a lot more time until the Gtk port is somewhat usable compared to the current Qt codebase. So if you (@peter88213) want to discuss details, feel free to let us know your perspective in those issues.