rga_noris

BUG: Group will not follow waypoint after entering vehicles assigned using addVehicle. I've added a task in the feedback tracker with a repro mission, but I wanted to check to see if anyone else has noticed this either: If any group is given a waypoint and has a vehicle in either "Wheeled_APC_F" or "Tank_F", they will not complete their waypoint. The vehicle has been assigned to the group using (group) addVehicle (vehicle). They will enter the vehicle appropriately, but they will never move to the waypoint. Any vehicle of any other class will work just fine. Note, this is not due to the commander position, as not all of the vehicles in those classes have a commander position. I first noticed this when going from Main Branch to the Tanks Update (not RC, official update). EDIT: One work around is to wait until after the units have entered the vehicle. Then change their group (steps below) and reassign the waypoint. They will behave as normal. Bug Report: https://feedback.bistudio.com/T128274

Video of problem: https://youtu.be/sdLyEm3NNRM Feedback tracker: https://feedback.bistudio.com/T125385 Hello! I've been using kbTell for some time now with solid success, however I recently noticed a bug. I'm actually not certain if this bug has always been present, or if I am just now noticing it. The reason for this post is to make sure it isn't my usage that's creating the issues. I am going to throw this into the feedback tracker as well. To sum up the video above, when kbTell is used on units that are not local to the person observing the conversation, only one person will speak at a time. So if player A is next to Bob and Bill, and Bob is supposed to talk at the same time Bill is, Bob will need to wait until Bill is done speaking, but Bob will lip sync on time. Now you might think this isn't a bug, in that they are having a conversation. The problem will be if Bob is miles away from Bill, talking about two different topics, Bill would still not say a darn thing until Bob is done, or vice versa. Now, if the units speaking are local to the observer, there is no issue. They will speak over each other if required. The video does a better job, showing both scenarios, so please take a gander if you have time. Here is the code used in the video: In game script: Ermy linkItem "ItemRadio"; Carl linkItem "ItemRadio"; Ermy kbAddTopic ["testTopic", "sentenceDB.bikb", "", ""]; Carl kbAddTopic ["testTopic", "sentenceDB.bikb", "", ""]; [] spawn {Carl kbTell [Carl, "testTopic", "Carl1B", ["",{},"",[""]], false]; sleep 0.5;Ermy kbTell [Ermy, "testTopic", "ErmyHelpPlane", ["",{},"",[""]], false];}; SentenceDB.bikb (located in the missions root) class Sentences { class ErmyHelpPlane { text = ""; speech[] = {"\BND\sound\Ermy\ErmyHelpPlane.ogg"}; variant = ""; variantText = ""; class Arguments {}; }; class Carl1B { text = ""; speech[] = {"\BND\sound\Missions\G01\Carl1B.ogg"}; variant = ""; variantText = ""; class Arguments {}; }; };

To change it, you would need to define a new class that is essentially that class, but with a different side. You would need to do this in a mod which you would pack into a pbo. The easier way is to simply place the units in the editor. Then place an OpFor unit. Open up the OpFor units attributes and set his probability to 0. Then, select your BluFor guys and right-click on one. Click connect and then group them all to the OpFor guy. Now they will all turn red and be OpFor. You can even delete the OpFor guy, but if you leave him there it the zero chance of probability will make sure he never shows up. Super quick and easy.

Since grp returns the created group by that function, just run the same loop on all units in that group (which is represented by the global variable grp in the script you provided). Since grp is overwritten by the most recent group created, as long as the forEach loop comes immediately after you should have no issues. Should look like this: grp = [getmarkerpos "M1", independent, 6] call bis_fnc_spawngroup; { _x removeAllEventHandlers "HandleDamage"; _x addEventHandler ["HandleDamage",{ _damage = (_this select 2)*1.5; _damage }];}forEach units grp;

Add the triggered waypoint for your vehicle just a few feet in front of it, making your intended waypoint the second waypoint. The truck will budge a few feet, and then wait for the trigger.

Well, that is how call works, fairly certain I'm not mistaken on that bit. I suppose I'm not certain exactly what you mean. Call is unscheduled, which essentially just means that it is a priority to the engine, so it will be run immediately as opposed to in line with the scheduler. It will, however, delay scheduled items until it is done, which I think is what you want to avoid... maybe?

So this is a tough question, as I'm not sure exactly what you mean, but here it goes. There are two ways to call a function. call and spawn. Let's say you have a simple function: CM_simpleHint = { hintSilent "A hint!"; }; There are two ways we could run this function. The first is call: [] call CM_simpleHint; In this manner, the script would run, however the game would essentially stop until it is done. I think this is what you mean. Because of this, certain things are a bit different. 1) You cannot suspend the script with sleep or waitUntil functions. If you could, the script could easily and indefinately freeze the game. Second, while loops are limited to 10,000 iterations for the same reason. A while loop halts the script until it is done, meaning that if a while loop is in a called function, it halts the game until it is done. That said, a called script is run much faster than its spawned cousin, and can also return a value. For example: _randoVar = [] call CM_funcAlwaysReturnsTrue would be the same as _randoVar = true, provided true is what the function returns. The function can return anything. Next is spawn: [] spawn CM_simpleHint A spawned script will not stop the game, it will run along side any other script. You can suspend this script as well for as long as you would like, and while loops are not capped. The disadvantage is that it will be slower, and you cannot return a value from the script in the same way as you can with call. _randoVar = [] spawn CM_funcAlwaysReturnsTrue would NOT equal true, instead _randoVar would be the scripts handle, for usage with commands like scriptDone. Additionally, you can run things via an FSM. FSM's are much the same as call, except they do not halt the game and run along side. They are their own topic in and of themselves, however, and are more suited for constantly looping tasks and AI stuff. I can help you with these as well if you think they would fit your need. Finally, whether called or spawned, any script can slow down game performance if written ineffeciently or with errors.

