InLine

[devSin]

I was unable to get InLine(S:S,O:O) to do anything. InLine(O:O) works, provided it's given an actor object. Adding the following to default.bs

IF
 InLine(Player1)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,1)
END

If Imoen can see Player1, the string runs. If Imoen can't see Player1, nothing happens. I was hoping this would have something to do with pathfinding (i.e., if there is a straight line between the calling and targeted actor that doesn't cross impassable terrain), but it appears entirely useless.

[devSin]

Follow(P:P) and Leader(P:P) do seem to work, but they need to be used in conjunction:

IF
 HotKey(E)
THEN
 RESPONSE #100
   ActionOverride(Player1,Leader([3363.2954]))
   ActionOverride(Player2,Follow([3363.2954]))
   ActionOverride(Player3,Follow([3363.2954]))
END

When added to default.bs, Player1 starts walking to the right point, hopefully followed by Imoen and Minsc (with very little collision -- each NPC seemingly "waits their turn"). Unlike MoveToObject() (or Point), the characters don't all try to fight for the target point, but instead line up in a nice row (in this case, it's Player1 -> Player2 -> Player3). Probably too flaky to be useful, though (it tends to fail more often than not).

 

This likely corresponds to the follow party formation (the targeting reticle only shows up for Leader(), the Follow()ing actors are doing something hard-coded that isn't MoveTo*). Or something.

[devSin]

It looks like JC was right when he mentioned CombatCounterGT() was hopeless (in ToB, at least). I haven't been able to get it to do anything at all sensible (it appears to always be false). CombatCounterLT() does work (so !CCLT() can be used in place of CCGT()), and CombatCounter() pretends to work. Adding the following to default.bs:

IF
 CombatCounterGT(0)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,1)
END

IF
 !CombatCounterGT(0)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,2)
END

will cause Imoen to run str 2 continuously (whether in combat or not). Any number can be supplied, and the results appear to be the same. Using the following code:

IF
 CombatCounter(5)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,1)
END

IF
 CombatCounter(4)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,2)
END

IF
 CombatCounter(3)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,3)
END

IF
 CombatCounter(2)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,4)
END

IF
 CombatCounter(1)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,5)
END

IF
 CombatCounter(0)
THEN
 RESPONSE #100
   DisplayStringHead(Myself,6)
END

