Properties for objects

[Chad]

btw it also enables array
int i[][] = new int[100][100];

now try to figure out how it does that

or
Solider t[][] = new Solider[100][100];

Yes it will create an array of size 100 * 100 = 10,000 elements

[Fragorl]

Right.

This is an amazing invention, and I think there are quite a few people here at ofpec (me included!) who would be more than interested to hear about it, ask questions, etc.

I suggest that you start a new topic for the compiler, so that people know what you're discussing, perhaps an explanation/introduction so that people understand exactly what it does, how it benefits and improves the editor's job, and so on.

I don't think you're doing it justice by posting here, simply because I'm expecting very little traffic in this thread (maybe one or two people who see the functions and are interested), and consequently very few people will come looking in here for something original (;D - well, you know what I mean), or something other than what's already been mentioned above.

It's my fault I think for starting this thread in the 'ideas' board; it really belongs under beta testing now that the functions have been submitted.

I will gladly re-post my comments if you start a new thread.

[Chad]

Np. I will be doing an offical release in the next coming weeks. The offical release will contain alot of demostration material and documentation with the product. It will also have the second version of the AI hurristic map to show off the compilers full ability.

Until then i normal release small examples like this to public forum to get some intrest going in the product before release

[Fragorl]

This is a bit late coming, sorry Planck.

Yes, I have tried using 'else' in functions and it works fine. However in script, i'm not sure what the equivalent is for 'else'; i know '?' == 'if'.

But considering you can do everything by call commands anyway, instead of
? _bool : outcome1 = true
?!_bool : outcome2 = true
you could do
call " if (_bool) then {outcome1=true;} else {outcome2 = true;};"
so what i said wasn't technically right

[Planck]

I had a quick play with using 'else' in a simple script.

Code: [Select]

x = 2

#loop
if (x==2) then {hint format ["%1", "then"]} else {hint format ["%1", "else"]}
~3
x = x + 1
? x == 4 : exit

goto "loop"

It seems to work ok.......however.......

It doesn't like '?' or ':', it seems you must use 'if' and 'then' .....also note the curly brackets seem to be necessary also.

EDIT:  Also the normal brackets round the condition at the start seem to be necessary also.


Planck

[Fragorl]

H'm, so you don't need that 'call .....' business then. Great. And it looks like those semicolons you're forced to permeate functions with aren't required in script either. Usually, the parser complains if you leave out the ';' after the second set of curly braces in a .sqf (with an 'else'), likewise it complains if you miss out the semicolon after the first set of curly braces in a .sqf (just an 'if... then... {}; '). So not really like C++ in that respect.

[h-]

The .sqs parser considers the lines end to be the 'end of line', dunno how it checks it though...
For some reason the sqf parser needs the semicolon to know the end of line, but that's probably because it enables the use of 'formatted' code (whatever it's called in english )...


Anyway, I just dropped here to give hails because I was just about to start doing pretty much the same thing as these functions of yours do, gladly I checked the Ed Depot first

So, I will be using these then...
Saves me hrs and hrs of hair pulling...
I probably need to edit them a bit to fit my needs, if that's ok (don't worry; credit will be given...)...

Oh btw, some 'critics/sugs':
-It's not wise to use un-OFP tagged global variable... (variable conflicts are always possible)
-And/or why not give the function user a possibility to define the 'property array' (name it)...?
If this is used in many instances to set/get a lot of stuff it would be nice if you could cathegorise different things in different arrays (easier to keep track of them) and so the Properties array would't grow to have 1 000 000 arrays in it...
The search may become slowish when there's a lot of stuff in there...

[General Barron]

-It's not wise to use un-OFP tagged global variable... (variable conflicts are always possible)
-And/or why not give the function user a possibility to define the 'property array' (name it)...?

I was going to suggest the exact same thing. One other example of why you would want to do this would be if you are using these functions in an addon. Obviously, you wouldn't want the addon's variables to over-write any mission variables, so the addon's data array would need to have it's own name. Obviously, you could just edit the functions and change the var names yourself, but that is beside the point...

[h-]

Obviously, you could just edit the functions and change the var names yourself, but that is beside the point...

Quite...
In my case would need quite a few copies of these functions...

[Fragorl]

Thanks for the feedback, General and HateR

