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?
When does a resource need to be a core resource
Débuté par
stuntpope
, déc. 10 2009 11:57
#1
Posté 10 décembre 2009 - 11:57
#2
Posté 10 décembre 2009 - 06:25
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
Posté 11 décembre 2009 - 06:01
That's my experience, too.
@stuntpope - where exactly in the wiki did you see this statement? It's not on the Item page.
@stuntpope - where exactly in the wiki did you see this statement? It's not on the Item page.
#5
Posté 11 décembre 2009 - 09:45
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.
I haven't had any problems yet with items made as module resources, but perhaps there's an issue we don't understand.
#6
Posté 11 décembre 2009 - 11:20
@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.
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
Posté 11 décembre 2009 - 02:57
Yeah that line about dependencies is pretty vague too.
It almost borders on mocking us..."ha ha here's a place you're sure to get into trouble!"
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.Be aware of dependencies between core and non-core resources; especially around scripts.
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
Posté 11 décembre 2009 - 06:55
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.
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
Posté 11 décembre 2009 - 10:03
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
Posté 12 décembre 2009 - 12:33
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.
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
Posté 12 décembre 2009 - 10:21
Bryan - great explanation, as always. I've taken the liberty of updating the wiki.
#12
Posté 13 décembre 2009 - 12:36
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.
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
Posté 13 décembre 2009 - 02:55
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?
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
Posté 15 décembre 2009 - 11:47
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
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





Retour en haut






