Nielsen

Aha. That was exactly it. It returned C 1-1-A 1 as the unit name, but I did'nt realize that the trigger would'nt accept that as legal input. Should have given more information about my problem - well spotted. Thanks for the help!

Nice work man! This will come in so handy. Thanks

I'm currently facing this problem. The issue seems to be caused by the Ambient Combat Module. When I place the module there is no problem, but the second I sync the module with the player then independents consider OPFOR enemy (though I have set independents friendly to OPFOR). The ACM is named BIS_ACM, and I am not using any custom settings on it. Other modules in the mission include ALICE, Ambient Animals, UAV and the first aid modules. Mission is on Takistan. Any ideas on what I am missing, or if this is a bug? Regards,

Hi all. For longer than I care to rememeber, I have tried to make my missions JIP compatible - but to no avail. I've read all I could find about this and it is starting to drive me crazy. I have done a 2 trigger solution: -1trigger: Con: this Act: objdone = true; PublicVariable "objdone"; -2trigger Con: Objdone Act: tskObj1 settaskstate "SUCCEEDED"; This failed to update when I had a player connect and multiple tasks where both created and completed with PV on JIP. I figured that Variable/trigger that completed the task might "fire" before the Variable creating it. I then removed the PublicVariables in the triggers, and set a - Init.sqf: onPlayerConnected "nul=[] execVM 'testJIP.sqf'"; testJIP.sqf: obj1created = true; sleep 1; PubliVariable "obj1created"; sleep 1; obj1done = true; sleep 1; "PublicVariable "obj1done"; sleep 1; obj2created = true; sleep 1; PublicVariable "obj2created"; sleep 1; //And so on. I inluded the sleep, as I read on a forum, that it might cause problems when a client recieves more than 1 publicvariable at a time (pr. frame). This solution seems to be much more consistent, but it still fails to update all (8) tasks to completed. 1 or 2 are allways only created when a player connects. In addition this does'nt solve the problem when another JIP happens, and the variables are allready public trough onplayerconnected. Then nothing really works. Then I read about the Multiplayer Framework in the functions module and thought I have tried it, but can not get it to work either. I add a functions module to my mission. In init.sqf I add: waituntil {!isnil "bis_fnc_init"}; waituntil {!isnil "BIS_MPF_InitDone"}; as I have seen suggested on the forums. The I use the code [nil,TskObj1,"per",rSettaskState,"Succeeded"] call RE; to update the tasks, but it does not work. I get and Error. I says that BIS_missionScope is nil. I have tried to include a: waituntil {!isnil "BIS_missionScope"}; In the init.sqf, but that does not work. I read on the forum that the MP Framework had to be initialized, and that could be done with: if (isnil "RE") then {[] execVM "\ca\Modules\MP\data\scripts\MPframework.sqf"}; That does not seem to work either.. I have also tried the TaskMaster script by 'Shk', but that wont work for me either. When I open the demomissions and have a buddy JIP the tasks wont update correctly. Would someone be so kind to explain to me how I get the Multiplayer Framework to work, or how to make my tasks update properly for JIP. I would be forever gratefull. Thanks in advance. Kind regards, R. Nielsen

Yeah I see I got the path of the upsmon.sqf wrong. I've changed it in my previous posts. Glad you got that working.

No problem. The (isServer) is for MP, but wont be a problem for SP. It just makes the script MP compatible (at least for a hosted environment). Btw. Remember you can change the runUPSmon.sqf to fit your needs regarding the upsmon settings. So the runUPSmon.sqf could look like this: if !(isServer) exitWith {}; private ["_npc","_location"]; _npc = _this select 0; _location = this select 1; _npc setVehicleInit "nul=[this,_location,[color="Red"]"Combat","Random","noFollow"[/color]] execVM ""scripts\upsmon.sqf"";"; processInitCommands; Again. Look at the UPSmon.sqf in the scripts folder of the UPSMON files.

Allright... First the use of UPSMON The UPSMON you use by downloading it, and putting the 'scripts' folder into your mission folder (where the mission.sqm is). Then you need a file called 'init.sqf' in that same root folder of the mission. If your not familiar with this, you can just make a text file in wordpad/notepad etc. and save it as init.sqf. In init.sqf you include: if (isServer) then { //Init UPSMON scritp call compile preprocessFileLineNumbers "scripts\Init_UPSMON.sqf"; }; Now, in the editor you place markers over the cities, and name them something clever eg. UPS_Town_1, UPS_Town_2, etc. If you just wanted the enemy to be in a specific city, you would just place an enemy group, and in the leaders init line you could put: nul=[this,"UPS_Town_1"] execVM "scripts\upsmon.sqf"; Where UPS_Town_1 is obviously the name of the marker where the group should patrol... Also you can put in various additional parameters in the init line. The parameters and examples are listed in the UPSMON.sqf in the scripts folder. UPSMON with random placed units Okay but on with the random placement of the units. Here comes the key element to what you are trying to accomplish. If you place the units with markers, then you have to know which marker they are under, and can not set the leaders init line beforehand. That could be a problem. There a propably a lot of ways to solve this, but here is one approach. Leave the group leaders init blank, but name him fx UPSunit1. Then set a trigger equivalent to each UPSmon marker (UPS_Town_1,2 etc.). Set the triggers to Opfor -> Present, and in the the condition field put: this AND (UPSunit1 in thislist); . In the activation field put: nul = [uPSunit1,"UPS_Town_X"] execVM "runUPSmon.sqf"; Where "UPS_Town_X" is the name of the corresponding UPSmon marker. (nb. The markername has to be in a string i.e. ""). Now make a file called runUPSmon.sqf in the (root) mission folder. runUPSmon.sqf if !(isServer) exitWith {}; private ["_npc","_location"]; _npc = _this select 0; _location = this select 1; _npc setVehicleInit "nul=[this,_location] execVM ""scripts\upsmon.sqf"";"; processInitCommands; And that should be it. When the unit spawns it triggers the trigger in that area. The trigger in turn executes the script, that sets the right initline for the area and processes it. I have not tested this, and I am certainly not a scripting guru, but I feel confident that it will work.:cool: Let me know if you test it out. PS: Just to be on the safe side, I should propably point out, that the markers for the random spawn of course has to be in the different UPSmon areas, or rather in the area of the corresponding triggers. If the units do not spawn in the triggerareas they wont execute the script, and nothing happens :rolleyes: Cheers,

Also, have you thought of using markers? In case you dont know, if you group a unit (groupleader) to one or more markers, then he and his group will either spawn at the original location or at the position of one of the markers he is grouped with (random chance). That way you can make a number of enemy groups. Put an empty marker on each town, and group the teamleaders to the markers. Then you have no idea in which town they ended up. You can still play with the propability so that you also dont know how many enemies there will be. Just a thought, that does not involve running a specifik mod or script. EDIT: BTW, it can be troublesome to group markers to units, as the markers are not visible in the group menu (F2). To make it easier, start by placing the markers close to the units. Hit (F6) and mouse over a marker, then hit (F2) and drag/group to the unit. Repeat with a new marker. When all markers are grouped, hit (F6) and move them to the towns, or whereever you want them. I'm just saying this so you dont set it all up first, and struggle with the grouping afterwards :)

@A-SUICIDAL: It's because your not replacing the 'groupName' with the groupname you have set on the leader. Also you have a scripterror as you point you, and on top of that you have wrongly replaced an essential part of the forEach command '_x'. ;) The forEach command just runs the same code, on each of the given units. In this case on each unit in group_b. The '_x' automatically gets replaced with the correct name of the unit in each cycle of the code. With the init: group_b = group this; the code should look like this: { _x setskill ["aimingAccuracy",0.15]; _x setskill ["spotDistance",0.85]; _x setskill ["spotTime",0.85]; _x setskill ["courage",0.85]; _x setskill ["commanding",0.85]; _x setskill ["aimingShake",0.15]; _x setskill ["aimingSpeed",0.65]; } foreach units [color="Red"]group_b[/color]; That being said. If you want to apply this to every enemy, then you should just use the example that Shk posted. That does exactly that. With this example you would indeed have to set every groups skills. The example is only of use if you want different groups to have different skills.

@fideco: { _x setskill ["aimingAccuracy",0.15]; _x setskill ["spotDistance",0.85]; _x setskill ["spotTime",0.85]; _x setskill ["courage",0.85]; _x setskill ["commanding",0.85]; _x setskill ["aimingShake",0.15]; _x setskill ["aimingSpeed",0.65]; } foreach units [color="Red"]groupName[/color]; Just change 'groupName' to the name of the group you want to execute the script on. This groupName can be specified by putting [color="Red"]GroupName[/color] = group this; in the init line of a group leader. EDIT: The things in red have to match ;)

This is a great idea. It is nice not having to create DOC's just to move objects relative to each other. Thanks man!

Great.. Been waiting for this. Thanks a bunch!