Anyway, I just dropped here to give hails because I was just about to start doing pretty much the same thing as these functions of yours do, gladly I checked the Ed Depot first

That's what they're for!

I was going to suggest the exact same thing. One other example of why you would want to do this would be if you are using these functions in an addon. Obviously, you wouldn't want the addon's variables to over-write any mission variables

No, in you can have two identical sets of the functions, one in the addon, one in the mission, and they will complement each other perfectly. You can simply have this:

["Mission Variables","MissionVar1",player] call SetProperty
["Addon Variables","MissionVar1", leader player] call SetProperty

which will work fine. Of course, nothing is stopping you from having different names for your global array.

Obviously, you could just edit the functions and change the var names yourself, but that is beside the point...

Well, no, that is precisely the point! Only a few quick edits to rename 'Properties' for each func, and you'd be sorted. That is quite alot easier than the alternative, supplying your Global Array name as an argument. I'd like to keep the number of arguments as small as possible; it makes for a tidier, more compact 'call' plus there's less to remember! And, you'd be essentially doing the same thing each time:
[object,"Property",value,"MY GLOBAL ARRAY"] call SetProperty

However, if it looks like having separate global arrays is a better idea becuase of what HateR said about array sizes getting too large, I will happily incorporate this argument in as well.

RE: tags. So I should make it 'FRG_properties'? I think I registered FRG a while back... have to check that...

[General Barron]

Well, you could make the "variable name" an optional parameter. If the editor doesn't specify, then it would use the standard FRG_properties var name. And yes, you definately should register and use a OFPEC tag for the global vars in your public scripts.  

[Fragorl]

Oops, I overlooked one very important thing (I think) -

If I allow the user to specify their own name. the function no longer sets itself up. Simply because, in order to modify the array you pass, you have to use 'call format' - like this

call format ["%1 = [blah blah...]", GENB_Properties]

and in order to do that you must FIRST say 'GENB_Properties = []' somewhere.

Ugh. I'm wondering if it's possible to do something like this:

[object, "name", value, GENB_Properties = [], "GENB_Properties"]

or something to tell the parser to create a new 'array' object first, and then use it from there.

[General Barron]

Ugh. I'm wondering if it's possible to do something like this:

[object, "name", value, GENB_Properties = [], "GENB_Properties"]

or something to tell the parser to create a new 'array' object first, and then use it from there.

Actually, that is possible. You can place ANY command within an array, and it will execute that command when it reads that line of script. I made a thread with that discovery somewhere a while back, but I don't think anyone came up with any real use for the fact.



There is a better solution, however, which you already use. At the beginning of your function, you already check to see if "properties" (the current global array) is instantiated, and if it isn't, you initialize it. All you need to do is a little restructure of your code, and then you can make that check with any variable:

Code: [Select]

_myobject = _this select 0;
_mypropertystring = _this select 1;
_myvalue = _this select 2;
_varname = "FRG_properties";
if ((count _this) > 3) then {_varname = _this select 3;};

if (format["%1",call _varname] == "scalar bool array string 0xfcffffef") then
   {
   call format[{%1 = [];}, _varname];
   }; comment {Create the array once};
...Note that I changed the script from using a hard-coded variable name, to instead use a string-representation of a variable name. Then I just made it so that if the user doesn't pass a name to the function, it uses the default variable.

From there onto the rest of the function, you would need to change all occurances of "properties" into some type of call or format combination. In general:

To read the value of a variable (given a string with the var name), you just "call" it:

  _value = call _varname

To set the value of a variable, you need to format a codestring and then call it:

  call format[{%1 = _value}, _varname]
  call format[{%1 set[0,_value]}, _varname]

and so on.

[Fragorl]

Of course, I forgot the one fundamental thing. Arrays are returned by reference not by value, in ofp as elsewhere. I was worrying that (_myArray = _this select 3) would make a copy of _myArray, but of course it wouldn't. It just makes a new pointer to the original, and any modifications you make will affect the overall array

So that whole worry of initialising the variable before changing it with a call format was unfounded. So, I will update the function as you suggest, probably in the next couple of days

[General Barron]

Hmm... I forgot about that one as well. So I suppose there would be no need for call/formatting then?

The user would still be required to initialize the variable on his own though...