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

    First of all: fantastic soundmod and I really enjoy it a lot. Since my RPT file is being filled with thousands of errors after each mission (Cannot load sound xyz from your mod...) I'd appreciate any update as well of course.

    When you talk about a new version you're working on could you be specific about the new revision as well? Right now I used 0.9beta, no clue if this is the one being discussed here or whether you have a new rev in the making already.

    Thanks,

    VictorFarbau

  2. Posted

    The absence of the getposATL (Arma 2) is a showstopper in my mind; it's just no fun and would require a huge amount of workaround code again.

    Secondly, whenever you find errors using addons from A2 in A1 - check the command reference whether commands are available in A1:

    http://community.bistudio.com/wiki/Category:Scripting_Commands

    In the WHILE loop e.g. I used the "currentWeapon player" function. Checked in the reference - introduced in Arma2. You could use a workaround and use "primaryWeapon player" for Arma1. But if the player currently holds the secondary weapon and carries his primary weapon on his back then you end up with faulty positioning again. Also, try to replace getposASL by a simple getpos. Not that it solves it but ASL has no benefit here.

    I did this in Arma 2 because finally it was possible to grab and handle objects easily w/o 50 lines of workaround code. Maybe you can get it to work somehow in A1 however...

    VictorFarbau

  3. Posted · Edited by VictorFarbau

    Hello,

    well, the problem is that getposATL is a function introduced in A2 only. It enables the correct positioning of ladders when the player is above terrain level (e.g. on a roof). Arma 1 only knows about getposASL instead - I don't think this will work correctly.

    All would work fine while on the ground; but as soon as you'd enter a roof and spawn another ladder it would spawn somewhere way above or below you since the correct height of the player would be incorrectly computed.

    Nonetheless, I will compile a version using this command and upload it. And here it is:

    http://www.mediafire.com/download.php?x2glgwykp6lo872

    Don't blame me if it doesn't work well; I was relying on getposATL for this.

    VictorFarbau

  5. Posted

    Hello erazor,

    can't say I am really working on this at present, see here:

    http://forums.bistudio.com/showthread.php?t=106528

    I have never experienced any ammo disappearing through VFAI but the issues you describe are usually very hard to determine in the plain code. In the testing environment all that usually worked fine. But I have seen weird behavior in MP games; possibly due to delays in code execution and distribution of global variables.

    So I hope that someone at some point will pick up the challenge; I fought this battle for years :)

    VictorFarbau

  6. Posted

    Spangg,

    1. There is a big set of conditions that determine whether VFAI will be run or paused. I can say that the current code should be reasonably easy on the CPU.

    2. Ammo crates - unless we get an engine command to read the contents of ammo crates (respectively "weapon holders") from a script -which is not possible at present- that will be tough. It was / is one of the biggest engine restrictions for VFAI.

    3. Automatic reactivation after turning it off - that was resolved in the latest version (see the original addon post thread with its change notes).

    Regards,

    VictorFarbau

    thx Vic,

    Guys, whoever picks it up, (Nikita :) some suggestions if possible:

    it might be easier to make the script easy on cpu to render the script to safe behaviour only,

    also if recognition and usage of ammo crates and if they would enjoy priority over weapons on ground would be great.

    There was an issue with it as well if I remember well, namely you couldn't permanently switch to keep weapons because it switched back to drop weapons after some time automatically.

    ignore if they were addressed already, haven't used it for a while

    thx anyway...

  7. Posted · Edited by VictorFarbau

    Hello,

    recently I received a message from nikita320106 requesting permission to modify and re-release VFAI.Equipment with some of his ideas. I initially refused that since I planned to maintain and extend the addon myself in the near future.

    However, I have done an honest assessment regarding probability of that to happen and found myself saying: no time for this. Also, I lost a bit of interest in doing the same addon over and over again for almost 3 years now.

    So, instead of jealously guarding that lousy piece of scripting I thought I'd rather post the material I have :) If anybody feels like reworking / enhancing and re-releasing it: please do so! I give explicit permission to everybody to do this. I believe some fresh ideas are welcome here.

    Only this advice: keep the Equipment and Smokeshell addons separate (that little Smokeshell code is not even included, it is contained in the smokeshell addon and this is the only version I worked with).

    Also, observe unit behaviour in massive multiplayer when you modify the equipment code; you may find units getting stuck if you overload their command queue and the game might even crash. Be easy on the timings (no "delay 0.05" or similar). The more generous you are on the timings the better all this usually works - depending on how busy the engine is. Can be painful to debug this if there the error is not in the code but merely in the way you apply it.

    Anyway, the little time I can spend on Arma II OA at present is required for me to maintain our massive MP mission we rarely get to play. The little tricks and tweaks possible in Arma II still intrigue me so I will rather continue with small things such as VFFPSS, VFTCAS and the like.

    DevHeaven is ot reachable for me at this moment, so I am uploading this to the following location:

    http://www.mediafire.com/?d7hru9pgwnne4lz

    Regards,

    VictorFarbau

  10. Posted

    I have a demanding job next to being a father and it would have never occurred to me to waste my time on public servers with all that kiddy shit going on there. You just need 1 or 2 friends playing Arma; then you host a game on your own PC and off you go. Many hours of fun guaranteed.

    And yeah, you can't have 8 hours of sleep each day :) That you signed when you got a job + family + Arma II. So nighttime is playtime.

    VictorFarbau

  13. Posted

    Hi there,

    it's probably easiest to use object variables for this. You attach a variable called "build_lock" (choose your own name if you like) to the player. You set it to 0 during mission start (notin the creation script, then it would be set to 0 each time called).

    When the creation script is called it checks if the timeout period of 300 seconds is over already. After creating the item the build_lock is increased to time + 300. So the build script can never create another mortar if the time between 1st and 2nd creation is < 300 sec.

    // e.g. put this into the init line of the player

    // Init variable (run only once during mission start)
