VictorFarbau

Yup, the vehicle configs are not finished in many aspects. I also believe that fuelrate was meant to provide some fuel/KM ratio. This along with many other config entries will need a brush up through time. It might happen or not; in the end there was that community configuration project for A2 by kju to address the abandonded config errors. Let's see how this evolves in A3. Cheers, VictorFarbau

RPM multiplication could be. But seriously, that 0.01 consumption rate is all across the board for all sorts of engine types so I think the vehicle configs are just not finished yet. I looked at 2 parent classes using the splendid config viewer and found this: configfile >> "CfgVehicles" >> "Truck_01_base_F" >> "fuelCapacity" = 45L // WRONG configfile >> "CfgVehicles" >> "Truck_01_base_F" >> "fuelConsumptionRate" = 0.01 // WRONG configfile >> "CfgVehicles" >> "Truck_02_base_F" >> "fuelCapacity" = 350 configfile >> "CfgVehicles" >> "Truck_02_base_F" >> "fuelConsumptionRate" = 26 Mind you, the "Truck_01_base_F" class spawns childs like the huge bluefor ammo truck. Hence, I believe it is a shortcoming to live with for now (or to re-config everything, but then again it might get fixed in any beta, so what the heck - for now :) ). And even if 0.01 would make any sense to the engine it still provides tanks with an virtually endless fuel supply as stated in the ticket. Cheers, VictorFarbau

It's been a long time that I finally got around to play some A3 again :) But one thing that struck me during one of my missions was the zero-fuel consumption bug of all tanks. I am referring to this feedback: http://feedback.arma3.com/view.php?id=15845 I found that all LandVehicles that I used have that config entry "FuelConsumptionRate" properly set (mostly values of 0.01). I just wonder if anybody knows: what is this value used for? I guess it is some sort of multiplicator used on "fuelCapacity", which is another config entry. But how would A3 use this value by design? Rate per KM driven? Rate per hour? Rate as of a certain speed? VictorFarbau

I personally don't give a toss if those camouflaged units feature a male or female face under their helmet. But I do care if this binds resources that could otherwise work on improving other in-game models such as vehicles, buildings etc. In that case don't do it; or if you do, don't expect any thank you other than from the 4 women worldwide who play Arma 3 :) Cheers, VictorFarbau

This beta is supposed to fix "weapon fired" CTD in MP. No further changelog published. http://www.arma2.com/beta-patch.php Cheers, VictorFarbau ---------- Post added at 13:02 ---------- Previous post was at 12:54 ---------- And to comment on the beta: 1. Perfect, no more crashes in MP when firing a weapon. The weekend has been saved :) 2. Bug: setAcctime command is disfunctional? I tried in STR's debug console and it has no effect, when did that happen? 3. Bug: in MP Mission SC48 - Sector control I am still hitting invisible targets in my gun barrel with all weapons (look here) Cheers, VictorFarbau

Same here, consistent CTD with patches 102111 and 102209 as well. What I do: 1. My shortcut to test (no addons except for the beta patch): C:\Games\ArmA2\Expansion\beta\arma2oa.exe -mod=Expansion\beta;Expansion\beta\Expansion -nosplash 2. MP Mode, host "Zargabad SC48 Sector Control", start mission, fire your weapon, bullets seem to hit something in the barrel (small cloud of debris appears in the middle of the barrel, looks real odd), occasional CTD after some 10 to 20 shots, happens with each available weapon. 3. Takistan COOP 18 Morning Dew - immediate CTD during the 1st shot Is this reproducible on your end or do you need more dump files sent? Cheers, VictorFarbau

No success and my gut feeling is, even when correctly computed it will still look completely dorky. Here's what I observed during my attempts: When A is attached to B: 1. setVectorDir alone will just cause unit A to flicker once 2. setVectorDirandUp applies the horizontal position of A correctly (array 1 of 2) but seems to completely ignore the pitch and bank array (array 2 of 2) 3. setVectorUp needs to be applied on A but can only be used in conjuction with a preceding setVectorDirandUp 4. calculation of a identical pitch and bank requires compensation for current vector of B PLUS misalignment between model centers PLUS distance between A and B So keeping the north orientation through setVectorDirandUp is no problem (sin and cos of parents direction), pitch and bank remains more or less out of control even though I bascially understand how they are supposed to work now. If the desired flat north orientation works then still this looks unnatural as the rotational center of A and B won't match (point 4, downside of attachto). I already spent 4h with this and the results just look stupid so I will put this idea to rest; maybe attachTo + setVector just doesn't cut it for this requirement. Sorry UNN, it just doesn't work out correctly for me and I can't figure out why. In my opinion a classical 3d vector command [degree left/right, degree up/down, degree forward/backward] would be more helpful compared to this freaky 2 * 2d vector concept. And guess what, if you had VBS2 you'd solve your problem in 2 minutes (parameter "relative"): VBS2: http://resources.bisimulations.com/wiki/setVectorDirAndUp VictorFarbau

