7 réponses à ce sujet

[Signo Vir]

I've been looking at the difficulty settings (difficulty.gda) and the related script in the toolset. There are a number of referenced columns in the script core_difficulty_h that are not labeled in GDApp or gffeditor. I understand that the column hashes are crc32, but I have not found any way to reproduce the values seen.

The column names in the script are (lowercased):

enemyflankbonus
defensebonus
suffix
dmgscalingthresh
srmod
srmodplayer
drmodplayer
drmod

which, for the most part, are easy to understand. drmod player, for example, likely modifies the player's damage resistance.

The problem is, though, that none of those match up to the CRCs in the file. I can't even get columns like "label", or "id", to work properly.

For example:

crc32 of "label" is 0EA750E8, or in decimal, 245846248, which is nothing like 3030163814 that is supposed to be.

It is probably something minor, but I'm hoping someone here knows what I'm doing wrong.

[mesmerizedish]

How are you viewing core_difficulty_h?

Or are you talking about Origins?

[Signo Vir]

I loaded up the toolset with the da2scripts.erf from the modding tools thread. Seeing so many DA:O references in itself wasn't unusual, though, given how many gda files contain old info as well. I got a bit suspicious, though, and unpacked the da2scripts.erf and noticed it only has two files, neither of which contain difficulty info.

So... the core_difficulty_h I was looking at was 100% from origins. Which means that either that didn't change (unlikely) or we don't have the scripts needed to affect difficulty scripts (amongst others).

This all started when I wanted to add friendly fire to difficulty levels other than nightmare, but it seems that, for the moment at least, it is impossible. (I am fairly convinced it is not a setting in a gda, but rather a scripted restriction)

[mesmerizedish]

That is a scripted restriction.

DAII's scripts are in designerscripts.erf in module/campaign_base.

And you can't view them, because they're all compiled, and we don't have the their source files.

[Signo Vir]

just so I understand clearly, what we *do* have is the constants in script.ldf and cscript.ldf from da2scripts.erf, the functions defined therein, and really nothing else.
When we compile scripts, the dependencies are also required, and so as long as we only refer to things in script.ldf and csript.ldf (and the da2 gda files accessed via GetM2DA*() functions), we can be fairly confident that it will work correctly. Anything else and it will probably break.

For example, we can create a new spell, with new visual effects to get the loot from a chest (PerformLootObject()), but not to unlock the chest because we don't have a known script for that. While this might seem minor, it also means we can't make a spell to unlock a door. Xatmos' lock bash mod probably works this way because of this restriction.

We could not, however, use a DA:O function that unlocks objects because it wouldn't get linked correctly in compilation.

that about right?

[Signo Vir]

Actually... I think I see a way to unlock objects...

there is a function SetPlaceableState( object oPlaceable, int nState ) and using the state values from statecnt_container and statecnt_door_* gda files, then it ought to be possible to unlock, and not just loot.

I have a rather lengthy list of spells and abilities I want to add/modify, but I think I'll start with an unlocking spell (assuming there's a way to use it outside of battle)

[mesmerizedish]

For the record: I'm not a scripter. What I know, I've just gleaned second-hand from my modding partner. As far as I know, there's no way to view the constants/functions in DAII's new .ldf files (if there is, please, let me know, because hoorayforicecream would have sex with an API browser).

Most scripts will work correctly simply by virtue of the language not having changed much. Some IDs are different between games, but they're all stored in .gdas which we DO have access to, so as long as we make sure we're writing with DAII in mind, bad sh*t shouldn't happen (ex: we wrote a script that modifies player health, but the ID for health in Origins is the ID for reserved health percentage in DAII, and until we noticed, we kept killing whomever we ran the script on XD).

If there's a SetPlaceableSate function, then you should be able to use it to unlock chests/doors, yes. You would probably have to award experience manually, however.

[Signo Vir]

extract the erf contents. there are two files: script.ldf and cscript.ldf. Both can be opened with a text editor. The top of both files include numerous constants like:

// Object types
int OBJECT_TYPE_INVALID = 0;
int OBJECT_TYPE_GUI = 1;
int OBJECT_TYPE_TILE = 2;
int OBJECT_TYPE_MODULE = 4;
int OBJECT_TYPE_AREA = 8;
int OBJECT_TYPE_STORE = 16;
int OBJECT_TYPE_CREATURE = 32;
int OBJECT_TYPE_ITEM = 64;
int OBJECT_TYPE_TRIGGER = 128;
int OBJECT_TYPE_PROJECTILE = 256;

In script.ldf there are about 500 lines of constants and about 100 lines of them in cscript.ldf.

In addition, both files contain function prototypes like:

/** @brief Returns the position of an object.
*
* Returns a position vector containting the xyz coordinates of the object oTarget.
*
* @param oTarget - The Object to get the position of.
* @return Returns a vector containing the position of the specified object. Returns an empty vector on error.
* @sa SetPosition()
* @author Brenon
*/
vector GetPosition( object oTarget) = 21;

/** @brief Signals the event to the specified object.
*
* Signals the specified event to the target object.
*
* @param oObject - The object to signal the event to.
* @param evEvent - The event to signal.
* @sa SignalEventToDataSet()
* @author Brenon
*/
void SignalEvent( object oObject, event evEvent, int bProcessImmediate = 0 ) = 105;

/** @brief Create an object in the specified location. Will attempt to use a corresponding pool if one exists.
*
* @param nObjectType - The object type (placeable, creature, etc)
* @param rTemplate - The template to use
* @param lLoc - Location of the object
* @param sOverrideScript - Script assigned to the object. If empty, the engine will use the template script
* @param bSpawnActive - Whether or not this object is enabled at spawn time
* @param bNoPermDeath - Set to TRUE to avoid destroying the object permanently (only valid for pool creatures)
* @param oAppearanceCopy - Set to the object which you want to copy appearance data from (*** ONLY USE THIS WITH APPROVAL FROM PROGRAMMING FOR SPECIFIC HITCHING ISSUES ***)
* @returns The new object, OBJECT_INVALID on failure
* @sa CreatePool, DestroyObject
* @author Jose
*/
object CreateObject( int nObjectType, resource rTemplate, location lLoc, string sOverrideScript = "", int bSpawnActive = TRUE, int bNoPermDeath = FALSE, object oAppearanceCopy = OBJECT_INVALID ) = 306;

/** @brief return an array of objects enclosed by the specified shape
*
*  Returns all objects enclosed by a specific shape.
*
*  Parameter Info for generic parameters fA, fB, fC:
*
*  SPHERE:    fA = radius (meters)
*  CONE:      fA = radius (meters), fB = angle (degrees)
*  RECTANGLE  fA = length, fB = width
*
* @param nObjectTypeMask Which objects to look for
* @param nShapeId the shape to use
* @param lLocation origin and direction for this shape
* @param fA floating point generic parameter
* @param fB optional floating point generic parameter
* @param fC optional floating point generic parameter
* @param bExcludeDead filter out dead objects if necessary
* @author Jose
*/
object[] GetObjectsInShape(int nObjectTypeMask, int nShapeId, location lLocation, float fA, float fB = 0.0f, float fC = 0.0f, int bExcludeDead = FALSE) = 673;


etc. There are hundreds, if not thousands, of functions listed.

Modifié par Signo Vir, 17 août 2011 - 08:02 .