DOE: Locations Extension

[viresanimi]

And don't worry, you're not being "THAT GUY"

No.. that would be me! *cackle*

But wow. That coding stuff you're doing seems darn complicated. I thought the whole point of Core was that everything would be nice and same-y with similar structure. But I guess individual rulesets still makes things difficult is a thing I didn't think about. Gotta say I am impressed you're going for "this works for everything"!

Vires Animi

[dulux-oz]

No.. that would be me! *cackle*

Yes, but that's OK

But wow. That coding stuff you're doing seems darn complicated. I thought the whole point of Core was that everything would be nice and same-y with similar structure. But I guess individual rulesets still makes things difficult is a thing I didn't think about. Gotta say I am impressed you're going for "this works for everything"!

Vires Animi

Yeah, Savage World has proven to be the most "difficult" - primarily I think because it was originally done under FGv2 and we were all "doing our own thing" back then. SW is a complex piece of code and the original architectural design decisions were different from the ones Moon used for 3E and 4E. When Moon retrofitted 3E and 4E into making CoreRPG naturally he used the same architecture as he had done before. When Doswelk, Ikael and Phantom Whale ported SW over to work with CoreRPG it looks like they made the decision to get their existing architecture to work with CoreRPG, instead of modifying the the SW architecture to sit on top of CoreRPG the same way that most other CoreRPG-child-rulesets do. That was a perfectly valid decision and almost certainly involved less work (& therefore time) to get SW working properly under FGv3.

The problem with doing this is when SOBs like me come along and try to create cross-ruleset Extensions (especially complex cross-ruleset Extensions) we hit this "different architectural wall" and have to either work around it or abandon support for the "difficult" Ruleset - and I don't like giving in!

[Ikael]

Just to clarify some things about Savage Worlds ruleset architecture and background, the ruleset has been around from FG v1 version, in FG v2 it was reimplemented to meet the new ruleset building model. There has always been many commercial products for it and the most important factor (business-wise) is to keep all those other products compatible with it. Savage Worlds v3.4 version upgraded its architecture (hidden from the audience) to match more on the current 4E ruleset architecture and to be honest it's still like that atm. Move to under CoreRPG was another massive retake but still the most important factor was to make sure existing products are compatible with it. The ruleset can and might be refactored to match CoreRPG even more, but the first move was not to make giant leap, just to make sure the baseline is working. The biggest issue has been that currently there are several product developers and coordination with them is challenging if we make significant changes to existing code.

Since Savage Worlds v3.5 to current beta of v4.2 I have been doing 99% of the coding for the ruleset plus code upgrades to most of the other commercial extension driven Savage Worlds products (50 Fathoms, Fantasy Companion, Horror Companion, Interface Zero, Necropolis, Rippers, Savage Suzerain, Science Fiction Companion, Slipstream, Sundered Skies). Like you, I am not paid at all, but probably not because no on wants to pay me, but that I have made decision to do all this for free and because of my own interest. The driving force for me is that it has been interesting and fun to do it, but it won't last forever. I am happy about my contribution to community so far and would love to help around making the Savage Worlds ruleset even more CoreRPG-like, but current setup might not motivate me enough to do it. At the moment I am more interested opening the secrects of the current Savage Worlds ruleset to others in hope others would start, dunno, taking my place.

-- I have promised myself to at least check your latest request of code change (since others don't have time for it) but not sure if I will do changes for it, depending on the complexity level and backward compatibility checking.

Yes, but that's OK

Yeah, Savage World has proven to be the most "difficult" - primarily I think because it was originally done under FGv2 and we were all "doing our own thing" back then. SW is a complex piece of code and the original architectural design decisions were different from the ones Moon used for 3E and 4E. When Moon retrofitted 3E and 4E into making CoreRPG naturally he used the same architecture as he had done before. When Doswelk, Ikael and Phantom Whale ported SW over to work with CoreRPG it looks like they made the decision to get their existing architecture to work with CoreRPG, instead of modifying the the SW architecture to sit on top of CoreRPG the same way that most other CoreRPG-child-rulesets do. That was a perfectly valid decision and almost certainly involved less work (& therefore time) to get SW working properly under FGv3.

The problem with doing this is when SOBs like me come along and try to create cross-ruleset Extensions (especially complex cross-ruleset Extensions) we hit this "different architectural wall" and have to either work around it or abandon support for the "difficult" Ruleset - and I don't like giving in!

[dulux-oz]

@Ikael => Mate, I understand completely. My comments weren't meant as a slur on you and the others and if that's how they came across I unreservedly apologize.

What I was trying to convey was why the new version of the Extension was taking so long to release - that's all!

I personally think the SW ruleset code-base is very good, and the more I delve into it the more I've grown to respect your (and the others') coding skills - you've taught me a few things which have helped my own code.

