ok I was just curious because it seemed out of place and random I was racking my brain trying to think of a reason when I would personally use that feature. but I like it. its a cool idea.
Printable View
ok I was just curious because it seemed out of place and random I was racking my brain trying to think of a reason when I would personally use that feature. but I like it. its a cool idea.
This is my favorite Extension so far. Primarily for the "shops" usage. The rest I'm still trying to get my head around. In other words, would the following be an accurate example of using this extension?
[plane: Material] -> [world: Toril] -> [location: Faerun] -> [location: The North] -> [location: Delimbyr Vale] -> [town: Secomber] -> [building: The Singing Sprite Inn]
Also, I saw mention of being able to set currency rates soon. Is that going to be a separate extension or part of an update to this one?
ThankyouQuote:
Originally Posted by Maleioch
Exactly! Well done!Quote:
Originally Posted by Maleioch
You might want to consider this: [plane: Material] -> [system: Toril Space] -> [world: Toril] - but that's up to you.
You could take things further, if you wanted: [building: The Singing Sprite Inn] -> [location: Basement] -> [Portal: To who knows where?!]
Its pretty big, so its almost certainly going to be a co-Extensions (like the Weather and Organisations Extensions are a co-Extension). I wouldn't hold your breath through - this one isn't even scheduled for Soon(TM) yet.Quote:
Originally Posted by Maleioch
Cheers
Hello Dulux-Oz,
I ran into another problem with the Locations extension.
I've been creating towns, locations and buildings without issues, linking each to a parent (i.e., Town[Candlekeep] -> Building[Library] -> Location[1st Floor]). However, out of the blue, I can't link places anymore. When I drag a location to a another, it doesn't show in the corresponding tab (like when you have the sheet "locked"). And when I delete a location that is shown in another sheet, I can't put it back.
Coincidentally, it happened some time after I exported my module as backup, I'm not sure if it's related.
Modules are static be default, so that would explain not being able to add new links - the ability to remove links, on the other-hand, shouldn't be able to be done either. Let me take a look and I'll see what I can find.
The problem was on the actual (current?) campaign, not the exported module.
I was adding locations without problems, and then suddenly I couldn't anymore. I thought it could be because of referential integrity, so I checked each and every location by type (town, Building, etc.), as well as their parents.
I found that one location was referencing another by its old name, i.e. it showed "Candlekeep**WIP**" (the old name) instead of "Candlekeep" (the current name). Once I removed the old reference and added it again, everything started to work normally. I hope that was the cause of the problem, since I've already invested a lot of effort on the locations extension (which, by the way, is awesome!).
Thanks for answering!
have you tried to repeat that linking the old name issue on a new campaign to prove the error was caused by linking old names? I wasnt able to repro that issue so I'm just curious if that was the actual cause.
The bug hasn't shown itself again but probably will, since I tend to change the page names A LOT to represent their current status.
I'll post if I get it (or should I say "catch it"?).
That's probably not a good idea in general (not just for the DOEs) - Names are meant to be static (or near static) because we use them as a means of identifying things. Changing the name of something (while possible) is not something that should be encouraged (especially with non-Relational Flat-File Database like the one FG uses, and even more so when someone's tried to make a non-Relational DB Relational) so I'd be representing "status" some other way - but its up to you :)Quote:
Originally Posted by zeracool2k
Cheers
I was under the impression that objects in the database were stored and indexed by an id number string ("id-00023") and that the names were simply strings and not used for any identification.