Jump to content
Bohemia Interactive Forums

VictorFarbau

Member
 View Profile  See their activity

  • Content Count

    557

  • Joined

  • Last visited

  • Medals

Posts posted by VictorFarbau

  1. Posted

    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

  2. Posted

    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

  3. Posted

    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

  4. Posted

    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

  5. Posted

    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

  6. Posted · Edited by 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

  7. Posted · Edited by 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

  9. Posted

    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

  10. Posted

    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

  11. Posted · Edited by 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

  14. Posted · Edited by 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

  15. Posted

    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

  16. Posted

    Nice topic... I remember the days when I was into embedded programming a long time ago. We essentially simulated damage to a moving object (robot) by attributing agility parameters to each functional group (legs, arms). The more damage taken (based on caliber e.g.) the higher the effect on the agility parameter. And this parameter was then broken down into speed and coordination values. Random value weighting was done so that sometimes for example an arm would still move correctly but very slowly; sometimes it would just wobble around (no coordination) but in normal speed. As easy as it is to implement, it simulated a random injury on a sufficient level for our model, where sometimes nerves are hit, sometimes the muscles, sometimes both.

    VictorFarbau

  18. Posted · Edited by VictorFarbau

    There is a function to query the distance in 2D to avoid the height problem. I don't recall the syntax now but I will add the codeline to this post later today.

    EDIT

    _mydistance = [x1, x2] call BIS_fnc_distance2D;

    Measures the line of sight distance between x1 and x2. Works fine, I am using this in some HALO scripts. You need to have the function manager present on your game map though.

    Cheers,

    VictorFarbau

  21. Posted · Edited by VictorFarbau

    I sent my crash dump through to Dwarden.

    And after hours of testing I narrowed it down to one addon which causes a CTD 4 out of 5 times when I warp to different parts of the world (Chernarus). Annoyingly enough it's even my own addon "VFAI_Smokeshell".

    Here's my assumption:

    VFAI_Smokeshell uses an event handler that fires each time an object of type "man" is created. This is in order to add the "wounded" event handler and to add 1 smokeshell. When I warp into random cities on the map then I can observe how objects and textures are loaded, cars and people are spawned (using the ALICE module). I guess the crash is somehow related to the spawning of "man" class objects which is caught by VFAI_smokeshell. Anyway, just guessing here.

    EDIT: Coming to think of it, I think I made this ExtendedEventHandlers compatible a long while ago. So the scripts should be fired by EE and not directly.

    Cheers,

    VictorFarbau

×