ACS: dynamic complex object to track multiple actioned tags?

[smeghammer]

I would like to be able to keep track of sector tags and whether they have already been acted upon.

 

As I described in this post, I want to trigger a monster trap. Well, actually SEVERAL traps. Therefore, I have several sets of bars flagged with different sector tags. I would like to be able to build, at runtime, a programmatic object (initially empty) that will hold the tag numbers and whether they have been triggered (basically a dynamic array or list). This should reduce the code and also allow flexibility of adding arbitrary additional traps of the same kind.

 

According to the  docs, this is not possible with ACS so I came up with this rather clunky script:

 

bool cage141triggered=0;
bool cage142triggered=0;
bool cage143triggered=0;
script 3 (int tag)
{
    bool _trigger = 0;
    switch(tag){
        case 141:
            if(cage141triggered != 1){
                cage141triggered=1;
                _trigger = 1;
            }
        break;
        case 142:
            if(cage142triggered != 1){
                cage142triggered=1;
                _trigger = 1;
            }
        break;
        case 143:
            if(cage143triggered != 1){
                cage143triggered=1;
                _trigger = 1;
            }
        break;
        default:
            //do nothing
    }
    if(_trigger == 1){
        floor_lowerbyvalue(tag,16,56);
    }
}

Now, this works fine, but does mean that I need to add more test flags and case clauses if I add more cage traps - which is programmatically uuugleeee...

 

What I would like to do is conceptually something like this (pseudocode):

//PSEUDOCODE
obj _tracker = {};
//or `arr _tracker = [];
script 3 (int tag)
{
    //test if passed tag has already been actioned: 
    if(!_tracker[tag]){
        //if not, set a property on the tracker that passed tag has now been actioned
        _tracker[tag] = 1;
        //or `_tracker.push({tag:1})` if an array-type object

        //the hardcoded cruft should now reduce to something like this: 
        floor_lowerbyvalue(tag,16,56);
    }
}

Yes, I know that there is no concept of this data type for ACS, but I was wondering if I could spoof it somehow - by utilising a hidden line with setLineSpecial, CREATING map elements to use as variables, utilising a dummy actor somehow? 

 

I'd love to hear any thoughts on this as I am sure that something like this is entirely possible. Thanks in advance.

 

[Gez]

You can use a non-dynamic array.

#define NUMCAGES 3
#define FIRSTCAGE 141
bool cagetriggered[NUMCAGES]; // pretty sure they all get initialized to 0 by default
script 3 (int tag)
{
	if (tag >= FIRSTCAGE && (tag - FIRSTCAGE) < NUMCAGES)
	{
		if (cagetriggered[tag - FIRSTCAGE] != 1)
		{
			cagetriggered[tag - FIRSTCAGE] = 1;
			floor_lowerbyvalue(tag,16,56);
		}
	}
}

Now, it's not as elegant as it could be with a map or other sort of semi-infinite array, but you only have one value that needs to be updated when you add more cages, and it's NUMCAGES.

[smeghammer]

Nice. Thank you, definitely a neater static solution. Though I think I would need to ensure the cage tags are sequential. It falls over if non-sequential tag numbers are used (for example if I re-purpose an old tag number):
 

numcages = 3
firstcage = 11
tags:[11, 12, 15]

tag>=firstcage = true //for all
tag-firstcage < numcages //fails:
11-11 = 0 //true
15-11 = 4 //false

 

[Gez]

Yeah, if you make nonsequential tags then you'll need another layer of indirection:

 

#define NUMCAGES 3
int cagetags = { 11, 12, 15 }
bool cagetriggered[NUMCAGES]; // pretty sure they all get initialized to 0 by default
script 3 (int tag)
{
	int i;
	for (i = 0; i < NUMCAGES; ++i)
	{
		if (cagetags[i] == tag && cagetriggered[i] != 1)
		{
			cagetriggered[i] = 1;
			floor_lowerbyvalue(tag,16,56);
		}
	}
}

 

Now you have to update both the cagetags array and the NUMCAGES constant, and that's where a problem might creep if they get out of sync.

[smeghammer]

That's cool yes. As you say, it gets more complex and error prone, as well as more iterative - at what iteration size/nesting would it be noticeable performance wise?. This is an edge case though I think. But good to know there is a workaround. And this is a neat construct for wider programming use as well.

 

Thanks for your suggestions - most helpful.