Varanon

No, I'm currently converting the ACR infantry. I don't see a reason to remake them since they are quite good already, being a later DLC. Same applies to the vehicles

Yes

New civilian units: Firefighter and Mechanic

Well, it's a bug tracker, it tracks bugs with CUP. It's not meant as a help desk for problems with using the assets, only for reporting problems with the assets themselves. For anything else, there's the forum or out Discord chat.

I've not been able to find firm information about the coordinate system used in the AFM XML files. I'Ve read in a comment of one Chopper that the position of the main rotor disc would be the reference point. Elsewhere, it said "center of mass". On the BIKI, it says "relative to the vehicle body coordinate system". Not only are all three mutually exclusive, none of them makes any sense given the observations in relation to the Ground contacts. So the question is, what IS actually the coodinate system used ? "Body coordinate system" doesn't make any sense, if you go by the bounding box, the wheels/skids are almost always the lower end of the bounding box, so they should be zero if the bounding box is the reference frame. Unless of course if the zero point is in the center of the bounding box, but that is difficult to measure... So, honestly, where IS the coordinate system's origin ?

Huh ? What the hell ? Would you kindly READ what I wrote before accusing me of something like that ? To quote myself: "Coordinates are relative to a point given by rtd_center, and all coordinates are relative to that The coordinate system is reversed (x and y have to change sign) and the actual ground contacts for gears are the coordinates of the wheel's center relative to the rtd_center, offset by the suspension length, taking the wheel radius into account." How is that "keep it secret" ? Uhm, re-reading that, the first sentence should probably just read "Coordinates are relative to a point given by rtd_center."

Yeah, you said it last time, I misunderstood. In any case, what you say is irrelevant in this case because as I said before, the origin is NOT the bounding boxes origin, nor is there any correlation between the model coordinates and the XML coordinates Coordinates are relative to a point given by rtd_center, and all coordinates are relative to that The coordinate system is reversed (x and y have to change sign) and the actual ground contacts for gears are the coordinates of the wheel's center relative to the rtd_center, offset by the suspension length, taking the wheel radius into account. But there, you touch the very matter of the subject. "Let's say it is at X"... That is EXACTLY the question I was asking... where IS X ? I know how coordinate systems work, but any coordinate system is defined by it's origin, and "let's say" doesn't work if the engine somehow gives you an origin that you don't know. You are basically answering the question with the question itself. In any case, I've found out how it work, no need to discuss it further.

Because modelToWorld generates world coordinates. How should that be an origin for the bounding box ? In the meantime, I know that all coordinates are relative to a point that is given be the rtd_center in class RotorLibHelicopterProperties, referencing a memory point. Moving that memory point up and down moves the land contacts as well. Now, I just need to find out what the actual scale is, because it's not simply in "meters" Edit: Suspension length also seems to be a factor

No, modelToWorld would convert to world coordinates, that wouldn't make sense.

In case you don't know where the RPT file is: Open an Explorer window, enter %APPDATA% in the address filed, then go up one directory and go to Local\Arma 3 from there. You'll find a bunch of files there ending in .rpt Run Arma once, and then send us the newest RPT file via pastebin and posting the link here Thank you

No, readable Look, in essence, I can understand your complaint, but as soon as you start with the insulting and the "WTF's" anyone's understanding ends.

Good to hear it works now. We've also just finished the first prototypr for FHQ Task Tracker Eden expansion, with in-game task and briefing editor, plus support for the new upcoming task overhaul. Should be out soon

Answering my own questjon: yes, this is how it works. I was a bit confused when no appropriate task icons showed up, just to learn that they currently am look the same except the letters

So, there is a new setSimpleTaskType script command. Does it work as I think it does, so _task setSimpleTaskType _type ? With _type being a CfgTaskType ?

Just a wild guess: Do you binarize the mission when saving from Eden ? I guess that it would not work to have a binarized mission when packing up the campaign

I understand that the "expression" fields of Eden attributes for mission and objects are executed during mission start. What would be good to know is where they fit into the initialization order. Are preinit functions guaranteed to execute first ?

Great, thanks

You might want to try to move this code: // Wait until player is initialized if (!isDedicated) then {waitUntil {!isNull player && isPlayer player};}; in init.sqf up a bit, so it executes before fhqtt.sqf and briefing.sqf, basically like so: // JIP Check (This code should be placed first line of init.sqf file) if (!isServer && isNull player) then {isJIP=true;} else {isJIP=false;}; // Wait until player is initialized if (!isDedicated) then {waitUntil {!isNull player && isPlayer player};}; call compile preProcessFileLineNumbers "fhqtt.sqf"; call compile preProcessFileLineNumbers "briefing.sqf";

My problem here is that I want to switch my own FHQ task tracker to use the BIS functions instead of createSimpleTask to make sure I can take advantage of future development in that area. So I need to "fix" the problem somehow.

I'll give it a shot

How does your briefing.sqf look like ?

And just verified: ["taskTest", true, ["Test task", "Task Test", "Test"], getPos truck, "created", 0, true, true, "attack", true] call BIS_fnc_setTask; works with a JIP'ing client (of course, the task is no longer tied to the object).

No, I didn't. The function is supposed to distribute it's state by itself. The task is created on the JIP'ing host, but it simply receives the wrong position

Replying to myself: Here's the way the task is created: ["taskTest", true, ["Test task", "Task Test", "Test"], truck, "created", 0, true, true, "attack", true] call BIS_fnc_setTask; The task target, "truck", is an Eden-placed truck called, well, "truck". As said above, it will correctly work for any client connected at the time of issuing the command. When a client connects, it generates the following error: 19:12:29 Error in expression <letaskdestination _task;}} else {{_task setsimpletasktarget _destination;}};}e> 19:12:29 Error position: <setsimpletasktarget _destination;}};}e> 19:12:29 Error setsimpletasktarget: Type Object, expected Array 19:12:29 File A3\functions_f\Tasks\fn_setTaskLocal.sqf, line 205 .. Obviously, setSimpleTaskTarget requires an array [object, precise], while the script only gives a single object. This might be related to fn_setTask: private["_dest","_destTarget"]; _dest = _this param [3,GET_DATA(_taskVar,DESTINATION),[objnull,[]]]; _destTarget = _dest param [0,objnull,[objnull,0]]; if (typename _destTarget == typename objnull) then { _dest = [ _destTarget, _dest param [1,false,[false]] ] } else { if (typeName _destTarget == typeName objNull) then { _dest = [ _destTarget, _dest param [1,false,[false]] ] } else { _dest = [ _destTarget, _dest param [1,0,[0]], _dest param [2,0,[0]] ] }; }; SET_DATA(_taskVar,DESTINATION,_dest); Check the first if statement: If this is true, then the following code is execute. If false, it will go to the else branch, which start with the exact same condition again. If it wasn't true in the first place, it won't be true here either.

setCaptive basically makes units change side to civilian. So if you add a briefing/tasks to, say, west, and you units are setCaptive true; they will not receive the briefing/tasks. However, if it works on hosted, then you are most likely doing one of two things wrong: 1) You use the script command "player". NEVER EVER use that if you want your mission to work in MP. Not only is it a different value on each client, it is not even defined on a dedicated server. 2) You are using the task tracker on a client. Note that the functions like "AddBriefing" MUST be executed on the server only.