Basic Unit Pointers

[UNN]

Hi,

A couple of functions that might come in handy for anyone who wants to store an integer value with individual infantry units.

UNN_SetInteger is used to embed an Integer value, ranging from 1..999 into a Soldier.

Code: [Select]

[<Soldier>,<Integer>] Call UNN_SetInteger
UNN_GetInteger is used to retrieve an Integer value, ranging from 1..999 from a Soldier.

Code: [Select]

[<Soldier>] Call UNN_GetInteger
It appends the integer to a units rating, it places the number after the decimal place so it does not interfere with OFP, works with MP and save game.

I won't go into to much detail about what it could be used for, the best example I can think of is arrays. You can use the functions to point to array indexes with individual soldiers, so you could create a virtual backpack e.t.c

Download the two functions here:

UNNGetSetInteger.zip

[Bluelikeu]

This sounds interesting. Is it possible to use the integer value as a reference so that I may use that instead of the soldiers name when doing scripting.

Thanks,
Bluelikeu

[UNN]

Hi,

Sorry I missed this.

This sounds interesting. Is it possible to use the integer value as a reference so that I may use that instead of the soldiers name when doing scripting.

You can already, using global variables, like arrays. This just helps speed things up when your trying to find a specific unit, in an array of units. Or something else in an array thats being "pointed" to by a soldier.

But you could just use it to store an action ID, returned by AddAction.

[Fragorl]

Interesting lateral thinking UNN! That's a very quick and effective method of referring to units, without having to name them. I'd definitely use this over my functions for storing refs to units, especially if i wanted return values quickly.

Another thing in the ol' toolset ...

[h-]

Yeah, this is usefull stuff..

But if some mission maker happens to use for some reason (like lack of knowledge on the rating matter) an addRating 54.567 wouldn't this get funked?

Of course this is highly theoretical and if someone lacks the knowledge on the rating matter he/she prolly won't be using this either, so...

Hmm, maybe it's time to shift from 'Fragorl method' to 'UNN method' then...

[UNN]

Interesting lateral thinking UNN! That's a very quick and effective method of referring to units

I can't take credit for the Rating working around. Just writing the functions, I'm afraid. Cant remember where I read about raiting and decimal places.

Of course this is highly theoretical and if someone lacks the knowledge on the rating matter he/she prolly won't be using this either, so...

You run the same risk everytime you use an eventhandler in an addon, or a mission designer uses removealleventhandlers. Not to mention being able to overwrite some function names, with global variables. But you can test for a bad result from the pointer functions, then use the traditional method to re-index the Raiting.  Just as a backup.

Hmm, maybe it's time to shift from 'Fragorl method' to 'UNN method' then...

But on a serious note The method Fragorl uses works hand in hand with this one. You can also use eventhandlers to pass on index values, just as easy for anything that does not have a Raiting.

Code: [Select]

_Vehicle AddEventHandler ["killed","[_This Select 0,"+(Format ["%1",_Index])+"] Exec AnyOnldScript.sqs"]

[h-]

You run the same risk everytime you use an eventhandler in an addon

What you mean by this exactly?

Also, removeAlleventHandlers doesn't remove any config defined eventHandlers (in my exp.), but I'm sure you didn't mean this

Not to mention being able to overwrite some function names, with global variables.

True, but at least the chances for that happening can be narrowed down to quite small ratio with proper tagging...

The method Fragorl uses works hand in hand with this one.

Sure.
But I just see this a bit better solution for a couple of things I have in the works...
A lot faster for calls happening several times a second (at their worst)...
At least a lot less code

[Fragorl]

I definitely have to work on streamlining the code for mine/making it quicker.

Keep in mind that for these, there still has to be some form of list keeping track of them. However, it is much quicker to do a

{if (... function grabbing and comparing ratings ...) then {...}} foreach list

than to do mine (unfortuantely), since for me the funcs have to cleave through 2 layers of arrays to find if the unit/object is correct. But keep in mind that mine work for any type of thing, include bullets, buildings, and even arrays

[UNN]

Also, removeAlleventHandlers doesn't remove any config defined eventHandlers (in my exp.), but I'm sure you didn't mean this

I was not sure about addons, but as I'm increasingly starting to use script events within addons, I have to take it into account. I guess it's a balance between using pointers and script events, bringing some VBS features into Armed Assault, will tidy all this up.

A lot faster for calls happening several times a second (at their worst)...

I recently replaced a user action in someones addon that checked with NearestObject (something like every 0.4 seconds) with these function and there was a noticable improvent, lag wise.

than to do mine (unfortuantely), since for me the funcs have to cleave through 2 layers of arrays to find if the unit/object is correct. But keep in mind that mine work for any type of thing, include bullets, buildings, and even arrays

Yeah, searching through arrays had been the main stay of all my scripts. But pointers and other tricks to hold the indexs at specific points, do help increase the sizes of arrays you can work with.

But why two arrays, and not?

Code: [Select]

ArrayList=[[IndexObject,ThingsAdded,ThingsAdded,ThingsAdded],[IndexObject,ThingsAdded,ThingsAdded,ThingsAdded]]

[Fragorl]

Nearestobject at 2.5 times a second = bad

Hmmm, as far as how the data is stored, that is exactly how mine work:

ArrayList = [ [unitReference, [data1], [data2], [data3]] , [unitReference2, [data1]] ... ]

