action #205

[Avenger]

While trying to decypher what individual actions might do, i stumbled into the unknown action #205.

Apparently it is a minor variant of the Wait(x) action.

I don't know the difference, or if it works at all, but other small variants seem to be consistent enough.

 

I found it while i looked at actions which could be run from the global script, so it may or may not work as a creature action.

[Avenger]

I also found the following things that i couldn't understand:

 

These actions wouldn't do anything in a global script:

102 MoraleSet(O:Target*,I:Morale*)

103 MoraleInc(O:Target*,I:Morale*)

104 MoraleDec(O:Target*,I:Morale*)

135 LockScroll()

127 CutSceneId(O:Object*)

 

Note that UnlockScroll() DOES work from a global script.

 

These actions DO something in a global script:

82 CreateItem(S:ResRef*,I:Usage1*,I:Usage2*,I:Usage3*)

351 LeaveAreaLUAPanicEntry(S:Area*,S:Entry*,P:Point*,I:Face*)

 

Note that 350 LeaveAreaLUAEntry(S:Area*,S:Entry*,P:Point*,I:Face*) doesn't work in a global script.

 

Anyone could confirm or deny these findings?

[devSin]

Maybe it's a WaitInterruptible() or a WaitNoInterrupt() (and since it's the default behavior (I think), they never used it)? Or maybe it's just an internal/Lua thing?

 

What do you mean by "global"? A non-actor script or the funky Baldur.bcs?

 

LeaveAreaLUAEntry() has to be the laziest action ever. @igi - the points are defined exclusively in the Entry.2da (or Entries.2da or whatever it's called); it doesn't even check the ARE as far as I know.

 

I don't think the Morale*() actions do anything from any script anyway, so oh well.

[devSin]

I don't really want to test this, sorry. There was no difference in behavior between the following two, but I didn't even check to see if the WaitWait() actually does a Wait() action:

IF
HotKey(E)
THEN
RESPONSE #100
SetGlobal("waiting","LOCALS",1)
Wait(150)
END

IF
HotKey(F)
THEN
RESPONSE #100
SetGlobal("waiting","LOCALS",1)
WaitWait(150)
END

IF
Global("waiting","LOCALS",1)
THEN
RESPONSE #100
DisplayStringHead(Myself,1)
SetGlobal("waiting","LOCALS",0)
END

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

String 2 runs; pressing either E or F, string 1 runs about a second afterward, followed by string 2 the next second.

 

So #205 doesn't behave differently in this case, and Wait() is interruptible by default.

[Avenger]

Cool, then i just found another Wait action by my leet reverse engineering skillz.

How disappointing

 

By global i meant baldur.bcs, but i wouldn't be surprised if it means all non-living script running entity (in GemRB terminology, Sender) as opposed to Actors (creatures, pcs).

I'm still in the beginning of mapping the scripting stuff.

So far i just got a jump table for the non-living actions clearly marked those that wouldn't do anything.

The action code is far less understandable than the effect code.

 

[edit]

 

I forgot to mention:322 - FakeEffectExpiryCheck(O:Object*,I:Ticks*)

also doesn't do anything when using it from baldur.bcs. It is strange, as it does contain a target object.

[Avenger]

Ok, i've been looking further.

I think i can safely tell that the following actions don't do anything (in tob):

 

2 - AddWayPoint(P:WayPoint*)

4 - (unknown)

32 - (unknown)

35 - (unknown)

37 - FollowPath()

41-46 - (unknown)

70-81 - NidSpecialX

318 - ForceSpellRange(O:Target,I:Spell*Spell)

319 - ForceSpellPointRange(P:Target,I:Spell*Spell)

 

The following actions DO something (this doesn't mean it is anything useful or safe):

6 - (unknown)

12 - (unknown)

93 - (unknown)

101 - (unknown)

205 - Wait(x) - appears to be the same as the other wait action (tested)

206 - Face(I:Direction*) - not tested, but all i can see points in this direction

[devSin]

2 - AddWayPoint(P:WayPoint*)

Really? It should just add a trigger point at X.Y -- I could have sworn I tested this. But without a way to name the point, I guess it wouldn't serve any purpose even if it does work?

 

318 - ForceSpellRange(O:Target,I:Spell*Spell)

319 - ForceSpellPointRange(P:Target,I:Spell*Spell)

Completely useless, yes.

 

You may want to look at ReallyForceSpellPoint* -- these work like ForceSpell() instead (for some reason), and I can make it crash by having a dead actor run this (where ForceSpellPoint* wouldn't crash).

 

Does it look like the DeathMatch* crap is really noop? What about TriggerWalkTo (#329)? UseContainer (#112)? UseDoor (#142)? (Actually, I've see UseDoor() crash as it runs to some ToggleDoor() function/method, so it tries to do something.)

[Avenger]

I have this info so far:

303 73 82 - DeathMatchPositionGlobal(S:Areaname*,P:Dest*,I:Player*)

304 73 82 - DeathMatchPositionArea(S:Areaname*,P:Dest*,I:Player*)

305 73 82 - DeathMatchPositionLocal(S:Areaname*,P:Dest*,I:Player*)

 

 

1. column is opcode

2. column is actor jumptable entry:

0-72 - individual actions for actors

73 - use global jumptable instead

 

3. column is global jumptable entry, which is:

0-a2 - individual actions for global (or actor which has no actor specific code)

a3 - noop

 

So, by looking at those 2 jumptables only, it looks like 303/304/305 got the same generic code (very small differences may occur), which is not conclusively duff.

I would have to look deeper, and it isn't easy for actions.

So far i could only see that Wait(x) equals SmallWait(x*15), but this is quite trivial, i guess.

 

All the other actions you mentioned do something, it isn't necessarily safe, as i said earlier

[devSin]

I wouldn't bother looking any more into the DM stuff; all crap, but I was just curious as to how much of it they left in or got around to implementing before shelving the whole thing.

 

Does the new Wait() take the same arguments? Maybe it's WaitOneRound() or something??

[Avenger]

What would this thing do?

Is it a kind of respawn point like the one in PST for Nameless?

Or?

[devSin]

What thing?

 

The death match stuff is just setting up the death match stuff. You all get transported to a dungeon with some gems, and you get to run around and frag the other MP chars and collect hidden gems to win. From the stuff that's implemented, that's what it looks like was intended, at least. You probably respawn when fragged instead of getting dropped (some chance you can still win if you collect the gems).

[Avenger]

Ok, action #6 just runs on an assertion (crashes).

ASSERTION FAILED!

File: ObjCreature.h

Line: 838

 

Exp: FALSE

 

Msg: no msg.

Run Debugger?

 

It doesn't even want to do anything else

 

But action #32 really does something, at least it tries to parse some parameters and appears complex enough.

[devSin]

Can you figure out parameter numbers/types?

 

How did you call #6 (e.g., Action6(), Action6(Myself))?

[Avenger]

action6(myself)

 

but it is totally useless, it really just calls into the assertion code

 

action32 is much much more interesting, i think it accepts at least an object as param.