-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Content Market and the Staging Ground
- Thread starter kbs666
- Start date
The "recommended practice" is ... don't put NPCs in a specific place.
Containment is meant for permanent, or near-permanent, locations (like a building in a settlement, or a settlement on a geographic location [note: NOT a political region]).
That being said, I would find phantom copies extra confusing. What I prefer to do is to place the NPC (or Item, or whatever) in a holding place ... such as under a Cast List (Adventure Allies, Adventure Enemies, Adventure Support, SettlementX Residents, etc.).
Something else to remember is that, depending on the GM, once the campaign starts, there's no guarantee that the NPC (or Item, etc.) will [i[stay[/i] where it started. If I have a Cult Leader (as in the example), I would want to see ONE copy so I know where he is... and I'd move that one copy from container to container to mark the location changes as the game plays out.
Containment is meant for permanent, or near-permanent, locations (like a building in a settlement, or a settlement on a geographic location [note: NOT a political region]).
That being said, I would find phantom copies extra confusing. What I prefer to do is to place the NPC (or Item, or whatever) in a holding place ... such as under a Cast List (Adventure Allies, Adventure Enemies, Adventure Support, SettlementX Residents, etc.).
Something else to remember is that, depending on the GM, once the campaign starts, there's no guarantee that the NPC (or Item, etc.) will [i[stay[/i] where it started. If I have a Cult Leader (as in the example), I would want to see ONE copy so I know where he is... and I'd move that one copy from container to container to mark the location changes as the game plays out.
Right now they are storing the links between items somehow - because you can literally pull up a view of every link the item has to it within snippets. This is actually kind of a cool view btw.
The only difference here is they would need to create a new type of database object that holds a specific type of snippet that says 'if I exist then render me as the parent object' (yes this isn't trivial as it sounds - I'm not ignorant of that fact).
The 'shortcut' topic would be an actual node with a single generated snippet type with some kind of key to generate the callback to the topic - short sweet and works just like everything else in the database (the actual topic can even get it's own auto-generated random name that we never see) - the real work would be in the render engine when finding *that* kind of snippet/topic rendering the referenced topic.
No relationship issues would exist that don't already based on how they are doing things.
I agree, cast lists are what I use for people and that really is the best place to put them. But if there is a major NPC both in town and in the dungeon, I'd love to be able to put a copy in both of them to grab my attention. The master category would be contained in the cast list and the clone(s) would be grayed out like aliases.
I've tried to do the linkages via relationships to locations but they aren't as visible and obvious. I need a bigger flag to catch my attention.
For multiple clones to work though, they would need to be used sparingly. Or you'd end up with a massive cluster.... I can see these getting overused by new RW users much as containers tend to be now.
If work is going to happen on this, it isn't a high priority. It's a nice-to-have after calendars, player journals and maybe a thrice over on the GUI.
I've tried to do the linkages via relationships to locations but they aren't as visible and obvious. I need a bigger flag to catch my attention.
For multiple clones to work though, they would need to be used sparingly. Or you'd end up with a massive cluster.... I can see these getting overused by new RW users much as containers tend to be now.
If work is going to happen on this, it isn't a high priority. It's a nice-to-have after calendars, player journals and maybe a thrice over on the GUI.
Yes, they would.
With each topic having only one container right now that relationship is simply an item in the record, probably. In order to allow for an unlimited number of containers, you have to create a separate table of nothing but topics and containers that has to be searched and joined to the main table every time you need to build the tree. And honestly it makes no sense to have a privileged container under that scheme, no matter where you find the name in the tree you should be able to open the topic directly.
I happen to agree that this is a desirable feature just that Rob is likely to have other opinions and this is why.
Of course if they would let you name a snippet and link to the snippet, the problem would go away. Think of how you can link to a particular segment of a web page using a target instead of the top of a text page.
Thus, you could place the magic shop owner as a section of the magic shop and then link to the name (which actually links to the named section just like a web page target) in the tavern he frequents and in his home building, as examples.
The feature request is here.
Thus, you could place the magic shop owner as a section of the magic shop and then link to the name (which actually links to the named section just like a web page target) in the tavern he frequents and in his home building, as examples.
The feature request is here.
Last edited:
I can do this already if I want by creating a topic with the same name and creating a snippet with a link to the name I want to link to. The only difference between doing that and my suggestion would be:
* The program creates a random name for the shortcut topic
* The program only populates the topic with a (this would be new) snippet type that only has a reference to the original
* The program renders this special topic with the name of the Shortcut (perhaps greyed out - perhaps with a customized look?) as if it were the shortcut
Oddly I can 'open the topic directly' now by clicking on any link from a snippet - so they already make links to the topic and track them - if you alter the topic location or name - the program will correct every link to that topic. The only difference here is the ability to see that 'link' as a topic name.
The link in a snippet is not the topic - nor am I in a container for the topic - so there is nothing new about this idea other than a bit of trickery on the back end.
Without seeing the rendering engine - you have no possible way of knowing if this is possible, insanely difficult, or even trivial - neither do I. We do know they are using custom controls for some things (like the date). I'll admit that it's possible the rendering engine is off limits which would make this kind of change difficult if not impossible - it's very difficult to guess because the program is so far along that some of the fundamentals vastly increase or decrease the kind of work needed to implement this kind of thing.
As much as I'd love the feature - I'd like to see all the dialogs work via keyboard (enter/esc/tab) also - it's jarring when so many useful functions are keyboard shortcuts and then you run into a dialog box that only accepts mouse input.
I'm trying very hard to hold off on a wishlist until they get the content market out and get a week off - because I'm sure the crunch they are in is enormous.?
You seem to think RW is some sort of XML document or the like. It isn't. The underlying structure is a relational database. This has been confirmed and discussed many times.
Links are entirely separate from containers. You may think the two are equivalent but the program treats the two as distinct and separate.
You seem to think RW is some sort of XML document or the like. It isn't. The underlying structure is a relational database. This has been confirmed and discussed many times.
Links are entirely separate from containers. You may think the two are equivalent but the program treats the two as distinct and separate.
And that's part of why I emphasize getting the terminology down. You can't meaningfully discuss technical topics if the people involved are not clear on distinctions. Blurred/fuzzy use of terms means your concept is also blurred/fuzzy and subject to errors.
I vaguely recall linking to specific Snippets as a maybe-future-long-term kind of something-they-want-to-do that was mentioned in the past.
I've never said anything of the sort.
I'll restate it again:
Topic Name: City of Brass
sub-snippet: Stuff about City of Brass
Topic Name: Plane of Fire
sub-snippet: Talks about City of Brass (link to city of brass)
If I change the name of "City of Brass" it will update the link automatically - it will find every link in the database that references City of Brass and update it. The program does this now.
Topic Name: Auto-generated-name-1
sub-snippet: City of Brass (link to city of brass)
This new type of topic isn't any different than the above - nothing in the database has changed (or how it works) - however when rendering the output the program treats any topic like this as special and shows the linked name.
We already know they have a 'rendering engine' - it has a bug that won't show topics if there are too many in a container. There is also logic in the render that decides if a topic is shown or not. This is an extension of that logic.
You are confusing things that are unrelated.
Yes, there is a rendering engine that handles displaying the UI, it's called Windows. There is an additional render engine that displays the user data. You seem to be under the impression it is simply creating something along the lines of a single webpage. That is incorrect. Every control is rendered separately. A snippet is a control in case there is any confusion.
Creating links in the program is simple at this point. They simply open topics. Maintaining the table of valid linker names trivial, it is simply every existing topic and article( plus aliases ). What you want is the equivalent of the anchor + bookmark functionality of HTML links which would require LWD to add that functionality, which since there is no DOM is not nearly as simple as you think.
As to your idea of placeholder topics to serve as links to real topics elsewhere in the hierarchy. This shows you truly do not understand the issue. In a DB this would be incredibly wasteful. A record, in the same table, is always the same size. So absolutely nothing would be gained by having a pseudo topic pointing to the "real" through a special snippet. What you seem to really be asking for is the ability to put the same topic in multiple places in the hierarchy which as I explained before is called many to many relationships and is problematic for a number of technical reasons. You can achieve roughly the result you desire by using a single container and establishing a relationship to any other topics as needed.
Yes, there is a rendering engine that handles displaying the UI, it's called Windows. There is an additional render engine that displays the user data. You seem to be under the impression it is simply creating something along the lines of a single webpage. That is incorrect. Every control is rendered separately. A snippet is a control in case there is any confusion.
Creating links in the program is simple at this point. They simply open topics. Maintaining the table of valid linker names trivial, it is simply every existing topic and article( plus aliases ). What you want is the equivalent of the anchor + bookmark functionality of HTML links which would require LWD to add that functionality, which since there is no DOM is not nearly as simple as you think.
As to your idea of placeholder topics to serve as links to real topics elsewhere in the hierarchy. This shows you truly do not understand the issue. In a DB this would be incredibly wasteful. A record, in the same table, is always the same size. So absolutely nothing would be gained by having a pseudo topic pointing to the "real" through a special snippet. What you seem to really be asking for is the ability to put the same topic in multiple places in the hierarchy which as I explained before is called many to many relationships and is problematic for a number of technical reasons. You can achieve roughly the result you desire by using a single container and establishing a relationship to any other topics as needed.
Nah - no one cares if we take up an extra 100 or 10000 records for stupid stuff here - because it's not going to process 1 million transactions an hour.
Look if you want to think I'm stupid then go away. If you honestly think this is true you aren't paying attention to what the devs have already said about their own program. Not everyone uses in the box controls for every program they create. It's pretty obvious they've done custom controls all over the place and my guess would be to ensure (as much as possible) copyright.
Windows doesn't have a bug where it stops displaying items after 1000. This program does - why... oh right - because they have a *custom render function that has a bug*.
You seem to think creating a shortcut is some impossible task - and the only way you would know that is if you had access to the code base - I go back to the fact that this has *nothing to do with the underlying database* as requested.
You keep approaching this problem like a typical DBA - that is you don't understand anything beyond 'make the database do it'. I can do exactly what I want in C++ without ever making a database.
Given that I can then make a database and do all the above with two tables and 3 data types, handling the rest of the logic in the code.
I don't presume that the code base (at this point) would be so easy to modify - I don't get why you presume to know for a fact this is true when the only way you'd know is if you were the one making the program.
That is definitely desirable.
I'll try one more time.
For many to many to work requires an extra table with at least one record for every topic. That means an extra join to build the tree. That is no big deal except that means redoing a lot of stuff that is already long done. I doubt Rob is eager to revisit that stuff.
The controls are not custom. They use a 3rd party library. You can do a search on the forum for which one. I can't be bothered to do it for you. Small shops do not in general write custom controls unless that is their business. LWD is in the business of writing gaming software they sure aren't going to spend time on writing controls.
I know quite a lot about the program. I know there is no DOM. There is no modding capability or scripting capability which would exist if there was a DOM. There are plenty of things you can do when starting from scratch that are substantially more difficult when you try to change an existing program.
Changing how links work is so fundamental to how the program works it would involve a massive change to one of the core functionalities of the program. I'm still not even sure how you would identify a non name that you want to be a link to a snippet. Even in HTML links to bookmarks are almost always hidden by plain text which is a capability not available in RW.
For many to many to work requires an extra table with at least one record for every topic. That means an extra join to build the tree. That is no big deal except that means redoing a lot of stuff that is already long done. I doubt Rob is eager to revisit that stuff.
The controls are not custom. They use a 3rd party library. You can do a search on the forum for which one. I can't be bothered to do it for you. Small shops do not in general write custom controls unless that is their business. LWD is in the business of writing gaming software they sure aren't going to spend time on writing controls.
I know quite a lot about the program. I know there is no DOM. There is no modding capability or scripting capability which would exist if there was a DOM. There are plenty of things you can do when starting from scratch that are substantially more difficult when you try to change an existing program.
Changing how links work is so fundamental to how the program works it would involve a massive change to one of the core functionalities of the program. I'm still not even sure how you would identify a non name that you want to be a link to a snippet. Even in HTML links to bookmarks are almost always hidden by plain text which is a capability not available in RW.
Viking2054
Well-known member
Actually, I think LWD may actually care about this. Not for your local database, but because of what it could do to the cloud. If every single realm sync'ed up to LWD's cloud had an extra 100, 1,000, 10,000 or even a million extra links then that could quickly spiral out of control. Also think about future web based access through the cloud. All those transactions to generate web pages could become rather bothersome.
It would be nice to get what you want, I'm just not sure it is feasible beyond the local machine anyway.
Ckorik's request is perfectly reasonable, and all the talk about difficulty is just speculation. There will be work involved, as with any of the requests out there. The amount depends upon a lot of implementation details we are not privy to. These extra links are storage size trivial (no actual duplication of content would occur in any reasonable implementation), and the web implementation would not be an issue (again in any reasonable implementation). The web version has a whole lot bigger problems that this, as we've discussed elsewhere.
Might I suggest someone find the request thread for this so we can actually add some weight to the suggestion?
Whether and when LWD gets to it is another matter....
Might I suggest someone find the request thread for this so we can actually add some weight to the suggestion?
Whether and when LWD gets to it is another matter....
Last edited: