Jump to content

Dj Rolnik

Member
  • Content Count

    92
  • Joined

  • Last visited

  • Medals

Everything posted by Dj Rolnik

  1. Hello, I am looking for a solution to an issue which troubles me greatly - AI going prone on contact. I guess all of us have experienced it before and know that once the AI changes combat mode, it instantly goes to the ground which is not always realistic, nor is it good for the players. I have searched for a solution for some time now and most of the solutions suggested forcing AI to one specific stance, either by Zeus or by setUnitPos. Unfortunately, none of the solutions considered allowing the AI to either STAND or KNEEL, which is what I'm hoping for. Maybe there is a way to add an eventhandler of some sort which could override the PRONE stance with KNEEL, if possible. Otherwise, maybe it could just disable prone itself, leaving kneel and stand for the AI to choose normally. I did find a semi-solution to this, which is using trigger areas and modules, which force the stance change of the AI within a trigger to whatever I set, however that's a) fixed to one stance, and b) always in zones that have been predefined by me, not dynamic in any way. I lack enough experience to write something like this on my own, but I do feel like forbidding AIs PRONE stance only is possible - I just don't know exactly how to do it. Will be grateful for any help! Adam
  2. Hey guys, I am working on a mission which utilizes a script allowing the players to shout to civilians based on distance and angle from the civie. Whenever the civilian is within a given radius and a specific angle from the player, then the latter receives an action allowing him to shout commands etc. The script works fine and all, but I am seeing a problem where the action appears/reappears pretty randomly when the civilians are running/moving OR RATHER when there are obstacles and uneven terrain around. I believe that the BIS_fnc_inAngleSector , which is the condition for the addAction, keeps returning an exact position of the civilian and when he keeps moving, changing altitudes or when there are objects around, the function just loses track and makes the action appear/disappear pretty randomly. I may be wrong on this but that's the only thing that comes to my mind. That's for the context. Now whe actual question I have is: do you think it's possible to feed some kind of modified position array of the civilian, so that it will search "around" his actual position? player nearEntities [ "MAN", _radius ] select { side _x isEqualTo civilian && { [ getPosATL player, getDir player, _angle, getPosATL _x ] call BIS_fnc_inAngleSector } } Thanks a lot! Adam
  3. Dj Rolnik

    Immersion Cigs

    Yeah ok, so removeGoggles does work on the smoked items. removeMagazine works for cigarette packs, lighters etc. However, I cannot seem to find a way to remove individual cigs unpacked from the packet. I thought that a simple removeItems would work, but instead it spewes the below error: Okay, scratch that. player removeItem "murshun_cigs_cig0" actually does work. For some reason the removeItems cmd does not work though. Not a biggie luckily. Thanks @Maff!
  4. Dj Rolnik

    Immersion Cigs

    Hmm, sounds good, I will try that.
  5. Dj Rolnik

    Immersion Cigs

    @Maff, yeah I think you're right. Basically the cigs are put in the goggles slot so at this point the unlinkItem should work, but it does not. I also tried the removal of magazines, but to no avail.
  6. Dj Rolnik

    Immersion Cigs

    Hey guys, I am trying to figure out a way to remove cigs, lighters, matches etc from the player with a script. I found the classnames for the items (and cigs in various stages) and created a simple trigger which ought to removeAllItems upon leaving the trigger area. I did test it with other items that the playe can use but for some reason I cannot get the cigs-items to work. I also tried unlinkItem for equipped items, but it does not seem to work. Do you have any ideas as to how I could do that? Thanks!
  7. Hey, Yes Larrow, you're right. My original attempt now just works in terms of connecting, but I did mess up the part with isUAVDisconnected. Apparently, according to the below thread, there is a command which returns the controller of the UAV, irrespective of whether it's connected, so I was thinking that this could work, but actually at this point your current version is just the way to go. Thanks again Larrow - saving the day once more 🙂 Adam
  8. Hey, I am prepping a mission which will feature stativ UAV terminals for players to use. Their intent is to allow for connecting to jets turret gunners when using an action, and remove the uav terminal when leaving the uav interface. What I got so far is this: initServer.sqf: WaitUntil {!(isNil "turret6")}; //waiting for the spawn of the last turret in sequence [ turret_controller_1, "Control turret 1", "\a3\ui_f\data\IGUI\Cfg\holdactions\holdAction_hack_ca.paa", "\a3\ui_f\data\IGUI\Cfg\holdactions\holdAction_hack_ca.paa", "_this distance _target < 2", "_caller distance _target < 2", {}, {}, {execVM "scripts\turret_control_1.sqf"}, {}, [], 2, 0, false, false ] remoteExec ["BIS_fnc_holdActionAdd", 0, turret_controller_1]; and turret_control_1.sqf: player linkItem "B_UavTerminal"; player connectTerminalToUAV turret1; player action ["SwitchToUAVGunner", getConnectedUAV player]; WaitUntil {!(isUAVConnected turret1)}; player unLinkItem "B_UavTerminal"; The simple script works perfectly in a Singleplayer environment. For some reason it does absolutely nothing when tested in Multiplayer. Basically we enter the map, proceed to the "turret_controller_1" which receives the action and when pressing and holding the spacebar (as instructed by the BIS_fnc_holdActionAdd command), the player is not transferred to the gunner view at all. All it does is add in the terminal for the player. I have been trying to kind of debug this issue and I came to the conclusion that the terminal does not connect to the turret (as shown by the getConnectedUAV command). I have no idea as to why that is, but that's slightly infuriating. I would be thankful for some guidance on this as I've been struggling to get those turrets to work for days now and there's always something new which does not work. I am leaning towards it happening because of some locality issue, but if that's the case, then I am the more in need of help. Thanks a lot, Adam
  9. Okay, so I have a few things to say.. First of all, thank you all for being so helpful! I have already realized that whenever I want to achieve any relatively simple effect in Arma, it always ends up being much more complicated that it initially seemed and I need to cry for help. It's great to know there are people willing to spend their time to help others - many thanks @Maff, @Larrow - that's really much appreciated. Secondly, I should apologize, because in the end all this mess resulted from my mistake. In short: all of those attempts do work on a dedicated server, as I have just confirmed after about a 376th server restart. I should apologize mainly because I assumed that creating the turrets within the initServer.sqf would not be a problem for the script to run, primarily because it worked on SP + local MP and not on a Dedicated - I never thought that this could be the reason but I should have posted it in the original post nonetheless. The initServer.sqf also contains the below bit which creates the turret-uavs from scratch and places them on a Ship. The sole createVehicle process was the part that messed up the connectivity for whatever reason. I actually noticed this after launching Larrow's test mission and comparing the two scenarios. In mine, the turret was placed by the script and in Larrow's it was already in the game. Even after copying Larrow's code directly to my mission it did not work so I started pulling my hair out until I realised what the cause could be. /* MK49 Spartan - Rear-right */ // turret1 = createVehicle ["B_SAM_System_01_F", [1507.26,8856.08,0.2]]; // createVehicleCrew turret1; turret1 attachTo [Ship, [24.8,-155.5,12.6]]; turret1 setDir 90; turret1 setBehaviour "CARELESS"; turret1 setCombatMode "BLUE"; turret1 disableAI "TARGET"; turret1 disableAI "AUTOTARGET"; turret1 setAutonomous false; turret1 setGroupId ["Turret 1"]; With that, I decided to just skip the createVehicle part and simply created a turret somewhere on the map in the editor. When the mission starts, I now only move it to the desired position and then connecting to it via any script works flawlessly in all environments. All scripts, that is Larrow's most elaborate code, Maff's suggestions pertaining to remoteControl and the previous attempts to fixing my code, as well as my original script. The only minor difference is that with remoteControl it seems that you cannot use the radar of the turret (Ctrl + R) and with my original script the line pertaining to the check, whether the terminal is already disconnected, is wrong - I will fix this later but that's not a biggie. Sooo.... yeah. I am so sorry for wasting your time guys. It could have been over much sooner and that's only due to my mistake. I guess live and learn, eh..? Thank you very much for helping again! Adam
  10. Well okay, I gave it a try and it actually looked pretty promising, as the code is shorter and the overall process is much easier. Again, works fine in SP but does literally nothing in MP when called using the aforementioned action. It just hints "done" and nothing happens. Is it still the case of locality? player remoteControl gunner turret1; gunner turret1 switchCamera "Internal"; hint "done"; I am beyond clueless... Help.
  11. Ygh, not yet, but from an initial look it seems like a dirty workaround and I am slightly afraid of going this way 😞
  12. Yes, that is true, but why do you ask? The idea behind the script is that there is a stationary item that works as a kind of "controller" for the turret (uav) and when the action attached to this object fires, the player gets directly into the gunner seat of the turret. After that, when he releases connection the terminal ought to disappear from his inventory.
  13. Ok, so apparently Releasing Controls from the UAV is not equal to disconnecting from it, so that is the reason for the terminal not being removed, but I swear it worked the other day... Anyways, it still leaves the question as to why the player cannot connect to the terminal in MP in the first place. Still no luck...
  14. Hey @Maff Unfortunately it does not change anything. When launched on a dedicated the terminal gets added but never connects to the actual turret 😞 That's exactly what I was thinking but for some reason it does not work still. Maybe I am missing some kind of step on the UAV connection, but on the other hand it works fine in SP, so not sure if that's the issue. Edit: The connectTerminalToUAV on the wiki also says: Maybe the UAV gets connected to some other terminal before I even attempt to do that? I don't think so, but I may try to work around that actually. Edit2: Nah, it's not that. Furthermore when testing this in SP, now the terminal does not get removed from the player's inventory after he has disconnected so that's another thing :/
  15. Any ideas anyone? I have no damn clue what I am doing wrong as it's even working when I'm testing it on local MP server but not on a dedicated. I will be very grateful for help with this 😞
  16. Hey guys, I am in need of a clever explanation of what I'm seeing and a helpful hand with fixing it. I have created an action that calls for a chopper from a nearby location and makes it move and land in a different location. The script works locally without issues. The script works in multiplayer when called using the Zeus code module option. The script does not work when called by addAction (either attached to a player or a static object). By "does not work" I mean the helicopter does receive the cargo (which means it is recognised) but the chopper just sits there forever. ["Land_PaperBox_01_small_closed_brown_IDAP_F", helicopter1] call ace_cargo_fnc_addCargoItem; ["Land_PaperBox_01_small_closed_brown_IDAP_F", helicopter1] call ace_cargo_fnc_addCargoItem; ["Land_PaperBox_01_small_closed_brown_IDAP_F", helicopter1] call ace_cargo_fnc_addCargoItem; ["Land_PaperBox_01_small_closed_brown_IDAP_F", helicopter1] call ace_cargo_fnc_addCargoItem; hint "Friendly chopper incoming"; helicopter1 move (getPos heli_landing_pad); sleep 15; while { ( (alive helicopter1) && !(unitReady helicopter1) ) } do { sleep 1; }; if (alive helicopter1) then { helicopter1 land "LAND"; while { ( (alive helicopter1) && !(unitReady helicopter1) ) } do { helicopter1 engineOn false; }; }; For the love of me, I cannot understand why it keeps happening. I even called the helicopter1 move part individually from the zeus interface and it did work. Thanks a lot, Adam
  17. Thanks @Dedmen, I will try that as well!
  18. @Maff I did. Only the move command did not work but again, it did not work only when called by addAction from the player/object. Yep, locality is also something which I struggle with constantly as well. You may be right with the move command description (Group or unit must be local to have global effect for this command.). I actually thought about it as well but did not manage to work around it. The idea of using the waypoint instead might be a good one. I will try that out as soon as I get back home 🙂 @genesis92x Thanks for the input too. When you mention the remoteexec, do you suggest it would look like this? Think it would work then? this addAction ["Call for a chopper", { remoteExec "call_heli_1.sqf" }] Thanks for your help guys!
  19. Hey @Maff, That's the whole point - for some reason the script works when spawned by debug but does not when spawned from addAction, which is attached to a player using the simplest syntax for that command. The while do loops were actually necessary for me as a workaround for when the heli reaches the vicinity of the landing pad, but hovers over it forever instead of just landing. I agree it's not always needed but it's the only way it has worked for me in this example. One more point I'd like to emphasize is that the addAction used on the player worked flawlessly in single player environment but failed on the "move" part in multiplayer, which boggles my mind. Not sure if you have tried your script on a dedicated? When I get back home I will try that again, also using your script. Do you have any idea what might be the reason for the script working differently depending on SP/MP?
  20. Hey guys, I am currently working on a mission that would feature some kind of a "command center" (for the lack of better description...) which would have a few screens. Those screens have been set up to receive a texture captured from a camera attached to a uav (to be precise, the Pelter drone from the new Contact DLC). I have used a script kindly provided by @killzone_kid which I have only adjusted for the other drone type and basically looks like this - this is repeated for 12 screens in the init.sqf: laptop1 setObjectTexture [0, "#(argb,512,512,1)r2t(uavrtt1,1)"]; cam1 = "camera" camCreate [0,0,0]; cam1 cameraEffect ["Internal", "Back", "uavrtt1"]; cam1 attachTo [pelter1, [0,0,0], "PiP1_demining_pos"]; addMissionEventHandler ["Draw3D", { _dir = (pelter1 selectionPosition "PiP1_demining_pos") vectorFromTo (pelter1 selectionPosition "PiP1_demining_dir"); cam1 setVectorDirAndUp [ _dir, _dir vectorCrossProduct [-(_dir select 1), _dir select 0, 0] ]; }]; The UAV feeds are being thrown on the screen in sequence one by one. This is how it looks in a test environment with 12 machines - you can see that the last four laptops turn black and show no feed. When I deleted the part of the script responsible for the first laptop, the 9th one worked fine so again - no more than 8 at once. I have two issues with it: - Obviously, I can display no more than 8 feeds at once - any more than that will appear as black screen - similarly, when opening the uav terminal, the turret control window will also appear black/blank. I do not mean to complain, but do you think this is an engine/performance limitation of some kind and there's no way around it? - Will this effect even be global to other players or only local (I fear the latter)? If local, is there a way to display this kind of effect globally to such a scale in a multiplayer environment? I appreciate all the feedback on this topic. Thanks a lot in advance! Adam
  21. Thanks @beno_83au, it sure looks like limitation of some sort now that you mentioned trying this in the past. Too bad we can only work with as many as 8 but again - don't want to complain. It's still great that we have such feature in the first place. I am still kind of uncertain on the aspect of locality of the view, as in who will see what in MP environment, but I guess I will just try it out with a few chaps. Thanks a lot for help!
  22. Thanks for your response @wogz187. I have actually decided to create this test scenario as I have initially started placing those cameras in a real mission scenario. There, I have noticed that some of them do not to work so thought that I try to isolate the issue as I could have made some mistakes in the script. I have also placed around 10 cameras in the mission. So as it turns out the script was just fine but again, there seems to be a kind of limitation on the render-to-texture feature. I couldn't help but dig a bit more and I found the below thread from about a year ago. I am not sure if this is the same thing exactly, but they also mention that there is apparently some limit as to how many of those textures can be displayed at once. This seems unconfirmed to me though. Either way, the original questions remain: Is there any way around it to make more of those screens? Will this effect be visible to other players in MP? Thanks!
  23. Hey, I am in need of help with trigger conditions checking whether there are enemy units (OPFOR) present inside vehicles such as jets, helicopters or boats. The idea is to have the trigger check whether enemy aircraft (or boats, but that's really low priority and optional) is approaching a large location covered by a trigger (about 10+km in size) and when that happens, launch an alarm sound effect in a certain place on the map (possibly not the trigger itself, because they are supposed to be placed in different locations). The important thing is that it's not only OPFOR - present, as the activation type, but OPFOR units in aircraft-type vehicles. An extra nice-to-have feature (if even doable) would be to display a hint or any kind of message on the screen informing about the type of aircraft incoming (not necessarily the name of the specific type of aircraft, but rather its type, so in that case "helicopter" or "jet"). I would be grateful for help in defining this condition! Thanks! Adam
  24. Seems to be working, thanks a lot for your help @stanhope! Now that it does work I think that I may have incorrectly set up some other things in the mission which may have triggered the sound twice, not the original script provided by you in the first post. Anyways, I will dig a bit more but for now this solution does work, so thanks a lot again!
×