Brockie

Had this problem with Windows 7. I wrongly believed I already had all the Direct X dependencies. As OP said you can check by looking in the Windows\System32 and Windows\SYSWOW64 folders for this file XAPOFX1_5.dll. However the proper way to fix this issue would be to visit: https://www.microsoft.com/download/details.aspx?id=35 The official Microsoft Direct X download.

Looking forward to testing this

Sounds like a filter issue to me. In arma 2, by default, you will only see servers with a max ping of 100. If your friends have higher than 100 ping that would explain why they can't see your server. Tell them to check their filter.

Hey @theduke, I don't have the gem mod but I do have extra right click actions, so I used that to play with building a flag and I was right,about player_build.sqf. server_monitor.sqf will take care of texturing your flags each time you restart the server, and player_build.sqf will take care of immediately texturing objects as they are being built. You don't need to edit any of the "publishVehicles" files and you shouldn't need the skins.sqf file either. so here is what I would do for player_build.sqf: (I've added only one line here, but showing the whole block so you can see where to put it.) // Start Build _tmpbuilt = createVehicle [_classname, _location, [], 0, "CAN_COLLIDE"]; _tmpbuilt setdir _dir; // Get position based on object _location = _position; if (_classname == "FlagCarrierWhite_EP1") then {_tmpbuilt setVehicleInit 'this setFlagTexture ''\ca\ca_e\data\flag_us_co.paa'';';}; // I added this line if((_isAllowedUnderGround == 0) && ((_location select 2) < 0)) then { _location set [2,0]; }; and you need to add processInitCommands; near the end. This shows where I would put it: }; processInitCommands; // I added this line } else { //if magazine was not removed, cancel publish Once you've done this people will probably get kicked for BattlEye remoteexec restrictions when they build the flag. Here's what you will want to add to your remoteexec.txt: !"setFlagTexture" like this: //new 5 "" !"setFlagTexture" (more script here that I'm not showing)

Indeed my edits will only handle server restart, buying a vehicle, stuff that's already in epoch (building a flag should work too) but server_monitor.sqf is just for restarts. Now that I think of it... the file for changing textures of building is player_build.sqf. Admin tools is not part of epoch and those mods don't use epoch files for creating stuff, exact same goes for AI missions. These mods use custom code for creating vehicles which is why the textures don't get applied immediately (but would take effect after a restart if the objects were persistant). Did your skins.sqf solve the issue to texture admin spawned vehicles? If not then it is redundant having that file. What I would do is edit the actual admin tools that when it createVehicle it also setObjectTexture. Same could be done with AI missions, by editing the missions code.

