DOE: Locations Extension

[dulux-oz]

Is there any way to remove certain tabs from this extension? For example, I don't need the Cosmos tab. Can I remove it in the code?

Only by re-coding the Extension ie unpacking it, finding all of the relevant references, removing them, re-writing any effected logic within the scripts, then (optionally) repacking the Extension.

Of course, if you do this then you'll have to do it again each time the Extension is updated.

If you do decide to go ahead and modify an Extension (anyone's, not just mine) its common courtesy to follow any copyright included with the original Extension and, at the very least, include an acknowledgement to the original author.

As a note each XML and Lua File in each of my Extensions has this copyright notice in it:

© Copyright Matthew James BLACK 2005-14 except where explicitly stated otherwise.
Fantasy Grounds is Copyright © 2004-2013 SmiteWorks USA LLC.
Copyright to other material within this Manuscript may be held by other Individuals and/or Entities.
Nothing in or from this File in printed, electronic and/or any other form may be used, copied,
	transmitted or otherwise manipulated in ANY way without the explicit written consent of Matthew
	James BLACK or, where applicable, any and all other Copyright holders.

I do NOT give permission for any of my code in any of my Extensions to be modified in any way, except for personal use by the individual performing the modification - that is, if you want to modify my code you can, but only YOU are allowed to use the resulting modified code; it MUST NOT be given to anyone else - in other words, follow the spirit of the copyright as well as the letter.

Also, I won't/can't support any of my Extensions that have been modified by someone else - I'll do what I can to help, but if you do such a thing you do it under this understanding.

So, with all of that in mind, is what you want really worth it? The offending tab takes up very little screen real-estate, isn't it easier to just ignore it?

Or have I missed the point entirely?

Cheers

[dr_venture]

Hey Shemantis, I just wanted to echo DO's comment about updates: if you edit his code, then every time he publishes an update, you'd have to go into the code and make the changes all over again. Or, you'd have to not install the update. Basically, there's no convenient way to patch an extension in FG. About the easiest thing you can do would be to change the graphic for the tab to be blank or greyed-out -- then at least when an update comes out, you'd only have to unpack the ZIP, stick the new graphic into the images folder, the repack it. But that would only hide the text of the name, not hide the underlying tab.

A pain, but that's FG, not DO's work. :P

[shemantis]

Oh man, it is totally not worth all that effort.
It's an absolutely fantastic extension as-is, and I wouldn't actually be making it any *better,* haha!
Thanks, all!

[dulux-oz]

Oh man, it is totally not worth all that effort.
It's an absolutely fantastic extension as-is, and I wouldn't actually be making it any *better,* haha!
Thanks, all!

Glad you like it - and listen, keep asking question/making suggestions - Dr.V. and others did/does and I've incorporated the best ideas into new versions (and continue to do so) - the trick is, adding things that are going to be useful to everybody and not taking functionality away - which is why most of the fields on the various forms will be hidden when empty and the record is Locked - if a GM doesn't want to use a particular field (eg Alignment in a non-Alignment game) then they just have to ignore it and Lock the record - and its best-practice to Lock the Records anyhow

Cheers

[shemantis]

I think the most important thing to me is: Continents!

I currently use the "Locations" tab for continents, but I would love to have a structure similar to this (things in parentheses aren't used by me, and were what I was thinking about removing in my previous post):
(Planes>Cosmos>Systems>) Worlds>Continents>Locations/Areas>Towns>Buildings

I understand that everyone's campaign/DMing style means everyone needs something different, but the structure above is my ideal structure, and of course, what *I* think makes "perfect sense," lol.

Just throwing it out there, in case you ever feel like re-arranging things, haha!

[Nickademus]

I think the most important thing to me is: Continents!

I currently use the "Locations" tab for continents, but I would love to have a structure similar to this (things in parentheses aren't used by me, and were what I was thinking about removing in my previous post):
(Planes>Cosmos>Systems>) Worlds>Continents>Locations/Areas>Towns>Buildings

I understand that everyone's campaign/DMing style means everyone needs something different, but the structure above is my ideal structure, and of course, what *I* think makes "perfect sense," lol.

Just throwing it out there, in case you ever feel like re-arranging things, haha!

I would have to agree with this. Not many would actively use it, but a small section for continents (and a large section for planes!) would be nice for organization and flavor.

[dulux-oz]

I would have to agree with this. Not many would actively use it, but a small section for continents (and a large section for planes!) would be nice for organization and flavor.

First of all, I do not believe anyone is trying to start an argument (least of all me!)

Secondly, I always enjoy a good discussion/debate, where the different sides put forward their views and reasoning's in a spirit of healthy discussion

So with that spirit in mind, I say to you both (Nick & shemantis) and anyone else who cares to chime in:

But we can do this now: a Continent is just a Location - we can see this by determining that there would be nothing recorded in a "Continent" Record that isn't already on a "Location" Record. If the structure of the two Records is the same (which I maintain they are) then it's silly to have two Records-types - its actually bad Database design.

Remember, don't get the design-structure of a Database mixed up with the use-structure (how the Records are used, as opposed to the Record-types).

This is the main reason that Location Records can be the Children of other Location Records - to allow the recording of areas, sub-areas, sub-sub-areas, etc.

Let's take the Continents idea to its logical extreme: within a World (or even a Plane) you could have a Hemisphere, within a Hemisphere you could have a Continent, within a Continent you could have a Region, within a Region you could have a Country (already available as a Political Location), within a Country you could have a State/Province, within a State you could have County, and so on. Now, I put it to you that all of these are just Locations (Political or Geographic, but Locations nevertheless) - would it be sensible to have a separate Record-type for each of these areas and sub-areas?

If we do go down this path, do we insist that all uses of the Extension must use this rigid structure, or do we allow Counties to belong directly to Continents (or anywhere else, for that matter)?

If we do the first, then we're restricting the usefulness of the Extension by a vast order of magnitude; if we do the second, then the code required to provide this level of "flexibility" blows out by several orders of magnitude.

And what about the Screen-real-estate? We'd have to provide a Tab for each Record-type (even if we, as individuals, would never use that Record-type). Screen-real-estate is already at a premium, so how would we go about doing this (in a consistent way with the rest of FG)?

So, I think you can see my reasoning behind designing the Extension in the way I have - yes?

OK, so, let's address your issue: It seems to me on reading both of your posts that this is an issue of organisation, so what I suggest is this - in the name of each Location put a prefix as to where the Location Record fits in to your individual use-hierarchy (I actually suggested this in a very early post in this thread ). This way, all of your "Continents" would be grouped together, all of your "Countries" likewise, all of your "Baronies" the same, etc, etc, etc. This way you build your use-structure into your usage of the Extension without effecting anyone-else.

Please, feel free to discuss any views you have - as I said, I love a good debate

Cheers

[dulux-oz]

I just received this as a PM and thought it was an important enough question (along with my reply) to be cross-posted here - I hope you don't mind, Kelendor.

Hi, we are interested in using the locations extention in our Star Wars Saga campaign but we are getting an error. Script Error: [string "Scripts/lsLocationsManager.lua"]:56: attempt to call field 'registerDockShortcut2' (a nil value) -- Is there a way to make it compatible? What inside of corerpg/scripts is the dependancy? Our SWSE uses desktop.lua and has some DesktopManager.XXX - If you let us know what dependencies there are we can try to add/move those scripts into the ruleset to see if we can make it work. Thanks!

Hi Kel,

The Locations Extension is ONLY compatible with the CoreRPG Ruleset and any child Rulesets of the CoreRPG Ruleset. The list of dependencies is vast - you've only found the first one: as you resolve each one the system will simply move on to the next and then stop again.

One of the reasons that SW went to the Cascading Ruleset Model for version 3 of Fantasy Grounds was to help alleviate these types of problems - by developing a "standard" set of base functions and functionality it makes developing new Rulesets and Extensions easier, (somewhat) quicker and - most importantly from the end-users' point of view - less prone to bugs and incompatibility issues.

The registerDockShortcut2() function is a base function used in the CoreRPG - I couldn't tell you exactly where to look in the CoreRPG Code without going and having a dig-around myself, but I know its fundamental to how FGv3 works.

The "problem" with the StarWars Ruleset is that it was written under FGv2, and while SW went out of its way to retain backward compatibility with all the older Rulesets when they went to FGv3, it doesn't mean that Extensions, etc, written for FGv3 will work with the older FGv2 Rulesets - as you've just found out

Not that your asking, but no, I'm not going to rewrite any of my Extensions to work with any of the older Rulesets - that would be a backwards step. I'd have to have a different one for each Ruleset, because each v2 Ruleset author "re-invented the wheel" and did things their way. It is easier, not to mention a better idea all around, to bring a given v2 Ruleset up to v3 CoreRPG Compatibility. You'd need to ask the Ruleset Author to do this or, if they've effectively abandoned it, get another dev to do it - for example, I've gotten permission from the original author of the Dragon Warriors Ruleset to rewrite it under the v3 CoreRPG Cascading Ruleset Model (he just wants a copy when I'm done ).

So, that's about it, I'm afraid. I'm sorry you're in this mess but that's the way it is - as I said, your best bet is to get the StarWars Ruleset bought up to FGv3 standard.

Anything else I can help with, just ask

Cheers

[dulux-oz]

I just received this follow-up PM and again thought it was important enough (along with my reply) to be cross-posted here - again, I hope you don't mind, Kelendor.

Since the best bet is to move the ruleset to version 3 could you either help me, offer me tips, or point me to documentation so I could move/update the ruleset to fantasy grounds 3? Also can I email you the ruleset and module so you could look at them.Thanks

OK, as I said, the first step is to get in contact with the original Author and see if he is doing/will do it.

If he isn't/won't, then next I suggest posting a thread in the relevant forum(s) asking if anyone else is doing/will do it - and maybe offering to help.

If you get no luck there then you'll have to tackle the project on your own - I'm afraid I don't have time to do it for you (and I doubt you could afford my standard Profession IT rates if I was to do it as a job ).

As far as documentation, check out the Ruleset Modification and Ruleset Reference on the Wiki, plus ask questions on the Armoury Forum - you'll get lots of help from me, Moon Wizard, Zeus, Trenloe, Phantom Whale and a host of others (sorry if I didn't mention you) - basically, any of the Immortals are people to listen to (that's one reason why we're Immortals), plus anyone else who seems to be a decent dev (ie if they've put together a Ruleset or an Extension before).

Your best bet in getting help is the forums as opposed to individual Personal eMails - you'll get a better, usually faster response - not that I mind getting PMs, its just that I'm not normally paying attention that much

Ask yourself this: are you a professional coder or are your coding skills up to a professional level? Be honest with yourself here: you're about to tackle a big job. You need to know (and I mean really know) XML, Lua, Programming Theory, how to Reverse Engineer someone else's code, and have a good general knowledge of Computer Science. If you don't then don't panic, you'll just need to hit the Web and learn - start with Wikipedia and go from there.

Good luck, ask those questions on the Forums, and be patient - you will get there in the end

Cheers

[swest]

So I tried your Sample_Locations_DB.mod, but it never appears on the modules screen... ?

I'm on my laptop using the 'free' version of FG (3.0.9). I unzipped the .mod, and placed it in the modules directory, and started the 3.5 Demo game. The Extension shows up, but when I open the Library, and go to the modules screen, no Sample_Locations_DB.

- s.west