@Bootsy: Searching is an artform. And I would say, that if you did not find at least one related thread, then you should propably reconsider your search parameters. That being said, I often have trouble finding threads that I know must be there. One important thing is to make use of the advanced search, and only search in the appropriate forum. @Kylania: I do think that B00tsy has got a point about the editor. In general I guess this discussion is not as much whether the editor is in fact easy-to-use, but more about what you understand by 'easy-to-use'. I would say that the editor gives me more possibilities to make missions without the use of scripting, than I have experienced before. In that regard it is certainly easy-to-use. Then again, I can understand why (some) people assume, that an "extremely easy-to-use editor" means that you can make aesthetic and professional-looking missions, without knowing how to code. In some respect I feel that is somehow a justified assumption. At the very least I would concur with B00tsy, that it would seem pretty standard "to have working tasks and objectives". I think BIS would go a long way in improving (at least peoples perception of) the editor if they added a simple briefing/objective wizard. In the end I dont really care. I love to look at this game as edutainment. I love opening up an old mission, realizing that I did not know what the hell I was doing - feeling like the newborn 1337 haxxor as I proceed to mock my old code like:" Did I really write this piece of sh!t garbage script", and then rewrite it to my full satisfaction. In the end I guess it all comes down to what you expect to get out of this (or any) game. When I do not know how to do something in the editor, I take it as a challenge not a source of irritation. If all you want from this game is solid entertainment, then I can understand why coding n00bs like myself are discouraged by the level of involvment it takes to make a nice looking mission. If you expect (like the boxcover promises) to be able to spit out good missions in 5min intervals, then you might be surprised about the amount of time you have to spent browsing forums for an answer on what might be percieved as basic questions. Personally I kinda like it that way, but that does not make me close my eyes to the legitimacy of the claim... - not saying that you do. I have just seen this discussion a few times allready, and seen a lot of opinionated claims about how easy- or not easy-to-use the editor in fact is, without anyone taking note of the discursive nature of the subject. ...omg, that turned into a rant. :o this disablePlayer "RANT"; Regards, EDIT: Sorry for going that far off topic, but I feel that the original question has been answered in full by ruebe and the link from kylania.

This is such great news! Cant wait to check it out...

Good idea MuzzleFlash. @Filip5: You can put that pretty much anywhere. In the unit init-line, or in a init.sqf. Just make sure you replace 'soldier' with the unit name.

If you dont know how to name your unit, you should propably read some editing tutorials. else its gonna be uphill all the way. I also suggest you take a look at the FAQ pages here and here. There is some very usefull info on those pages. To answer your question. Just check the classname of the backpack you want on his back here. Then use the command that W0lle showed you to equip the pack. Examples are shown on the wiki page. In the init line of the unit just write: this addBackpack "backpackname". E.g.: this addBackpack "US_Patrol_Pack_EP1"; The relevant unit will now have such a backpack on his back. Hope that solves it for you.

Have you tried giving them the throw weapon.? They need to have a weapon to throw rocks. If you dont want them to have firearms, then do a 'this addWeapon "throw";' in addition to the stones. Also, the AI have to be at a certain distance to start throwing rocks. If they are too close they wont throw a thing.

Thanks for the reply.. Yeah, guess I'll have to suck it up then :)

Thats the question. I have this in my description.ext: class CfgRadio { sounds[] = {Sound1}; class Sound1 { name = "Sound1"; sound[] = {\sound\sound1.ogg, db-200, 1.0}; title = ""; }; }; I execute it with: player1 sideRadio "Sound1"; When I change the db setting, nothing changes in-game. 'db-10' or 'db+500' makes no difference at all. The sound is playing fine, and the pitch nuber reacts. So if I do '{\sound\sound1.ogg, db-200, 0.8};' the pitch is lowered. The volume setting will however not respond. Any thoughts on why this is? Would be a pain to have to turn down all the files in Audition or something. Regards,

Plain awesome! Thats about all I have to say at this point.. *tries to get comfortable on the edge of his seat*

Looking forward to it! :)

No i had not deactivated the timer after placing the satchel. I set the timer to 30sec. I place the satchel and wait 30secs. Nothing happens. Everything else seems to work perfectly. Regarding the detonation. I have looked into it since I posted before. I cant find numbers on the actual detonation-range of US satchel charges. However, I have found several ways of remote detonation the seem reasonable. My best bet on a realistic approach is this 'Remote Detonation System - 6708' (RDS6708). I highly doubt that the military would use something with lesser range than a walkie talkie, when those puppies are available :). To sum up a few features: I'm not claiming that american troops are currently using this exact device. I just think that it is a pretty good indication of what is realistic.

