A Humble Request

[Nickademus]

To my knowledge, there is a difference between the GM client and player client in regards to the tabs at the bottom of windows such as the Image, Items, etc. While the GM can create multiple tabs and have the information separated with spiffy looking color-symbol combinations, the player does not see the tabs and all the shared assets are dumped into a single list.

I know this problem stems from the design of the old code and don't expect this to be changed. But with the new Unity engine, I believe this code will be rewritten. I humbly ask that you choose to alter the design to allow the GM's (specifically the GM's) tabs to act as a sort for the players as well. So if the GM has 8 images in the first blue-book tab and 5 images in the second green-world tab, that the players will also have a blue-book tab when one of the 8 images is shared and a green-world tab when one of the 5 images is shared.

This would help the GM to present information to the player is an organized fashion.

[seycyrus]

I second this request.

[Nickademus]

Had this come up in a game I was playing in. The GM referred us to a certain tab in the image window and we had to tell him we had no tabs; all the images were in one big list.

[Nylanfs]

If players are having an issue finding it the GM "could" un-share and then re-share again. It should force it to pop up. But yes I do like the players having the same tabs that the GM would, the only issue would be potential spoilers.

Also this is a main reason on why a lot of GM's running long-term campaigns switch to using a module system. :)

[Wolfheart]

They should have tabs, and the GM could mark items in the list as "not visible to player". On a related note, as I'm swamping my FG with text input across a gazillion story tabs, is there an easy way to actually give these names tabs? I notice in Lost Mine of Phandelver, the tabs at the bottom have titles (for example, Part I: Goblins). That would make it a LOT easier to navigate for me. And probably others.

[Moon Wizard]

Type text into the chat entry box; but before you hit Enter, drag that text onto a category tab.

Regards,
JPG

[Wolfheart]

All right, thanks!

[Nickademus]

Type text into the chat entry box; but before you hit Enter, drag that text onto a category tab.

Regards,
JPG

I believe you can hit enter and drag the story frame text the same way. This lets you drag it multiple times.

[TASagent]

Hey Moon Wizard,

Any chance you can clarify how tabs are sorted (in windows like Story) when loading a module? My experience exporting modules and loading them as adventures seems to suggest the sort priority is: color cycle order, icon, name. Is there meant to be another way for creators to exert control over the order? And is the color cycle order what it is just for historical reasons?

Thanks!

[Nickademus]

It is semi-random. It is supposed to be based on the id-# order of the categories in the database. But this gets mixed up some times.

You can open and close a module that adds multiple tabs and it will put them in a different order more times than not. It seems the tabs are first-come-first-added, though since FG is single threaded I don't see what is causing the order to vary. You can also see this if you have multiple tabs and you drag one from one side to the other too quickly. It will scatter the other tabs rather than preserving their order.

[Moon Wizard]

It's essentially it's in load order of the underlying database (first main database, then module databases). For all practical purposes, it's semi-random.

Cheers,
JPG

[seycyrus]

Is there some issue that prevents the tabs from being sent over to the players?

[Moon Wizard]

Yeah. The current client does not share any category info over network, so it would have to be implemented and all the UI considerations considered as well. It's not in our product planning right now.

I'm actually considering a complete overhaul of this part of FG with Unity rebuild. I'm currently thinking it will be folder based with the ability to next multiple folders in the next version.

Regards,
JPG

[TASagent]

Nesting would be excellent. Just build in serialization of the directory structure from the get-go with the redesign and the rest should be EZPZ. :-)

[TASagent]

Actually, if you were already doing that redesign... The ability to visualize and organize all data types as if they belonged to an arbitrarily nestable directory hierarchy would probably be a rather intuitive improvement. Especially if you could then create links to open directories of items, for example, and not just items themselves.

[damned]

Actually, if you were already doing that redesign... The ability to visualize and organize all data types as if they belonged to an arbitrarily nestable directory hierarchy would probably be a rather intuitive improvement. Especially if you could then create links to open directories of items, for example, and not just items themselves.

The big challenge for the port and redesigning these things is the desire to maintain as much backward compatibility as possible... so sometimes the best way might not be the best way... :)

[TASagent]

Here I was, excited to share an overview of my implementation to solve an incredibly similar problem, when I realized that the backwards compatibility you are concerned about was in the form of compatibility with mods, extentions, and the like, and not merely getting old well-formed data into the new format. Other than the (significant, I acknowledge) need to cooperate with external tools, it's somewhat uncanny the degree to which the problem that I worked on is similar to what would need to be done.

[damned]

Here I was, excited to share an overview of my implementation to solve an incredibly similar problem, when I realized that the backwards compatibility you are concerned about was in the form of compatibility with mods, extentions, and the like, and not merely getting old well-formed data into the new format. Other than the (significant, I acknowledge) need to cooperate with external tools, it's somewhat uncanny the degree to which the problem that I worked on is similar to what would need to be done.

