-NoMa-Bansku

Compiling a string wont help here, i'm afraid. As you can imagine, getPos %1 would get replaced by unit object _as_string_. In such case, there is no way to "getPos" from "99499600# 1770844: apc_wheeled_02_rcws_f.p3d": Error in expression <awIcon3D ['', [1,0,0,1], getPos 99499600# 1770844: apc_wheeled_02_rcws_f.p3d, 0,> Error position: <# 1770844: apc_wheeled_02_rcws_f.p3d, 0,> Error Missing ] Any other object type would cause the same problem. Only way to do that is to feed in position array and relocate getPos outside of the string. Only downside of that would be that position coordinates would always be the same ;). In other words, we are back to square 1 => don't compile and keep on polluting global variables space :mad: ---------- Post added at 09:48 ---------- Previous post was at 09:09 ---------- Oh well, there is one "cheat" you can try out. As long as you are playing ONLY with strings, everything is just fine. With that in mind, for objects there are netid and objectfromnetid functions available to be abused: call compile format ["_myfancyid = addMissionEventHandler ['Draw3D', {drawIcon3D ['pic_of_my_convertible.paa', [1,1,1,1], getPos (objectFromNetId '%1'), 1, 1, 0, 'dont drive me on a rainy day', 1, 0.03, 'PuristaMedium'];}];", netId _unit]; Of course there is performance impact but at least this way you can minimize variable scope as much as possible. You decide which one is better.

Like always with paths and files not found even if they should, last resort is to use pseudo absolute paths. Example: \mpmissions\<yourmissionname>.<island>\<here>\<starts>\<your>\<own>\<path>\<kewl_pic>.paa Drawback is the same as in everything else so this only works for mp mission, for sp mission path is different...

i would call that a nasty hack. what would happen if the same pbo is run in linux? i wonder why relative paths are not working in this case. furthermore, preprocessor can not tweak string in include. hmmm. like always, bistudio wiki documentation is a little bit of a joke: https://community.bistudio.com/wiki/PreProcessor_Commands. There is a link in the bottom pointing to external pdf. That pdf is wrong in stating that relative include paths would work. In two words, they wont.

Well, this is only one of the minor problems in the whole equipement management in A3. For scripters like us, there is no other way but first add a clip to some container (uniform,vest,backpack) and then add weapon. First clip will be inserted into the weapon "magically". If in your case you have soldier already full of equipement, there simply will be no free space even for a small clip anymore and whole procedure fails. In such case, you just need to temporarily remove something to make room and then do the procedure again. If you also have the weapon, that needs to be removed, too. Otherwise there wouldn't be a clip before weapon. What i have seen in A3's built in gear menu (yeah read through a lot of code in pbo's), there might be something written in the engine for gear management but is not (yet) exposed to the scripters.

Nothing in the server log? In my experience with dedicated linux server, loading of any mission is just taking veeeery long time. In other words, everything the server tries to do, just takes time. Normally my mission in working environment takes around 30 seconds to fully load. In A3 linux server, the same mission takes around 10 minutes to load...

My linux box is having serious issues with dedicated server tps performance. Where as A2 was having around 40-50 tps, A3 is only between 4-6. By taking strace from the running process, it seems to do awfully lot of gettimeofday system calls. As far as i recall from A2 days, there was some date/time resolving long time ago, too. Maybe this poor performance is related to similar thing, or not. To do some sanity checking, i tried a couple different mp missions, some A3 built in and then my own cti mission. There was no significant difference there, at least performance wise. Some other errors were there but that is not part of this feedback thread. Here is small part of the strace (perhaps 90% of all noise was this time fetching): gettimeofday({1387625266, 782347}, NULL) = 0 gettimeofday({1387625266, 782414}, NULL) = 0 gettimeofday({1387625266, 782461}, NULL) = 0 . . . . . . . . . My 2cnts.