I almost got it, it needs some finetuning but it should work eventually. It's not only about understanding the applied vector space but also the sequence of commands is essential apparently. When I'm done I'll post it here. If you don't hear back I jumped out of the window. Cheers, VictorFarbau

Yep, clear. After attaching a child to a parent object the child will assume the parent as its coordinate system and north means being straight aligned with the parent. As I see it the calculation would be: 1. Calculate delta of parent's vector and real world [0,0,1] 2. Apply inverted delta to the child object Surely enough quite annoying to calculate :) Post 2 shows the translation from degrees to vector which is needed for step 2. Haven't wrapped my head around step 1 yet and it shouldn't be rocket science but I saw many people giving up on setVector so I won't talk too big. VictorFarbau

If I understand correctly you would like to attach an object that behaves like water. Always leveled and in your case always facing north. So the script would constantly need to calculate the correct pitch and bank relative to the parents object and execute some setVector statement. Why not use a simple setDir and then a loop of setPos with a position relative to the parent object instead? Both approaches require to be run every 0.01 seconds to provide best results anyway. Or do you think attachTo + setVector causes less delay in positioning compared to setPos when in MP? In SP there's never an issue usually, in MP there can be delays even with attachTo objects, as I have observed a couple of times during MP games. And if you're concerned about the parent object crashing into the child object during movement you could still execute "enableSimulation false" on the child object as long as attached to the parent. Just my 2 cents, VictorFarbau

Seriously, forget about adding that chair unless you really need it as your personal eye candy :D You'd need a different logic to achieve what you want: 1. Add a permanent action to the plane such as "Get in as CoPilot" which triggers "getinco.sqf" (for example) 2. "getinco.sqf" attaches the *caller of the action* to the plane like you do already 3. "getinco.sqf" then assigns an action "Get out" to the *caller of the action* which triggers "getoutco.sqf" 4. "getoutco.sqf" detaches the caller from the plane and removes the action from the caller Somewhere in the scripting wiki you'll find all useful information about action parameters in order to determine the caller of an AddAction menu entry. Of course it's only a workaround for a second seat but it can work this way. Attaching objects to each other works in realtime on clients. If you run the same on a server clients will observe a delay in positioning of the 2 objects - which somtimes looks really odd. As said... workaround. If you need a real 2seater you'd need to edit the model configuration indeed. VictorFarbau

I confirm the fps drops are history, perfect :)

Build 98736 has been posted on the beta site and it is supposed to fix the performance breakdowns we experienced since 98220. So, everybody who experienced these huge fps drops should test this and feed back accordingly. Cheers, VictorFarbau

I tried to repro it like 5 times w/o success. Then we went for a round of MP and when assaulting a city with 141 units on the Chernarus map (counted by <count allUnits>) I suddenly had a slowdown to 2-3 fps. Yet no crash or any entry in the RPT file to be found. However, my team buddy's Arma froze completely and when we looked into his rpt file it read: No alive in 10000 note: Minidump has been generated into the file C:\Users\anon\AppData\Local\ArmA 2 OA\arma2oa.mdmp ===FROZEN====>>>>>>BEG Version 1.62.98443 Fault address: 006AD160 01:002AC160 D:\Games\ArmA 2\Expansion\beta\arma2oa.exe Prev. code bytes: 8B 01 6A 01 6A 00 8D 55 E8 52 FF 90 98 00 00 00 Fault code bytes: D9 5D 0C 8B 07 8D 4D E8 51 8B CF FF 90 44 07 00 Registers: EAX:00000063 EBX:E36E30AE ECX:46F8D0C0 EDX:018CF200 ESI:FFFFEB6B EDI:5E9B8100 CS:EIP:0023:006AD160 SS:ESP:002B:018CF1C8 EBP:018CF228 DS:002B ES:002B FS:0053 GS:002B Flags:00200202 ===FROZEN====>>>>>>END I can pull the minidump file from him; I will send it to Dwarden as soon as I get it. EDIT: Ran a mission with 212 units on the map, sporadic recurring freezes and stuttering occurs which got worse through time. Eventually the game froze for 10 sec, ran for 1 sec, froze again for 10 sec. I managed to enter this into the command console: "{deleteVehicle _x} forEach allUnits;" and immediately the freezes were gone. Makes me believe it is directly related to AI activity. EDIT OCT31st: sent dump, minidump and RPT file of my team member's frozen unit to Dwarden by mail. Cheers, VictorFarbau

I confirm the observations: same here. A friend warned me to not install 98220 before our sunday MP session since it would slow down the game to 1 - 2 fps at times. He has an nVidia graphics card so I thought: what the heck, I have an ATI so I should be fine. Wrong assumption :) Some 10 to 15 minutes into the game (I was hosting MP on my local machine) freezes and fps-drops occured and eventually I had to shut down Arma through the task manager. Went back to 98148 and the game smooth as butter for 2h even with 3 clients attached. VictorFarbau