Lone Wolf Development Forums  

Go Back   Lone Wolf Development Forums > Realm Works Forums > Realm Works Discussion

Notices

Reply
 
Thread Tools Display Modes
nodice
Member
 
Join Date: Jan 2015
Location: Australia
Posts: 32

Old December 29th, 2015, 04:29 AM
Hi guys, is anyone able to tell me if its possible to have an entity's alias or alternate name be listed under a different containing topic than its actual name?

EG: I have the cast in my setting organised by family, and I would like certain people who change family to have their maiden name as an alias, and for that name to list correctly in the original family topic rather than the new one.
nodice is offline   #1 Reply With Quote
Farling
Senior Member
 
Join Date: Mar 2013
Location: Greater London, UK
Posts: 2,368

Old December 29th, 2015, 04:33 AM
No, the containing topic hierarchy is unique.

However, you can use relationships to indicate marriage between families.
Farling is offline   #2 Reply With Quote
nodice
Member
 
Join Date: Jan 2015
Location: Australia
Posts: 32

Old December 29th, 2015, 03:30 PM
Quote:
Originally Posted by Farling View Post
However, you can use relationships to indicate marriage between families.
Yeah, I already do that.

I also have another instance where a particular clan is made up of just one family, I was hoping to be able to have the same entry linked to in both the clan list and the family list. Does anyone know any reasonable workarounds for this?
nodice is offline   #3 Reply With Quote
Farling
Senior Member
 
Join Date: Mar 2013
Location: Greater London, UK
Posts: 2,368

Old December 29th, 2015, 04:36 PM
Rob has suggested in the past that the container hierarchy is more useful for permanent connections (e.g. geographical containment) rather than for "temporary" arrangements such as marriage or organisation membership.

The link-view should be able to present the parent/child/member relationships between people.

In your example, a family list of children could be using the topic hierarchy; whilst clan membership is better suited using relationships.

It is very easy to see the relationship links in the panels on the right side of the RW window; rather than the topic hierarchy on the left side of the window.
Farling is offline   #4 Reply With Quote
nodice
Member
 
Join Date: Jan 2015
Location: Australia
Posts: 32

Old December 29th, 2015, 05:12 PM
Quote:
Originally Posted by Farling View Post
Rob has suggested in the past that the container hierarchy is more useful for permanent connections (e.g. geographical containment) rather than for "temporary" arrangements such as marriage or organisation membership.

The link-view should be able to present the parent/child/member relationships between people.

In your example, a family list of children could be using the topic hierarchy; whilst clan membership is better suited using relationships.

It is very easy to see the relationship links in the panels on the right side of the RW window; rather than the topic hierarchy on the left side of the window.
Hmmm, I do use relationship links a lot. Its more so that, vis a vis this clan in my example, If I hear of it first via the clan name, I can look in the clans sections, or if I hear about it first via the family name, I can look there. Currently, I can only have it show up in one list or the other and I will need to make a dummy entry with a link to the actual entry, which seems kinda redundant but oh well.

Last edited by nodice; December 29th, 2015 at 06:07 PM.
nodice is offline   #5 Reply With Quote
AEIOU
Senior Member
 
Join Date: Jan 2012
Posts: 1,147

Old December 30th, 2015, 08:45 AM
There are several ways to approach everything in RW. Some make more sense or are easier or work better for a situation. Find what works best for you.

I create cast lists which contain all of the major NPCs for a locale. This is the primary location for these people so using the cast list as a container works for me. In the cast list topic, I create a table that lists every NPC for the locale with a super truncated stat list, location and gaming notes. This table is important to me because it includes the barmaids and cobblers and smiths and gongfarmers that the PCs may encounter. It has everyone so I can do a search on one topic for a name and find it.

My method isn't player friendly at the moment though as the table is one huge block containing everyone. I just can't get myself to create individual lines for 100's of people. And I don't want to reveal stats so it would be hundreds of blocks of lines.... RW for me is primarily a GM reference so it's not a big deal. If players need more info they can journal it or I can create a real topic entry to reveal to them.
AEIOU is offline   #6 Reply With Quote
kbs666
Senior Member
 
Join Date: Oct 2014
Location: Chicago, IL
Posts: 1,687

Old December 30th, 2015, 12:10 PM
And I have yet to create a single cast list. I'll do People topics for NPC's the PC's will or have a strong possibility of encountering. For the "supporting cast" sorts I still generally make them up on the fly the first time and then take notes and they get a full topic after the session.

For me NPC's are contained by the geographic topic where they live/work. Then they have relationships to everything, body and where else they might be important to or belong to. I imagine that if I were to ever do a community that was developed at a very high level only and needed just a few major NPC's there I'd just put them in a cast list in under the community's topic but so far that isn't how I've been fleshing out my realm.

But both methods work just fine. It is just two GM's different approaches using the same tool.
kbs666 is offline   #7 Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 02:15 AM.


Powered by vBulletin® - Copyright ©2000 - 2020, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.