I know how popular SW is on FG and I'd simply like to make sure that I and my Extensions can be helpful to the SW user-base as well as the various DnD ones - its your code so its me who needs to come up with solutions, which I'm trying to do.

Anyway, let's take this off-line - I've sent you a PM

Cheers

[Nickademus]

Just had the weirdest thing happen when using this extension. Not sure how it happened, but I figure you'll want to know about it.

I'm working on a campaign that will be turned into a module (and already has been a few times). I had another adventure module open for some reason, linking an item from it to an NPC in this campaign I think. The NPC nor the item have any relation to the location I'm about to refer to.

I went to make a new location and pulled up a building/shop that I had previously made to use as a reference. Upon noticing the adventure module was still open and I no longer needed it, I closed it in the module activation window. All the items in the previously made shop disappeared. I opened the adventure module again and all the items reappeared. I closed the campaign and took a look at the xml files for the campaign database, the adventure module and the module of the campaign that I had exported in the past. I can't find the itemlist for that building in any file. Yet when FG is running and I open the adventure module, the list appears in the building (whether it is the current campaign or opened from a module in another campaign).

I have no idea how the itemlist became dependent on a separate module being open. I am recreating the building/shop and find the itemlist in the new one is not tied to the adventure module. Though, I'm still very curious where FG is getting the data for the building's inventory in the first place. The itemlist in the campaign db.xml and the exported module looks like this:

				<itemlist>
				</itemlist>

EDIT: Actually, upon looking further, I think I see what is happening. There were no items in the itemlist for the building/shop in the campaign. (I'm not sure if I just didn't put them in or if the list got deleted somehow.) The list that is showing up is actually the first list in the first opened module. When I close the adventure module and open a different one, the list in the building/shop of the current campaign changes to the inventory of the first building in the new module.

It looks like either FG or the extension is looking for something in the <itemlist> tag and when it doesn't find it in the current campaign it grabs something from a module.

[dulux-oz]

Curious, I've never seen that happening before.

There's nothing in the Extension Code (that I know about / can find) that would do that. I wonder if its in the fg.exe code somewhere - but if it was then why hasn't it shown up before - except that this is (I believe) the first Extension to tap into the Item system.

I've just tried to reproduce this under the new v4 Extension and I can't get it to happen, so it may have been fixed with the new code.

I think I'll keep an eye out for it in the new version, and see what, if anything, turns up

Thanks for letting me know

Cheers

[Moon Wizard]

It sounds like somewhere a windowlist is somehow pointing to module data. It can be done by the windowlist.setDatabaseNode or the windowlist.usealltrees flag. If you use either of these features in your extension code, it might be worth looking there.

Cheers,
JPG

[dulux-oz]

Yeah, that's what I initially thought - but I'm pretty sure those two are not used in the Extension.

As I said, curious

Cheers

[Nickademus]

Something else that might be related. I'm not sure exactly what's going on here, but these are my observations from a user's perspective.

The items in the building inventory do not seem to be hard copied. They seem to be links to the item module I drug them from. When I change the weight or cost field in the inventory, it changes it in the item information when the link is clicked AND it changes it in the item module when the item is pulled directly out of the module. (I'm not saying it is physically changing the module file, but rather putting a change in the moduledb.xml file so that the item module uses the values of the item in the building inventory.)

Most of the time, an item is hard copied directly into a parcel or a PC character sheet. (I think it only copies a link into the Items window list, which is why I always use parcels now.) It would probably be better to use the same method that the rulesets use for adding an item to a PC sheet. That might avoid databasenodes from being linked to the building inventory list.

[Moon Wizard]

That's good info. It sounds like the store item listing only saves references, not copying item records.

Regards,
JPG