Not just mods and extensions - rulesets too... rulesets often take 6months to a year for someone to build... losing them would be very tough...

[TASagent]

Yeah, I haven't yet taken the time to extract a ruleset to get an idea of just how tightly bound they are to the particular implementation details behind the data elements in question, like Story, Items, NPCs, etc. While it's theoretically possible the answer is "not at all", in practice that rarely ends up being the case. However, even in the worst case of very little flexibility, if you have the ability to attach a small amount of metadata to these data elements, you can completely change the way Users interface with the data with virtually no modification to how it actually works behind-the-scenes.

I struggle to think of complications that would actively prevent such a redesign (that is, independent of the question as to whether it is worth the number of man-hours to actually implement). However, as a rule, I will never declare that programming a particular addition or modification is simple or fast without at least decent familiarity with the codebase. Little gets my goat more than laymen (or gods forbid, other programmers) declaring "They need to add X. It's so easy and very important."

As an armchair exercise, in what ways might rulesets fail to cooperate with this kind of redesign?

[Griogre]

One of the main problems is LUA is not OOP. The window classes do have inheritance but basically rulesets are all procedural programming with globals. They can be and are usually very messy. Then mix in the fact that most rulesets grow organically feature wise. The combat tracker in most rulesets which use targeting is a great example of this. Once just a simple "board" to track initiatives for the GM only, all the targeting and damage code for both players and GMs have been hooked into this part of the ruleset and in a lot of rulesets its the most complicated code the ruleset has.

[TASagent]

Thanks for the reply, Griogre.

BTW, I just happen to rather enjoy hypothetical, arm-chair program design. I find it a stimulating programming exercise. If you don't enjoy it, please don't feel obligated to put in effort and respond to my ramblings. If you do enjoy it, don't hesitate to point out any mistakes or holes in my reasoning. There is always more room to grow.

Yeah, I understand LUA is not OO. If you wanted that functionality you could simulate it by just implementing a virtual table that gets built up by a few factories, but that's kind of ridiculous and not exactly what I had in mind. Plus, your code would likely end up looking like python, with everyone passing themselves to their member functions, and who would want that? </ribbing>

In any case, I played around with modifying a ruleset for the first time this morning, and have a bit better idea how things fit together on the scripting front. Well, an hour or two's improved understanding. So, just a little bit.

More of the behavior regarding the display of the data items is driven by the LUA than I expected, but that's still not necessarily problematic. As long as your Model and View are sufficiently disentangled, which it looks like is the case here, it remains feasible to make changes to just the View without needing to propagate collateral changes throughout everything dependent on the Model. Emulating a nested directory structure doesn't necessarily require anything more than very minor filtering and parsing of what would normally be passed to the user for display, and the addition of a small amount of path data to each data element, like a string. The filtering is to display just the items that have paths that begin with your "current directory", and the parsing to find the directories that might exist "below" your current directory, to add buttons for "navigation" to the interface. It wouldn't necessitate modifying any underlying organization of the actual data, and thus should, theoretically, have a minor impact on the functioning of existing rulesets. It's entirely possible (likely, even) that some rulesets might need minor tweaks, like if they "overwrote" some of the new functionality that they would need to "inherit" (quotes due to the semi-inherited relationship between CoreRPG ruleset and its children), but in theory it could be possible with only minor changes to offending rulesets. Unless, that is, I have made a grievously mistaken assumption about how it could work, which is entirely possible.

Also, the described approach is obviously not the most efficient implementation, but that's not what I was claiming. True hierarchical representation, reflected in the structure of the database, would absolutely be a major rewrite and significantly impact likely all rulesets.

Thoughts?

[Moon Wizard]

In many cases, I don't know the full extent of the changes necessary to support any change to the product, until I implement, fix what breaks or becomes hard to manage in the UI, then see what breaks in the wild or what people bring up. It's a challenge brought about by the high flexibility and programmability of the product. So good and bad sides to this implementation.

Also, I find that any changes, especially those that modify core features, tend to snowball in scope, once I dig into the code. While I may think it's a couple new functions or behavior changes, I have found cases where it ends up spanning the entire code base, due to the original design. In addition to maintaining backward compatibility with 5+ years of DLC, I'm also working with a code base and design where portions are 8+ years old and not written by me.

While I know that a few things will need to change, such as windowlist folder support, deprecation of category controls, etc.; the end case is that I won't know until I do it. :)

Regards,
JPG

[TASagent]

While I know that a few things will need to change, such as windowlist folder support, deprecation of category controls, etc.; the end case is that I won't know until I do it.

Definitely. I am a firm believer that the only way to know, for certain, what changes would need to be made for a given feature is to have already made them. And QA'd it. And released it. And waited a long time for feedback.

I look forward to the eventual news regarding what you guys decide to do.