I'm not familiar with that particular function, however there is another way you could get a random position within a circle. As long as the trigger is a perfect circle, you could do something like this: _random_pos_in_trigger = (trigger getRelPos [(random ((triggerArea trigger) select 0)), random(360)]); I just tested this and it works without issue. Let me know if you need something a bit more complex for different shapes. EDIT: I figured I would show how this works: trigger is the name of your trigger, obviously. getRelPos is script command that gets a position relative to the location of an object. So trigger is our object, and then the array we pass after the getRelPos command is [distance, direction]. So if you put in trigger getRelPos [90,180], that would return a pos that is 90m to the direct south of the object. So, we want the distance and direction to be random. The distance needs to not exceed the radius of the trigger. We can get the radius of the trigger by using this: ((triggerArea trigger) select 0). triggerArea returns this array: [a, b, angle, isRectangle, c] . Since we have a perfect circle, selecting the first element of the array will work as it is the same as the second, so we use select 0 (arrays elements are like so [0,1,2,3.....,15,16]). We then add random in front of that, as this will return a random whole number from 0 to the stated value, which in our case would be the radius of the trigger. Next, we need a random direction. Since headings in Arma are 0-360, we simply need a random number from 0 to 360. Tada!

https://feedback.bistudio.com/T125385 Ok, give it a shot!

It was made with WinRar... I'll try just making it a zip

https://feedback.bistudio.com/T125385 There is the ticket with the repro mission attached. Directions for Repro Mission: Run the mission on a dedicated server and join (mission is done quickly with only one player in mind). Use your radio menu (press 0, by default), and use 1 to make Ted Talk, 2 to make Bill talk, and 3 to make them attempt to talk at the same time, reproducing the bug. Let me know if you have any questions!

To be clear, you're looking for a repro mission for the kbTell bug, correct? Although I'll still put up the mission, what's on your mind as a possible cause? Just curious, I've done a ton of looking around and general fiddling about with no luck.

I put the kbTell issue in the bug tracker. I'll make a repro mission tonight and place it in there. Had anyone put the say bug in the bug tracker? There are bugs for the say command in there, but I couldn't find the specific one.

So recently I decided to play with Say3D. I have several sounds in a mod, which I added to the description.ext via adding to CfgSounds. I also tried to set it up in the mods config.cpp. Initially, the sounds worked using say3D with no issue. The characters lip synced just fine. Then, seemingly for no reason, the characters started mumbling (like the sounds we're spoken incredibly fast, but no change in pitch). This was after adding more voices, so I reverted back to what worked... Except now it no longer works. These sounds work with playSound and playSound3D just fine. I even tried some vanilla sounds, and some of those worked while some exhibited the behavior I mentioned. I have made no changes to my files that worked. I do not want to use kbTell for reasons I outline in this video: Please help!

Video of problem: https://youtu.be/sdLyEm3NNRM Hello! I've been using kbTell for some time now with solid success, however I recently noticed a bug. I'm actually not certain if this bug has always been present, or if I am just now noticing it. The reason for this post is to make sure it isn't my usage that's creating the issues. I am going to throw this into the feedback tracker as well. To sum up the video above, when kbTell is used on units that are not local to the person observing the conversation, only one person will speak at a time. So if player A is next to Bob and Bill, and Bob is supposed to talk at the same time Bill is, Bob will need to wait until Bill is done speaking, but Bob will lip sync on time. Now you might think this isn't a bug, in that they are having a conversation. The problem will be if Bob is miles away from Bill, talking about two different topics, Bill would still not say a darn thing until Bob is done, or vice versa. Now, if the units speaking are local to the observer, there is no issue. They will speak over each other if required. The video does a better job, showing both scenarios, so please take a gander if you have time. Here is the code used in the video: In game script: Ermy linkItem "ItemRadio"; Carl linkItem "ItemRadio"; Ermy kbAddTopic ["testTopic", "sentenceDB.bikb", "", ""]; Carl kbAddTopic ["testTopic", "sentenceDB.bikb", "", ""]; [] spawn {Carl kbTell [Carl, "testTopic", "Carl1B", ["",{},"",[""]], false]; sleep 0.5;Ermy kbTell [Ermy, "testTopic", "ErmyHelpPlane", ["",{},"",[""]], false];}; SentenceDB.bikb (located in the missions root) class Sentences { class ErmyHelpPlane { text = ""; speech[] = {"\BND\sound\Ermy\ErmyHelpPlane.ogg"}; variant = ""; variantText = ""; class Arguments {}; }; class Carl1B { text = ""; speech[] = {"\BND\sound\Missions\G01\Carl1B.ogg"}; variant = ""; variantText = ""; class Arguments {}; }; };