Aller au contenu

Photo

When does a resource need to be a core resource


13 réponses à ce sujet

#1
stuntpope

stuntpope
  • Members
  • 112 messages
In the wiki it says:

Any item that the player can use or that a creatures drops for the player, needs to be a core resource.

Why? What if I am making a stand alone module or a campaign separate to the single player campaign?

Does this still apply. So long as all the resources shared between modules in my campaign all belong to the root module in the hierarchy, shouldn't that suffice?

As far as I can see there is a problem with having to make things core resources. Because of dependencies once you make an item a core resource you would need to make any scripts associated with the item a core resource and then any GDAs etc. The problem is that once you put GDAs in a core folder they start affecting every module, not just the ones they're intended for.

Does anyone know?

#2
avantoreon

avantoreon
  • Members
  • 115 messages
I've added items in custom modules that the player can use outside of that module without making the item a core resource, so at the very least you don't seem to need to make items be core resources...

#3
Proleric

Proleric
  • Members
  • 2 357 messages
That's my experience, too.



@stuntpope - where exactly in the wiki did you see this statement? It's not on the Item page.

#4
Axe_Murderer

Axe_Murderer
  • Members
  • 279 messages
He must have read it here.

#5
Proleric

Proleric
  • Members
  • 2 357 messages
Hm... I wonder whether Bioware could clarify or explain?

I haven't had any problems yet with items made as module resources, but perhaps there's an issue we don't understand.

#6
stuntpope

stuntpope
  • Members
  • 112 messages
@Axe_Murderer - thanks for tracking down the link for me.



It's good to hear that people haven't found any problems but I would also like to hear a Bioware clarification. They must have meant something when they wrote it. It may have only pertained to the original campaign though.

#7
Axe_Murderer

Axe_Murderer
  • Members
  • 279 messages
Yeah that line about dependencies is pretty vague too.

Be aware of dependencies between core and non-core resources; especially around scripts.

Sounds ominous, yet no reasons given as to why one should be aware of those dependencies or what the consequences will be for those who are unaware, and why scripts need special attention that other resources presumably don't.

It almost borders on mocking us..."ha ha here's a place you're sure to get into trouble!"

Modifié par Axe_Murderer, 11 décembre 2009 - 03:03 .


#8
BryanDerksen

BryanDerksen
  • BioWare Employees
  • 273 messages
The reason items were recommended to be made core resources instead of module-specific resources is because it is possible for the PC to be imported from one module into another one that doesn't necessarily inherit the first module's resources.



So for example, in module 1 the player picks up the item super_sword_1, which is a module-only resource. "super_sword_1" is now in the player's inventory. He saves the game, then switches to module 2 and starts a new game by importing his character from the save he just made. The save says the player's got "super_sword_1" in his inventory, but module 2 has no idea what that is. So the player loses his sword.



The dependancies issue is similar. If you create super_sword_1 as a core resource, but make it depend on a script that's in module_1 to function, when you bring it into module_2 the sword will be present but it won't work because the script it depends on is missing. It'll also cause Builder-to-builder to sometimes fail to deal with super_sword_1 sometimes, since you can't B2B load something that's missing dependencies.

#9
cstanish

cstanish
  • Members
  • 90 messages

BryanDerksen wrote...

<snip>

He saves the game, then switches to module 2 and starts a new game by importing his character from the save he just made.
<snip>


Is this actually as simple as it seems to sound?  I've been looking into how to do this and haven't found it yet.

#10
BryanDerksen

BryanDerksen
  • BioWare Employees
  • 273 messages
Actually, it may need to wait for a game patch. None of the DLC content we've released so far has required the ability to import a character, so it wasn't properly tested and I think it might be broken right now. Future DLC will likely require this and I've seen work being done on it to make it work.



In fact, if you'd like a little peek into the potential future, take a look at the module_core script's resource history in the 1.01 database. I had to remove a CHARGEN_IMPORT_HERO event from the script to get it to compile for the current version of the game, it was apparently added since the 1.02 game patch got branched.



(And before everyone wastes a bunch of time database-diving for similar resource histories, that was probably the only interesting thing I had to tweak while building this database. Everything else was pure annoyance. Much of it dependency-related. :)

#11
Proleric

Proleric
  • Members
  • 2 357 messages
Bryan - great explanation, as always. I've taken the liberty of updating the wiki.

#12
stuntpope

stuntpope
  • Members
  • 112 messages
Thanks for that clarification Bryan.

It seems to me that I don't need to worry about it then, since if my module uses different backgrounds and classes which aren't going to integrate properly into somone else's module anyway then there is no point trying to take a saved character from my module and sticking it in someone else's module.

As the scripts that handle these things are hooked up into my module (I never overwrite the actual core resources) they will never run in the other module anyway (and if they did they would most likely break the module). Even if I overwrote the core resources it might not work since there is no guarantee that the other module uses those core scripts. So basically I see it as pointless to try and cater for people wanting to take characters from my module and use them in someone else's.

The only real use I see for character import is when two modules are linked in some way. In this case the two modules can share a common ancestor in the hierarchy anyway (or one descends from the other) and there is no problem.

Modifié par stuntpope, 13 décembre 2009 - 12:36 .


#13
Happysin

Happysin
  • Members
  • 42 messages
Bryan, can I interpret this to mean that it would be safe to keep module-specific items as not core? E.g. plot items for the first module and the like?



Furthermore, I've been doing really simplistic exports of my modules, when I start creating items that should go in Core, what's the best way to handle packaging that all together with the module-spcific overrides?

#14
BryanDerksen

BryanDerksen
  • BioWare Employees
  • 273 messages
Yes, it's safe to have plot items be module-specific. I imagine it would actually be a good idea to have them fail to load if you imported the character into another module, since there might not be any other way to purge them from your inventory.

For packaging up resources for the player to use, use the "Builder to Player" packaging process to create a DAZIP containing all the resources the player will need (both core and non-core). The DA updater program will be able to install everything into the correct places from that. http://social.biowar...ilder_to_player