Hey @theduke, I've got it working. but before I reveal the code for re-texturing flags I just want to ask about your " mission sided file... "skins.sqf... in the init.sqf ". This should not be necessary from what I can tell. Unless I am mistaken re-texturing should work for all clients, including ones that join later. Is that from another texture script? what is the purpose of that file? anyway here it is for your sever_monitor.sqf: This will re-texture the flag for you on server startup but I don't have emerald designer or whatever gem mod you are using so I can't test building a flag dynamically. But If you find that it's not working dynamically then I would recommend adding the line also to server_publishVehicle3.sqf (i think this is for dynamic object creating) or actually maybe server_publishObject2.sqf (I'm not sure) and just remember in those files you must change _type to _class.

I just found a typo in player_unlockVault.sqf line 34 has two semi-colons _ownerID = _obj getVariable["ownerPUID","0"];;

Hey @theduke, that's an interesting question. I didn't know about the setFlagtexture command. Firstly a bit of a typo in your code: setFalgTexture should be setFlagTexture. Now, looking at the difference in syntax on the bohemia wiki first thing I notice is a difference in syntax between setObjectTexture and setFlagtexture. syntax for setObjectTexture: object setObjectTexture [selectionNumber,texture] syntax for setFlagTexture: flag setFlagTexture texture Indeed it seems there is no 'selection number' when it come to flags. This means you shouldn't need brackets around the path to the texture file. Try this: if (_class == "FlagCarrierWhite_EP1") then { _object setVehicleInit "this setFlagTexture ''graphics\flag.jpg''" }; This line of code might have syntax errors but it looks good to me right now. Next, when trying to decide between _class or _type it comes down to how the stock files were written. Use the variable that is being called for creating the vehicle. Examples: Server_Monitor.sqf: createVehicle [_type, _pos, [], 0, "CAN_COLLIDE"]; server_publishVehicle2.sqf, server_publishVehicle3.sqf createVehicle [_class, [0,0,0], [], 0, "CAN_COLLIDE"]; It's just how it was written by the devs for whatever reason. Next I'm going to share some of my novice understanding of the code. Emphasis on being 'novice'. if (_class == "FlagCarrierWhite_EP1") then { _object setVehicleInit "this setFlagTexture ''graphics\flag.jpg''" }; So in this line of code, I believe (though I could be totally wrong) _class only represents which type of object we are looking for. If you have 10 of the same type of flag on the map it's looking at all of them. Where _object I believe has a number associated with it to identify exactly which of those 10 flags is being updated each time. The last thing I can think of right now is the difference between server_publishVehicle.sqf, server_publishVehicle2.sqf, server_publishVehicle3.sqf, and server_monitor.sqf. It is important to understand which file does what. I wish I could explain this right now but I'm way too rusty. server_monitor.sqf seems to be the likely candidate that deals with server startup so I would start there. Make sure the flag is called from the database and not from editor.sqf that way the server_monitor.sqf should deal with it (I think). if that doesn't work I next I would try publishVehicle3, and last I would try publishVehicle2. I'm going to give this a try in my game and see if I can get it to work and I will report back. Thanks for the question.

Hey everyone. Ok, firstly... sorry I have been away for ages... beyond that the problem was pretty clear by your RPT: problem was you copied the wrong line of code into server_monitor.sqf. Step 4 said _type not _class. I also made a note in step 6 because I knew some people wouldn't get it right. Sorry you had problems getting this to work but you just needed to read the instructions better. After I was away for nearly 2 years and now being very rusty at this, I was still able to follow my own instructions and I'm happy to say it still works the same in 1.0.5.1 that it did in 1.0.4.2. If anyone has difficulty with this feel free to message me and I'll try to help.

I had the same problem. The bug is in player_build_states.sqf. The script is checking the variable _isFine and expecting Boolean (true or false) but it's returning "Strings". @RimBlock - The way I saw the true error was to wrap the the "[] call player_build_states;" with a waitUntil control structure. This brought out the proper error in my RPT as to _isFine should be boolean and not strings. Please double check because I am admitedly using a modified version of P4L but I'm fairly certain this is a bug in your release. Correct me if I'm wrong. To fix it open player_build_states.sqf and change the _isFine variables to Boolean like this: Also, however, while debugging this I also found some other nasty, and related, bugs... If you pass the player_build_states.sqf (ie. you aren't swimming or in a vehicle or on a ladder) it gives you the ghost preview of the object you are about to build. The problem is that once you have the ghost preview, you can mount a vehicle (or go swimming, or climb on a ladder) and the build doesn't get interupted. It will infact try to build the object and although it wont actually publish the object (it sort of gets frozen during the build) this is a problem if your server supports static weapons (like mine does) because it will not stop you from mounting an unpublished weapon (or vehicle). So for me this is not good. So I'm sure there's a better way to fix this but my solution so far is to modify the player_build_publish.sqf to essentially recheck the player's "state". Like so: (don't forget to ADD the extra variables to the private ["..."] (variables array). If anyone knows a better way to interupt the build when the player goes swimming, gets on a ladder, or jumps in a vehicle, please let me know! Lastly.. OP please try to condense this mod back into player_build.sqf because this is a bit of a mess as many have already commented. Also as an opinion I think safes, lockboxes, combos etc should not have been changed.. please change it back to normal or give people the option to keep it normal. Nonetheless great work. Keep it up =)

@Link use unused variations for example maybe try SUV_TK_EP1_DZE1 or DZE2 or DZE3 or DZE4 etc.

U can disable the auto polling on startup in the options. Also I find DayZ Launcher's need to rename all the folders is causing a lot of problems, but otherwise I'm all for extra launchers.. even tho I don't really use them very often anymore

heres ur typo ["LadaLM","],

It works for 1.0.5.1 but I had a case of a safe losing all of it's contents so I took out the safe combo changing on my server.

I would say it is probably a typo in your dynamic_vehicles.sqf was it recently edited?