Jump to content

VictorFarbau

Member
  • Content Count

    557
  • Joined

  • Last visited

  • Medals

Posts posted by VictorFarbau


  1. Bob, you might need to move over to the editing forum instead.

    Editing Forum

    If you want to add something into the "init" line of a unit then you're looking for commands such as "removallweapons this; this addmagazine "G36Mag"'; this addweapon "G36" " for example. Have a look around and search, there's plenty of examples available.

    Regards,

    Victor


  2. Infam0us, two thoughts from my side:

    1. Is it possible you have some problem with HID connected to your computer? Like a rampant mouse or joystick or both? Maybe disconnect or try another one?

    2. Do you have any program installed that tries to hook in between video output and maybe causes these errors? Like any screen capture program or VNC or similar? What did you install or try right before this started?

    Regards,

    Victor


  3. @Whisper: thanks for your extensive reply. I got it now. Funny thing is that normally I am at proficient level in networking myself somehow but up until now I failed to see the close relation between protocol and the ArmA netcode. I guess I am too much into Application design recently. I was blind, now I can see smile_o.gif

    @ShinRaiden: thanks for the tips, I shall do that.

    Quote[/b] ]working locally with full arrays while syncing with indexes

    I use that for example for my MP Intercom system, just tokens and indexes being sent around to exchange messages. But the traffic caused by massive presence of moving enemies at times is beyond my influence. Here I have to trust Arma's netcode to just get it done.

    As said, network lag is ok, it would be obvious when the amount of objects gets out of hand and it would get better again when less objects are present. But in my case it broke the complete mission. So dropping network messages completely because they are "too big" is something the ArmA netcode programmers must resolve, not my fault. Imagine TCP or UDP would throw these errors all the time because some stuff you try to download would be too big or something. A bit absurd.

    Worst case I have to artificially limit the amount of objects in my mission. Pity but ok.

    Regards,

    Victor


  4. I tried these parameters now:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MaxMsgSend = 256;

    MaxSizeNonguaranteed = 256;

    MinBandwidth = 512000;

    MaxBandwidth = 768000;

    Result: NO MORE error entries in the server log but terrible sync issues again, team members not accepting commands anymore, running on the same spot for minutes and every single respawn ends in the irreversible "head freelook" mode. Very frustrating. I'll try to reduce the MaxMsgSend now again and if that doesn't work I'll revert to

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MaxMsgSend = 128;

    MaxSizeNonguaranteed = 1024;

    MinBandwidth = 512000;

    MaxBandwidth = 768000;

    Sigh - and that on a local server huh.gif Maybe I should take out the Bandwidth paramters - but those I left in to simulate the limitations of my DSL line. Only I would expect no lag at all with these when the server ping is almost 0.

    Victor


  5. @Whisper:

    I am using a separate computer to host my dedicated server and test and play missions. When my buddies connect they do so through my DSL line so it's only me with a 100Mbit connection. So I guess it would be best to play with a couple of performance parameters to get the best results for all parties.

    But what's the point of limiting it down to 128 byte e.g. when the netcode can't work with these parameters and complains about failed messages due to huge size anyway?

    So I am not sure how to systematically resolve this if I can't trust the netcode in that sense.

    Regards,

    Victor


  6. Howdy Sickboy.

    True, I added these lines to the Arma.cfg file. And they did make a noticeable difference in the game so I assume the game uses that file. Will verify tonight.

    >Still wouldn't explain it though as the standard setting is 512,

    Yes, exactly. I only added these lines after I had problems, not before. Seems like the default 512 is too low; my test with 4096 makes matters even worse and 1400 seams to be reasonbly ok.

    To me the question remains as to why the netcode engine doesn't chop data messages into pieces with a maximum size when there is such a parameter in the first place.

    Since there's no effective control or feedback to the user (e.g. message on screen saying "Bandwidth overload") this will mostly go unnoticed. The folks I play with have certainly never opened their Arma.RPT files ever. And why would they?

    Risk is that people will just complain how badly ArmA performs yadda yadda. Another area of improvement? smile_o.gif

    Regards,

    Victor


  7. @Suma:

    Thanks for confirming the MTU influence, I would have never crossed my mind. But you know the code...

    What I don't understand is:

    I have set the parameter

    "MaxSizeNonguaranteed=1400"

    now and still the server logs errors such as

    "NetServer: trying to send too large non-guaranteed message (2861 bytes long)"

    So why does the server not just limit the message size as specifed and send 2 messages instead? I just fail to see where this is my fault if you know what I mean smile_o.gif

    If everything gets slow then ok, I'll look at my errors. But don't complain to me that the engine tries to send messages with invalid sizes.

    Not bitching here; but I'd just like to be able to work on my mistakes. Looks like I can't really complete fix this one all by myself.

    Regards,

    Victor


  8. Thanks for your thoughts guys. There could be one misunderstanding. When I talk about "messages" to be sent then I don't mean any custom made messages. It is the engine-controlled server-client messaging that has problems. So in that sense I really have little influence on size or shape of these. They just transport game information.

    One way would be to just decrease the amount of data being shoved around by limiting the mission. A pity but maybe the only solution long term.

    @whisper: "high if you have bandwidth issues, knowing that it will increase lag."

    Hm, right, that makes sense. I don't have bandwidth issues so I should decrease msg size. So I did to 1400 and voila, much better already smile_o.gif

    A lot of msg size errors still in the log (less than before, though) but a lot less Async issues in the game.

    In general I will look at methods to reduce traffic and keep the msg size down.

    Cheers mates,

    Victor


  9. @Whisper: you're relating this to the Ethernet MTU? This is a quite courageous assumption I guess. Your assumption about latency would in fact imply that the server itself would create the packets to be sent. But I highly doubt that; unless the server uses a proprietary protocol it should be up to OSI layer 4 (Transport) to manage that.

    Nonetheless I'll try this of course with an MsgSize of 1400 biggrin_o.gif

    @shinRaiden: what can I do with a statement such as "the issue is with your scripting"? I cannot actively influence the message size or amount of network traffic unless I limit everything down to 10 units. As said before; it did really work before (up to 1.05) and my mission never changed. It is also said that ArmA has been particularly optimized to allow "massive" MP environments. And up until recently this really seemed to be true for me.

    Ah well, I will keep trying.

    Victor


  10. BETA SERVER 1.7.0.5157 (updated BETA 1.07)

    I am regularly checking my "arma_server.RPT" file to scan for coding and generic errors.

    I managed to get rid of all current script errors but my Mega-Coop-Dynamic War mission suffers from Async issues; meaning that after playing for about 20-30min it can happen to any player that he gets killed by invisble enemies / he doesn't see any enemies anymore / he cannot kill any enemies.

    So I assigned markers to enemy units to trace them. After a while I basically saw a marker walking by right in front of me but I couldn't see any man or vehicle there. Next thing was that I got shot (just fell, didn't see or hear anything).

    Since I am testing these things on a dedicated server in my local LAN first I would exclude bandwidth issues (100mbit local).

    I have studied the included "DS-Admin.rtf" which talks about optimizing performance. There it says to tune paramters in the "Flashpoint.cfg" file. Well, since we rather talk about the Arma.cfg file I added the following lines to the Arma.cfg as well as to the server specific "sample.cfg" file:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    MaxMsgSend = 256;

    MinBandwidth = 512000;

    MaxBandwidth = 768000;

    MaxSizeNonguaranteed = 4096;

    And still my arma_server.RPT records hundreds of lines with the identical text:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    NetServer: trying to send too large non-guaranteed message (3291 bytes long)

    Message not sent - error 0, message ID = ffffffff, to 1884877695 (Victor)

    The "non-guaranteed message" size varies between 3000 - 3800 bytes. Can anybody recommend a better setting? Seems like setting these variables didn't make any difference at all - same errors before (using default) and afterwards.

    This causes Async issues all over the place. Positions not being updated, people not getting in or out of vehicles, the invisible death, player's head getting stuck in free-look mode etcpp.

    So I just did a "monitor" on the server and it shows "Outgoing: 2422kbps, Incoming 181kbps" on average. Isn't that a bit much for a simple mission with a few trucks, 2 - 3 tanks, 4 Helos and about 120 soldiers? I remember we played this mission often w/o any problems lately. This started very recently all of a sudden (maybe after updating to 1.07b-b?).

    Puzzled,

    Victor


  11. Get over it Balschiow. The OFP and now ArmA community has always been about sharing knowledge and techniques. And even if certain interest groups accumulated more knowledge you would still be able to benefit from their skills.

    Encrypting scripts would introduce a new mindset that would not do any good to the community but only to the ego of the script creator. You need to grow beyond this if this really bothers you biggrin_o.gif

    Remember that all this is non-profit work for a small computer game. In case somebody really decides to steal scripts and create a commercial product out of this he would find himself in big trouble very quickly anyway.

    Regards,

    Victor Farbau


  12. That's difficult indeed. Those triggers cannot be randomly delayed within the editor AFAIK (if anybody found a way, let me know smile_o.gif ).

    I did this a couple of times with a simple detour. The object calls a script once it is dead, the script waits for 10 seconds and sets another variable and the map trigger waits for this variable, got it?

    The object needs this in its activation field:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    this addEventHandler ["killed", {_this exec "killdelay.sqs"}]

    In the mission directory you need to create a text file called "killdelay.sqs" with this content:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    ~10

    iamdead = TRUE

    publicVariable "iamdead"

    Last but not least you need to change your end triggers "Condition" to "iamdead".

    Over and out,

    Victor Farbau


  13. Hello MadDogX,

    really a nice script, I like it a lot. I think the improvement suggestions are also a good idea. One more suggestion from myself:

    If the vehicle is of class "Air" then I could imagine it would be cool if some parts fly off continously until impact. It can be seen sometimes that during downfall the hull disintegrates more and more. I am not sure what it would really look like in Arma, but it could be worth a shot.

    Regards,

    Victor Farbau


  14. Core2Duo@2133Mhz

    NV 7800GTX@256MB RAM

    2GB DDR2 RAM

    Arma.exe, EU Version 1.5.0.5136 (= Patch 1.05)

    I get regular CTD since recently (might be 1.05, not sure). However, the event viewer always lists this as Application Error of Arma.Exe at address 0x002b143f.

    There's also a crash dump file created each time.

    Found 4 events in my event viewer, all identical yet from different days. Just thought I post this; maybe it helps debugging the code one day.

    Regards,

    Victor


  15. Salve,

    if I understand your requirement correct (first Heli1 touches down, then Heli2 starts descending) then you might as well just check for the height of Heli1.

    I do this in one of my scripts because the Heli AI is a mystery to me sometimes; even when scripted the AI seems to be driven by a lot of AI code still (shifting landing zones, ignoring some commands).

    So what I would do is simply something like this:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@(position heli1 select 2 < 5)

    That way the script really only continues when Heli1 almost is at touchdown. That ensure synchronicity of events at least.

    Victor


  16. I could show you an example but syntaxwise it would be identical to your statements.

    If I may advise you to change something:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? _Max =< _i : intrig = 1;

    publicVariable "intrig";

    Change this to:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    intrig = 1

    publicVariable "intrig"

    Reason 1: no semicolons needed in sqs if you use one line per statement (redundancy)

    Reason 2: no need to insert another condition once you just left the loop based on a condition (redundancy).

    Plus, it could be that "=<" is not a valid operator (syntax). Better use "less=" if you need to - but in this case it shouldn't be necessary.

    Your current code risks to leave "intrig" in an undefined state.

    Cheers,

    Victor


  17. Olle,

    you concept is sound - a script controlling an AI soldier should always only be run on the server. Thus, the first line to determine the server logic is also fine.

    I use a very similar script and it just runs fine. The only difference is that I use "NOT" instead of "!" because ! is not an SQF command I thought? Might be the script terminates with a syntax error at that point?

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    IF NOT(server) THEN {exit;};


  18. Cloughy,

    Quote[/b] ]Is there any issues with global vars being set in scripts, rather than a trigger?

    No there is not - I use them a lot in my missions.

    But there's some awkward twists in your "#LoopStart" loop as I see it (correct me if I'm wrong).

    1. _i never gets increased unless a unit is in the trigger and is alive. Imagine a unit is dead, _i will never be increased and the loop never ends.

    2. When the loop ends, just set intrig and publish it, no more conditions are needed then. This is redundant.

    Just my 2 cents,

    Victor


  19. You're right mad_o.gif And my fix was premature.

    I fixed this again and this time I even tested it whistle.gif It properly runs through time now and at midnight it skips one hour (to avoid DIV 0 annoyances). When using NV goggles it flashes exactly one time when the new day starts (don't ask me why) but then it continues to run normally. And if not let me know biggrin_o.gif

    Again, delete the last two lines of the server script if you don't want an even more accelerated night time.

    Regards,

    Victor

    MPtimeserver.sqs

    Quote[/b] ]# Accelerated Time Server build 005, © 2007 Victor Farbau

    # Map objects needed: game logic called "Server"

    # servertime = continuous count of time in seconds (00:00 is skipped, too much workaround otherwise)

    # accel = acceleration factor (24h in 1h = accel 24)

    # _hourlist holds an array of scenic starting hours, could also be set to a fix value if desired

    # VFserverhours, VFservermin are public variables that contain the server time

    ?!(local Server): exit

    _accel = 24

    _taccel = _accel

    _onehour = 3600

    _oneday = (24 * _onehour) - _accel

    _hourlist = [4,5,6,7,12,17,18,19]

    _hourcount = (count _hourlist) - 1

    _servertime = (_hourlist select (random _hourcount)) * 3600

    #tempusfugit

    ~1

    _servertime = _servertime + _taccel

    ?(_servertime < _onehour): _servertime = _onehour + 1

    ?(_servertime > _oneday): _servertime = _onehour + 1

    VFserverhours = floor(_servertime / 3600)

    VFservermin = floor((_servertime MOD 3600) / 60)

    publicVariable "VFserverhours"

    publicVariable "VFservermin"

    ?((VFserverhours > 20) OR (VFserverhours < 3)) : _taccel = _accel * 2

    ?((VFserverhours > 3) AND (VFserverhours < 20)) : _taccel = _accel

    goto "tempusfugit"

    MPtimeclient.sqs

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"># If this runs on a dedicated server - quit now

    ?(player != player): exit

    # Init global variables locally to avoid undefined values being used; then wait 5 sec for server

    ~5

    #tempusfugit

    ~1

    _localhours = floor daytime

    _localmin = 60 * (daytime MOD (floor daytime))

    skipTime (VFserverhours - _localhours)

    skipTime ((VFservermin - _localmin) / 60)

    goto "tempusfugit"

×