Allright. Done some more testing. The missing possibility of disarming the satchel do seem to be a little less frequent in MP. Not much though. When we tested it, only once had I the possibility of picking up my satchel again. When I put it again, I could not. My buddy could not remove any satchels. Some other thoughts: How does the timer work? I set the timer to 30sec and place a satchel. I wait 30sec and nothing happens. Then I hit the detonator to see if that will start the countdown, but once I hit detonate it detonates right away. What gives? :) Instead of showing the total number of satchels placed in the 'current channel' action, it would be awesome if it only displayed the number of satchels placed in that channel. Would be much more usefull info imo. Still loving the addon :ok: EDIT: Cool. But keep in mind which kind of radio you are using. I dont know what kind of radio you have, I'm just saying that a standard Motorola walkie have significantly less range than military grade UHF/VHF radios. My 'Yaesu VX-6E' has (in my experience) an effective range of at least 1km in a dense urban environment. When in an open environment with no buildings blocking reception the range extends beyond my testing capabilities. But I'd say 5-10km, easy.

Hehe, indeed. I usually play small hosted coops, and we use alot of satchels :). No need for a full fletched demo-mission for this addon to be the bomb (pun intended ). I feel that everytime I have placed a vanilla satchel I have been slightly annoyed with the limited possibilities. This will make me preplan my detonation sequences in detail - even when there is absolutely no need for it :D. Hmm. I only had time to test it in SP. I will take a look at this, when my buddy is online and we've got the time. Well, like I said. All I know about dialogs is that I LOVE them. I've never been a big fan of the action menu. I mean its neat, and I use it a lot in my missions, but only because I dont know any other way. Problems is, that I feel its clumsy to control, and not fit for lots of actions. In addition I got an itchy triggerfinger, and on more than a few occasions I have been known to unintentionally squeeze off a round while trying to select stuff in the menu :o. Dialogs would not have the problem of cluttering up your action menu. Besides dialogs just feels and looks so nice imho. Yeah I know. All the things i suggested was just extensions of things that can allready be accomplished with your addon. What I meant was, it would be neat if I could place satchels on channel 4, while keeping my finger on the detonator for channel 8. Yeah, thats exactly what I was thinking. Again, dialogs would make this possible. Hehe, good point. It was just a wild thought. I was still in the dialogs mindset, and thought that it would be so 1337 to have a sequence-pre-planner feature or something, so you could plan out and configure the satchels before going into hostile territory. Not that needed, it could just be fun. I'm the one saying thanks. It's awesome that you have made this. I see a lot of mods being made, but very few of them leave me with a "FINALLY! I've been waiting for this." feeling. Glad to hear you'll stay with it. I guess we are all happy then ;) Haha. On that note. It could be awesome with a safety on the detonator! With dialogs this could look awesome, but it could also work with the action menu. If you changed the 'detonate' option to 'Safety off detonator' or something, and that would open the possibility of pushing 'the button'.. Cause yeah. As it is, there is a real possibility of going for your rifle, or talking to a civilian, and instead inadvertently setting off the whole of Bravo teams channel-1's :eek:... One last thing. I've allways hated that you had to be very close to the satchels to detonate them. I would like that this was not the case with this addon. I do not know how realistic this is, but I find it hard to believe that the restriction of 200(?) meters is very realistic. Surely the military is using satelite technology. And even if satchels are irl somehow restricted to standard 2way radiowave detonators, then 200m seems very restrictive. I know my Yaesu Radio can send and recieve at 10 times that range (at least). Is it something you would look into?. Looking forward to any improvements! EDIT: Btw, I did not know that vanilla satchels gives up your position. If that is the case, and this addon does not, then it just got a severe utility-boost. Nice!

This is awesome! Been hoping for something like this for so long. Thanks man. Been testing it out a little bit, and I really like it. Works really nice. Cant wait to set up some serious demo missions. Gonna be so sweet :cool: For some feedback and (hopefully constructive) critisism. Like you said I did not seem to be able to deactive/remove the satchels once placed. I know - known issue. Just saying I had the problem also, and it would obviously be nice if you were able to fix it. If not, then I can def. live with it. One thing that would be SO nice, was if you could make it dialog based instead of doing it all through the action menu. I dont know anything about dialogs, so I have no idea how hard this would be to implement. I'm just saying that it would be way easier to set things, and it seems you would have alot more room for implementing additional features without making the whole thing too confusing, and cluttering up the action too much. Just a thought, but certainly something that would make sure I would never run arma without it ;) Something on the wishlist: - Possibility of having seperate channel selection for detonator and placed satchels. - More extensive possibilities when selecting time/fuse intervals. - Possibility of "pre-setting" a sequence of satchels, instead of just the next one. I guess they would propably all be to confusing to use in the action menu, so I guess I'm still rooting for the dialog thing. Anyways. Great addon Neo, I will be using this all the time! I hope you stay with it. Regards. EDIT: Btw, I forgot to mention, that the fuse option is a really cool feature