OpenDoor and BashDoor

[Wounded_Lion]

143 OpenDoor(O:Object*)

This action will open the specified door. If the door is locked the creature must possess the correct key or have sufficient strength to bash the door. Some doors central to the plot doors cannot be opened. The active creature can stick on this action if it fails.

 

This action will not force a creature to bash a door (regardless of whether or not the creature possesses sufficient strength).

 

148 BashDoor(0:Object)

This action has not been seen to produce any results.

 

This description should read:

 

148 BashDoor(0:Object)

This action is miscoded in the default ACTION.ids file (the number 0 should be the capital letter O). To use it in your mod, include the following code in your setup tp2 file:

 

COPY_EXISTING ~ACTION.ids~ ~override~

REPLACE_TEXTUALLY ~BashDoor(0:Object)~ ~BashDoor(O:Object)~

BUT_ONLY_IF_IT_CHANGES

 

This action works as intended when the above code is used (download the Branwen NPC mod and direct Minsc to talk to Branwen to verify what I say). Please include the fix code in the description (even if the G3 Fixpack incoporates a patch to this action per my suggestion at its forum; not all of us use the G3 Fixpack).

 

The IESDP has been a useful resource to me. Thank you for your efforts in maintaining the project.

 

aWL

 

EDIT: typo ("IEDSP")

[Avenger]

Hmm, so BashDoor works if the ids file is correct, that's cool on one hand, and crap on the other

 

The problem is that if you compile a script with the good ids file, the IE will work well, but GemRB won't

Dialogs of course work the same way in the engines.

[Wounded_Lion]

Hmm, so BashDoor works if the ids file is correct, that's cool on one hand, and crap on the other

 

The problem is that if you compile a script with the good ids file, the IE will work well, but GemRB won't

Dialogs of course work the same way in the engines.

 

I don't understand. Isn't GemRB an ongoing open source project that aims to clone (and improve upon) the Infinity Engine? If BashDoor wasn't included in GemRB for some reason (which seems odd, btw), then why can't the action be coded and added to its next release?

 

Besides, the IESDP describes the IE, not GemRB.

 

aWL

[Avenger]

The answer would exceed the limits of this forum

[Wounded_Lion]

The answer would exceed the limits of this forum

 

I'll visit GemRB's website. Last time I checked (a looong time ago), it wasn't actually working to a degree that would allow for modding, so I probably need to catch myself up to current on the state of the project.

 

Anyway, about what I posted: Does anyone contest or verify my findings? Will the description changes make the next IESDP update?

 

aWL

[igi]

Will the description changes make the next IESDP update?

 

Probably - except for the .tp2 code.

[Wounded_Lion]

Probably - except for the .tp2 code.

 

I don't care whether or not you use my exact description; what I care about is the accuracy of the IESDP. I'd think that your answer would be a definite "yes" to updating the descriptions if you cared about the same (unless someone contests my findings).

 

Why wouldn't you include the fix code? If you can better my fix (better code, etc), then by all means do so, but why not give that extra bit of help to modders using the IESDP as a reference? It'd prevent unnecessary questions on the Q&A forums.

 

aWL

[devSin]

IESDP should be "vendor-neutral," which is why you don't see WeiDU code or IEEP instructions and stuff.

 

Anyway, that was igi's version of a definite "yes" (excepting the case where he may forgot and including the fact that the next IESDP update may happen in 2010). :-)

[Wounded_Lion]

IESDP should be "vendor-neutral," which is why you don't see WeiDU code or IEEP instructions and stuff.

 

Anyway, that was igi's version of a definite "yes" (excepting the case where he may forgot and including the fact that the next IESDP update may happen in 2010). :-)

 

Cool. I see your point about vendor-neutrality (WeiDU dominates, but I suppose some people might be using alternative methods of modding).

 

aWL

[igi]

It's a 'probably', as I cannot guarentee it will be in the next IESDP update (which is what your question related to). However, it will be an IESDP update, sometime.

 

 

I do try and keep the IESDP vendor-neutral; it's an IE modding reference, not a guide to using a specific tool. There is a fair amount of knowledge which should be recorded someplace, but not in the IESDP. The G3 dev wiki, the prefix list at BWL and the various tutorials are examples of this.

[igi]

Added to local copy. Thanks.