13 réponses à ce sujet

[JackFuzz]

1. I just created a module that extends the single player campaign as per this tutorial:

http://social.bioware.com/wiki/datoolset/index.php/Creating_a_module

2. I now have a new directory: 

Documents\\\\BioWare\\\\Dragon Age\\\\AddIns\\\\   globvars_mod

3. In the toolset I have globvars_mod (module) as the open module.  I can also see the single player campaign files. So far so good.

.....

The only reason I have resorted to using an extended module is so I can have access to local variables.

How can I use GetModule() and GetLocalObject now?  How does GetModule() know the difference between single player campaign and my new module? 

Modifié par JackFuzz, 10 janvier 2010 - 02:33 .

[AmstradHero]

If you've followed that tutorial, you should be fine. That's what I've done and my Add-In is working fine.



However, I don't know about GetModule(). What do you want to do to the module anyway?

[JackFuzz]

AmstradHero wrote...

If you've followed that tutorial, you should be fine. That's what I've done and my Add-In is working fine.

However, I don't know about GetModule(). What do you want to do to the module anyway?

Man i finally figured all that stuff out.  

Let's just say if you ever need two different scripts to access a global variable let me know and I'll point you to the right thread.

[Xetrill]

You have to roll your own var_module 2da table.
I suggest extending the default one, eg make an M2DA version from the default var_module.gda, if you have that put it in your core\\override folder. And finally adjust the module properties to use your knew table (you might have to Refresh before it shows up in the dialog).

And never forget, watch those ID ranges

[AmstradHero]

JackFuzz wrote...

Let's just say if you ever need two different scripts to access a global variable let me know and I'll point you to the right thread.

But "globals are evil", so I'd use plot flag instead. And provided the scripts are being run in the same area (or maybe in the same AreaList?), then surely you should just be able to store it on an object anyway?

Alternatively, is it possible to use SetLocalX on GetHero()?

[FalloutBoy]

AmstradHero wrote...
But "globals are evil", so I'd use plot flag instead...

This doesn't work if you need to store something other than a 1 or a 0.

[EJ42]

AmstradHero wrote...

JackFuzz wrote...

Let's just say if you ever need two different scripts to access a global variable let me know and I'll point you to the right thread.

But "globals are evil", so I'd use plot flag instead. And provided the scripts are being run in the same area (or maybe in the same AreaList?), then surely you should just be able to store it on an object anyway?

Alternatively, is it possible to use SetLocalX on GetHero()?

Globals are not evil.  You've just been tainted by bad programming instructors who don't want you to think for yourself.  Globals can be evil (and will probably cause you to break things accidentally), but it depends on your application.  Depending on the simplicity of your program, you don't even need the complexity of an object-oriented programming language.

I still have to write some assembly code.  PUSHing and POPing aren't bad as long as you know what you're doing.

Parameter passing is great and all, but if you think about it, the save game files are "global variables" themselves.

I've known far too many programmers who are more concerned with how "pretty" their code is than what it actually does.

Modifié par EJ42, 10 janvier 2010 - 08:42 .

[JackFuzz]

The only reason I'm FORCED to use globals is because playing cutscenes from a script is an asynchronous operation (stupid). 

[AmstradHero]

Just to clarify, I placed "globals are evil" in quotation marks because I'm fully aware that there are reasons to use them.   I did not intend to come across as preachy.

Hence why I offered the suggestion of asking whether local variables placed on the player object persist across area transitions.  This worked nicely in Neverwinter Nights 2 (and I think 1 as well) - I thought it might be a feasible option in DAO as well.

[Xetrill]

FYI GetLocal* and SetLocal* works only on variables that are in the var_*.gda that objects uses which the function is called on.

Besides that, didn't a Bioware dev mention that globals aren't supported somewhere?!

And variables set using SetLocal are persisted (stored in the savegame). Even if you would uninstall/deactivate an addin that and later install/activate it again, GetLocal would return the value stored in the savegame.

[JackFuzz]

Xetrill wrote...

FYI GetLocal* and SetLocal* works only on variables that are in the var_*.gda that objects uses which the function is called on.

Besides that, didn't a Bioware dev mention that globals aren't supported somewhere?!

And variables set using SetLocal are persisted (stored in the savegame). Even if you would uninstall/deactivate an addin that and later install/activate it again, GetLocal would return the value stored in the savegame.

hmmm i wonder if this will cause problems.

I'm using the var_***.gda in my own module and not the single player campaign.  Let's say a user uninstalled my addin completely.  That means the scripts would be uninstalled as well and there would be no GetLocal from my GetModule(). So hopefully there won't be any problems.

So if you save a game with my addin then remove the addin.  I guess the savegame will want the addin turned back on? hmmm..

These are things I'll let a potential user of my mod know ahead of time.  Once you start keep going till the end! 

[Xetrill]

> So if you save a game with my addin then remove the addin. I guess the savegame will want the addin turned back on? hmmm..

Yes, but not because of the variable, but because your addin would be stored in the savegames addin-list.

[AmstradHero]

If you have a save made while an Add-In was loaded, then subsequently disable the Add-In and attempt to load, the game presents a warning message stating that the Add-In (or Add-Ins if you've disabled multiple ones) are needed in order to load the save.



However, you can force load the save anyway - which will appears to ignore/not load any data associated with the Add-In. It seems that a subsequent save will no longer store any data associated with the Add-In and hence not produce the warning message.

[Xetrill]

Yes, no data associated with a disabled addin will be loaded. And if you save again afterwards, that disabled plugin would have been removed from the addin-list.

But no, savegame-wise there is no way of telling which item/talent/spell/etc. belongs to which addin. The engine will just not load anything that it cannot find a resource for (which might corrupt a characters stats).

Lets say you disabled an addin that had some item stored in a general override directory (such as GameDir/override or Documents/.../override), than it wouldn't matter if the addin that gave you the item in the first place was disabled, you still you posses that item.

Because the resource (the .uti in that case) can still be loaded/accessed.

A little side note, resources stored in these directories will always be loaded - they will always reside in memory.