Seeking further input into script variable substitution (TobEx)

[Ascension64]

Hi GemRB folks,

I'm currently in process of implementing variable substitutions and arithmetic operations in script and would like as much as input as possible from others as to how I can implement this optimally. Take a look at http://www.shsforums.net/topic/47494-wip-expanded-triggers/page__view__findpost__p__540285. The implementation has already changed significantly, but I will keep everyone updated as I work on things.

Asc64

[Ascension64]

While triggers are cached, are actions also cached? Does GemRB also use action lists stored on each creature?

If so, is it OK for TobEx to destructively modify actions in the creature action lists for variable substitution purposes?

[lynx]

Sorry, I can't be of much use in this discussion, it's something for fuzzie and Avenger.

[Avenger]

While triggers are cached, are actions also cached? Does GemRB also use action lists stored on each creature?

If so, is it OK for TobEx to destructively modify actions in the creature action lists for variable substitution purposes?

Yes, the whole script is cached and refcounts are used for the static pieces. All moving parts are stored in the scriptable itself.

 

If you want to modify triggers on the fly, you can easily do this:

there is a bitfield which has only one bit used (for negation)

Modify it to have flags for external variables.

The problem is, the old script compiler wouldn't know how to set this bitfield to other than 0 or 1.

And every re compilation with a wrong de/compiler would corrupt the new binary syntax.

 

About the argument type checks, i don't think we check too much about them. If there is a new combination that wouldn't work now, I could alter gemrb.

[Ascension64]

So once a trigger blocks evaluates to true, how do you queue up the actions on a Scriptable? Do you make a copy of them?

[Avenger]

So once a trigger blocks evaluates to true, how do you queue up the actions on a Scriptable? Do you make a copy of them?

 

 

We make an internal reference, with refcount increased.
void Scriptable::AddAction(Action* aC)
{
if (!aC) {
	print( "[GameScript]: NULL action encountered for %s!\n",scriptName );
	return;
}

InternalFlags|=IF_ACTIVE;
aC->IncRef();
if (actionflags[aC->actionID] & AF_SCRIPTLEVEL) {
	aC->int0Parameter = scriptlevel;
}

// attempt to handle 'instant' actions, from instant.ids, which run immediately
// when added if the action queue is empty, even on actors which are Held/etc
// FIXME: area check hack until fuzzie fixes scripts here
if (!CurrentAction && !GetNextAction() && area) {
	if (actionflags[aC->actionID] & AF_INSTANT) {
		CurrentAction = aC;
		GameScript::ExecuteAction( this, CurrentAction );
		return;
	}
}

actionQueue.push_back( aC );
}

 

 

 

Though, as i see, we already break this by modifying a value with scriptlevel... I wonder if that causes any problem.

And half of the time, we already create a new copy.

[Ascension64]

actionQueue.push_back( aC ); 

This looks like a copy. However, I don't necessarily see how you would use one action to modify the next action's details with that code above.

[Avenger]

actionQueue.push_back( aC ); 

This looks like a copy. However, I don't necessarily see how you would use one action to modify the next action's details with that code above.

Nah, it is a copy of a pointer. The action it points at is static. See incref earlier.

Anyway, implement whatever you like, we need to rewrite this stuff anyway, and we already have mechanisms to create non-static copies of actions.