player setVariable ["build_lock", 0,false];

    In the creation script:

    // Check if player is allowed to build static item
IF (time > (player getVariable "build_lock")) THEN
{
  // create the static item here
  // Now set the timer to time + 300 sec
  player setVariable ["build_lock", (time + 300),false];
};

    Regards, VictorFarbau

  15. Posted

    For me exthread=3 is definitely an improvement. Playing a heavy mission on my local PC (up to 700 soldiers, 30 trucks, 10 Tanks, 5 Planes, 5 choppers and each unit running several scripts) results in smooth gameplay if I use setting "3". If I use "1" it feels a lot more sluggish somehow.

    Odd: whatever parameter I start Arma II with, the effects won't show in the Windows Task Manager or in FPS displays - they always report about the same values (25-30 FPS, up to 48% CPU on a quadcore, ARMA II using 15-16 threads). Nonetheless, I experience the best performance when using "3".

    When I host this mission on a dedicated server (which is the purpose) then my local PC runs at 55-65fps consistently, no matter if I use -exthreads or not. Seems to me that the effects become more visible the lower the PC performs to begin with.

    Regards,

    VictorFarbau

  21. Posted

    Some monitors display that behaviour after sudden color changes of bigger parts of the screen because certain electrical patterns (consumption mainly based on brightness) would cause some coils to vibrate. Or, the changing electrical fields have an effect on some insufficient shielding of the internal audio wires. My 2 cents.

    VictorFarbau

  24. Posted

    I don't think realism is the key property or goal here guys :)

    No kidding :) ACE, ropes and all that is about realism. This addon is strictly about gameplay and how to improve it. Carrying a bunch of long ladders in your pocket is as realistic as running around in a whole city of fake buildings - we could say they share the same denominator.

    Then again, I personally don't mind ropes as an alternative; this is maybe something for a future build (ACE detection -> rope addon usage).

    VictorFarbau

×