In actual fact it doesnt matter whether you have a 2+ dimensional array, or a linear array with everything stored sequentially eg
ArrayList = [unitref, [data, data, data], unitref, [data, data] ...]

I only opted for the former because in my mind it's slightly tidier and less prone to mistakes.

[h-]

Nearestobject at 2.5 times a second = bad

;D ;D
Try multiple simultaneous nearestObject calls (spanning over a circular area, size defined upon calling the function) in .2 sec intervals...

Anyway, the calls I was referring to can happen at least 5-7 times a second.. ;D :-X
Are not nearestObject though, 'just' storing/retrieving data with the set/getProperty...

I recently replaced a user action in someones addon that checked with NearestObject (something like every 0.4 seconds) with these function and there was a noticable improvent, lag wise.

I have to really start 'learning' to use this since this could actually get me rid of that above mentioned 'nearestObject abhorrence', and some other nearestObject hell I have going on...

All this pointer stuff is just too 'real coding' for my old rusted brain
*shivers/sweats as having some old C flashbacks..*

I was not sure about addons, but as I'm increasingly starting to use script events within addons, I have to take it into account.

If you issue addeventHandler in a script then removeAllEventHandlers will 'kill' it...
Not configged ones...

Also, I have not had any trouble with EHs at all..
Tried for example configging an eventHandler to a unit, adding the same event in the editor pointing to the same script as the configged one and both EHs were 'triggered' and both run their own instances of the same script...
But this is getting off the point

[UNN]

Hmmm, as far as how the data is stored, that is exactly how mine work:

Yeah, my mistake. I thought you ment two seperate arrays.

have to really start 'learning' to use this since this could actually get me rid of that above mentioned 'nearestObject abhorrence', and some other nearestObject hell I have going on...

The addon I was reffereing to was used on CSJ Medical Evacuation helicopters. The nearest object command was used to enable a user action when the litter was raised up to the helicopter. I just used the pointers to point to an array that includes the status of the litter object. Swapping nearestobject for:

Code: [Select]

((Litter_Array Select ([Driver This] Call GetPointer)) Select STATUS_INDEX)==LITTER_RAISED
I could get away with using this on a heli, because the script will only be run when it's flying. So there will always be a pilot available, to hold the pointer.

Also, I have not had any trouble with EHs at all..
Tried for example configging an eventHandler to a unit, adding the same event in the editor pointing to the same script as the configged one and both EHs were 'triggered' and both run their own instances of the same script...
But this is getting off the point

It quite on-topic regarding when you can use these functions, and has convinced me to take the extra time to add them. When possible it's better to use the pointers than script events, even though script events allow you to pass your own variables around at higher speeds:

Code: [Select]

_Vehicle AddEventHandler ["killed","[_This Select 0,"+(Format ["%1",_Index])+"] Exec AnyOnldScript.sqs"]
As you say, to avoid having this event removed. I should have written it into the configs event:

Code: [Select]

killed="[_This Select 0,[Driver (_This Select 0)] Call GetPointer] Exec AnyOnldScript.sqs";
You have to be carefull using Raiting though, you start mixing it with another addon that also uses the same principle, there could be trouble. If you use it for specific tasks like the chopper pilot or a complete MOD, then it should be ok. Although I should have added some code to the getin and getout events of the pilot, to store and restore, his original raiting when he is not flying.

[h-]

There's also the trouble with vehicles that the vehicle's rating is the vehicle's driver's rating and if in a tank a commander switches to driver's seat the vehicle now uses the commander's rating thus if getInteger is now called on the vehicle it's not getting the correct stuff...

Untested, but I had this trouble when I was assing about with the rediculous getRank function...

I just used the pointers to point to an array that includes the status of the litter object

I was thinking that a looping script checking a distance between two objects would be much less laggy than a looping script using (multiple) nearestObject calls to search for an object on a certain area...
After all the OFP distance function basicly getPosses those two objects and calculates the distance between those positions, or something...

So if I add objects to an array upon their initialisation and setInteger them and then make a script that checks distances between an object and the objects in the array (using getInteger instead of foreach for example) it should lessen lag...

Or am I barking at a wrong tree?

[UNN]

There's also the trouble with vehicles that the vehicle's rating is the vehicle's driver's rating and if in a tank a commander switches to driver's seat the vehicle now uses the commander's rating thus if getInteger is now called on the vehicle it's not getting the correct stuff...

Ah, cheers. Never came across this. AFAIK you cant even detect when something moves to back e.t.c with any of the get\getout events. But you can at least detect when the driver has lost his index, then use the loop through all, method once. Just to restore it, and remove it from the previous driver. Not as much of an issue for boats or aircraft.

So if I add objects to an array upon their initialisation and setInteger them and then make a script that checks distances between an object and the objects in the array (using getInteger instead of foreach for example) it should lessen lag...

Or am I barking at a wrong tree?

That would work just as well. Because it was a winch\litter I was working on. I just got the winch scripts to update the status of the litter, when it had finished raising, lowereing e.t.c

[h-]

Just tested that idea of mine (not in it's complete form though) but the lag was reduced insanely...

From about 20-30 FPS drop with nearestObject about to 5-10 FPS drop with this distance idea, with 100 instances of the script running

Didn't need the set/getInteger yet though but it might be needed once I get a bit further with this...