will have Imoen only ever display str 6 when the party is not in combat (or the battle music is just tapering out -- it doesn't completely stop before the counter is reset). I've never been able to get a non-zero value to return true.

 

CombatCounterLT() works somewhat. I didn't do enough testing to determine the counter timing, nor when it resets, but the "counts down from 150" may be off (10 seconds seems a bit long for a full pass; it seemed to spend most of its time between 50 and 100 here).

[devSin]

ActuallyInCombat() is pretty skanky (for PCs, at least). After adding the following code to default.bs:

IF
 !ActuallyInCombat()
THEN
 RESPONSE #100
   DisplayStringHead(Myself,1)
END

IF
 ActuallyInCombat()
THEN
 RESPONSE #100
   DisplayStringHead(Myself,2)
END

If Player1 is sent off to attack the Jailkeep Golem, as soon as the combat counter starts, Imoen will run str 2 (even though she's nowhere near the golem, nor close to any enemy). ActuallyInCombat() will be true until the combat counter starts, and then Imoen will run str 1.

[devSin]

Keeping in mind that I didn't ever do extremely comprehensive testing, the following actions all work flawlessly here:

244 SaveLocation(S:Area*,S:Global*,P:Point*)
245 SaveObjectLocation(S:Area*,S:Global*,O:Object*)
246 CreateCreatureAtLocation(S:GLOBAL*,S:Area*,S:ResRef*)
297 MoveToSavedLocation(S:GLOBAL*,S:Area*)

Using global variables (vs. locals or area), I never encountered a situation where these had any effect even remotely resembling failure. I don't know the format the location coordinates are stored in, but all actions worked as expected.

[devSin]

The code to draw the CallLightning() effect is broken. If the exact object point is not onscreen, then the arc isn't drawn at all. If the object is at the upper end of the screen, the arc starts shooting off below the object. If you're lucky enough to be able to split the object at the upper end of the screen, the arc fans out and starts shooting around onscreen.

 

The instant death doesn't bypass minhp1-type immunities (Imoen, with IMOENHP1, didn't get killed). It's also hard-coded to run a random thunder ambient (it appears to actually use area ambient sounds, not the special effect sounds).

[devSin]

The IESDP description for ScreenShake() ("254 ScreenShake(P:Point*,I:Duration*)") should be updated to note that the Point parameter is actually the intensity (how far X and Y to "shake" the screen; the "shake area," if you will). I don't know if the x.y value is halved (e.g., 100.100 would add 50px to each edge of the screen for the shake area), or if the full amount is added to each side.

[devSin]

For all but the *Copy() variants, the first "usage" parameter in the CreateCreatureObject() actions is the facing direction. This corresponds to the following actions:

227 CreateCreatureObject(S:ResRef*,O:Object*,I:Usage1*,I:Usage2*,I:Usage3*)
232 CreateCreatureObjectDoor(S:ResRef*,O:Object*,I:Usage1*,I:Usage2*,I:Usage3*)
233 CreateCreatureObjectOffScreen(S:ResRef*,O:Object*,I:Usage1*,I:Usage2*,I:Usage3*)

I was hoping that the additional parameters would allow destination coordinates to be defined (i.e., (S:NewObject*,O:Object*,I:X*,I:Y*,I:Face*), so that the creature would begin moving to the dest pt on creation), but no such luck. The following code added to default.bs:

IF
 HotKey(D)
THEN
 RESPONSE #100
   CreateCreatureObject("NDOG","Cell02",13,0,0)
END

Will always create NDOG near Minsc's cell door facing 13.

[igi]

Keeping in mind that I didn't ever do extremely comprehensive testing, the following actions all work flawlessly here:

244 SaveLocation(S:Area*,S:Global*,P:Point*)
245 SaveObjectLocation(S:Area*,S:Global*,O:Object*)
246 CreateCreatureAtLocation(S:GLOBAL*,S:Area*,S:ResRef*)
297 MoveToSavedLocation(S:GLOBAL*,S:Area*)

Using global variables (vs. locals or area), I never encountered a situation where these had any effect even remotely resembling failure. I don't know the format the location coordinates are stored in, but all actions worked as expected.

<{POST_SNAPBACK}>

 

 

The following code makes Player1 walk to position 0,0. Am I using it wrongly?

IF
 Global("something", "GLOBAL", 1)
THEN
 RESPONSE #100
   SetGlobal("something", "GLOBAL", 2)
   SaveLocation("GLOBAL","xxx",[770.640])
END


IF
 Global("something", "GLOBAL", 3)
THEN
 RESPONSE #100
   SetGlobal("something", "GLOBAL", 4)
   MoveToSavedLocationn("xxx","GLOBAL")
END

[Avenger]

Movetosavedlocation isn't used anywhere in the original game.

It could very well be that weidu compiles wrong code for it.

[Avenger]

IF
 HotKey(G)
THEN
 RESPONSE #100
   SaveObjectLocation("GLOBAL","position",Myself)
END

IF
 HotKey(N)
THEN
 RESPONSE #100
   MoveToSavedLocationn("GLOBALposition","")
END

 

This works.

 

The problem is that the original action.ids contains a wrong entry for it, and weidu doesn't merge the two strings.

[devSin]

It's been so long that I have no idea. I know I tested and they worked, but don't remember the specifics. I don't understand what Avenger is suggesting.

 

I think CreateCreatureAtLocation() is used in the original game (to create the dead paladins in AR1200).

 

EDIT: Now that I read it, I get it. I would have been using Near Infinity and probably LOCALS, all from Default.bs and None.bs, with HotKey() triggers. As stated, I didn't investigate how the coordinates are stored (it's a single value, obviously).

[igi]

Yeah, I've confirmed them all as working

This is all in the local copy (which really will be uploaded soon).