Jump to content

tirpitz

Member
  • Content Count

    42
  • Joined

  • Last visited

  • Medals

Posts posted by tirpitz


  1. I have 1 PBO that refused to pass signature checks, although the signature check utility does not throw and error.

    when launching Arma with the  verify signatures it does not pass with error 0x22.

     

    14:51:57 Signature tests for F:\Documents\Arma 3 - Other Profiles\Tirpitz%20[AM%202SA]\mods\TAW Community pack Public\addons\revo_reducedweaponsway.pbo PASSED!
    14:51:57 Signature F:\Documents\Arma 3 - Other Profiles\Tirpitz%20[AM%202SA]\mods\TAW Community pack Public\addons\rhs_no_smoke_bounce.pbo is wrong. Error 0x22. Test FAILED!

    1OXmnbf.png

    c3A4xAa.png

    both of these mods were signed using the same private key, at the same time in the same batch operation.
    PBO is available at link (11KB): https://drive.google.com/file/d/11VoGyFmSCPkDD0RI-Ck5BcvFdpNOpkFs/view?usp=sharing
    I have tried padding the config.cpp in the pbo (the only thing in there) with comments just in case the file was too small to generate a proper signature. I have tried changing the name of the file, the location on the drive to eliminate path name errors. Padding with images doesnt work either.

    I am running out of ideas.

    PBO was packed with PBO manager.

    Any help appreciated.


  2. So, let me preface this: I am not after the rain dance you performed that may have helped that one time on this one server. 
    I would like an explanation of what some of the networking related errors in the RPT mean and which setting (in the basic.cfg or otherwise) this relates to.

     

    These errors appear in the the server RPT log frequently and are often spammed thousands of times. yes this server is modded, and has 50+ players. many of these errors are accompanied by a large spike in CPU usage and desync and eventual crash or very slow recovery of the server.

    We have experimented with basic.cfg settings, and are currently trying close to default setting with little success.

     

    • First one that I don't understand,  mainly because my basic config  should prevent messages of this size:  
    MaxSizeNonguaranteed = 256;
    MaxSizeGuaranteed = 512;   
    class sockets{maxPacketSize = 1340;};
    22:00:30 NetServer: trying to send a too large non-guaranteed message (len=1288/1306) to 2097798637
    22:00:30 Message not sent - error 0, message ID = ffffffff, to 2097798637 (wicky [AM 2])
    22:00:30 NetServer: trying to send a too large non-guaranteed message (len=1288/1303) to 1070593847
    22:00:30 Message not sent - error 0, message ID = ffffffff, to 1070593847 (HC3)
    22:00:30 NetServer: trying to send a too large non-guaranteed message (len=1288/1308) to 983477534
    22:00:30 Message not sent - error 0, message ID = ffffffff, to 983477534 (Tirpitz [AM 2SA])

    To me the raises several questions: why is it trying to send messages larger than what I have specified, am I misunderstanding this message and how can I avoid it?
    What the maximum safe MaxsizeGuaranteed and MaxSizeNonguaranteed with respect to MTU if this is relevant.

     

    • Number two, this one,  the message type and the object identifier change, as well as the location (server/local).
    22:10:42 Client: Object 48:172 (type Type_460) not found.
    22:10:42 Client: Object 48:173 (type Type_460) not found.
    22:10:42 Server: Object 15:97 not found (message Type_460)
    22:10:42 Server: Object 15:96 not found (message Type_460)
    22:10:42 Client: Object 48:174 (type Type_460) not found.
    22:10:46 Server: Object 6:229 not found (message Type_96)
    22:10:46 Server: Object 6:228 not found (message Type_96)

     

    • Number three: 
    22:10:51 NetServer: cannot find channel #1648235163, users.card=55
    22:10:51 Message not sent - error 0, message ID = ffffffff, to 1648235163 (CURT [CC PXLC])
    22:10:51 NetServer: cannot find channel #1648235163, users.card=55
    22:10:51 Message not sent - error 0, message ID = ffffffff, to 1648235163 (CURT [CC PXLC])
    • and number four
    21:29:31 Server: Network message 302ef35 is pending
    21:29:31 Server: Network message 302ef36 is pending
    21:29:31 Server: Network message 302ef36 is pending
    21:29:31 Server: Network message 302ef36 is pending
    21:29:31 Server: Network message 302ef37 is pending
    21:29:31 Server: Network message 302ef37 is pending
    21:29:31 Server: Network message 302ef39 is pending
    21:29:31 Server: Network message 302ef3a is pending
    21:29:31 Server: Network message 302ef3c is pending



    Our current basic.cfg looks like this:

    // These options are created by default
    language="English";
    adapter=-1;
    3D_Performance=1.000000;
    Resolution_W=0;
    Resolution_H=0;
    Resolution_Bpp=32;
    
    
    // These options are important for performance tuning
    
    MinBandwidth = 131072;                // Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072
    MaxBandwidth = 104857600;                // Bandwidth the server is guaranteed to never have. This value helps the server to estimate bandwidth available.
    
    MaxMsgSend = 512;                                // Maximum number of messages that can be sent in one simulation cycle. Increasing this value can decrease lag on high upload bandwidth servers.Default: 128
    MaxSizeGuaranteed = 512;                // Maximum size of guaranteed packet in bytes (without headers). Small messages are packed to larger frames. Guaranteed messages are used for non-repetitive events like shooting. Default: 512
    MaxSizeNonguaranteed = 256;                // Maximum size of non-guaranteed packet in bytes (without headers). Non-guaranteed messages are used for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256
    
    MinErrorToSend = 0.002;                        // Minimal error to send updates across network. Using a smaller value can make units observed by binoculars or sniper rifle to move smoother. Default: 0.001
    MinErrorToSendNear = 0.02;                // Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well. Default: 0.01
    
    
    
    class sockets{maxPacketSize = 1340;};
    
    MaxCustomFileSize = 10000;                        // (bytes) Users with custom face or custom sound larger than this size are kicked when trying to connect.

     


  3. I don't have a PC at the moment.
    This is a massively overkill implementation of what you want: https://github.com/AsYetUntitled/Framework/blob/master/Altis_Life.Altis/core/functions/fn_keyHandler.sqf
    Perform some checks as to whether you are in or near a vehicle. Implement this somewhere: https://community.bistudio.com/wiki/User_Interface_Event_Handlers

    And your are good to go.


    Sent from my WAS-LX1A using Tapatalk


  4. This is what I love about this forum, people without any idea about code trying to get other people to implement their ideas for them without showing any kind of attempt themselves. Then when someone tries to help by suggesting an approach they very shot down because they didn't stop what they were doing and write some code for someone on the internet.

    Sent from my WAS-LX1A using Tapatalk


  5. I use this in a header file that I include where needed, simple version:

    has three levels of logging. 

    #ifndef tirpDebug
    #define tirpDebug 0 //define desired value for debug level before including this file (0-3)
    #endif
    #ifndef fileName
    #define fileName "UNKNOWN"
    #endif
    #define ERROR(MSG) if (tirpDebug >= 1) then {diag_log ("Tirp ERROR ("+  fileName + "): " + MSG );hint ("Tirp ERROR ("+  fileName+"): " + MSG );}
    
    #define INFO(MSG)  if (tirpDebug >= 2) then {diag_log ("Tirp INFO  (" + fileName + "): " + MSG );}
    
    #define DEBUG(MSG) if (tirpDebug >= 3) then {diag_log ("Tirp DEBUG ("+  fileName + "): " + MSG );hint ("Tirp DEBUG ("+ fileName+"): " + MSG );}
    advanced version, allows some messages to be logged permanently and another set logged only when a value is defined in that file to help reduce RPT spam. 

     

    #ifndef tirpDebug
    #define tirpDebug 0
    #endif
    #ifndef DEBUGTHIS
    #define DEBUGTHIS false
    #endif
    #ifndef fileName
    #define fileName "UNKNOWN"
    #endif
    #define ERROR(MSG) if (tirpDebug >= 1) then {diag_log ("Tirp ERROR ("+  fileName + "): " + MSG );hint ("Tirp ERROR ("+  fileName+"): " + MSG );}
    
    #define INFO(MSG)  if (tirpDebug >= 2) then {diag_log ("Tirp INFO  (" + fileName + "): " + MSG );}
    
    #define DEBUG(MSG) if (tirpDebug >= 3) then {diag_log ("Tirp DEBUG ("+  fileName + "): " + MSG );hint ("Tirp DEBUG ("+ fileName+"): " + MSG );}
    #define DEBUG2(MSG) if (tirpDebug >= 3 && DEBUGTHIS ) then {diag_log ("Tirp DEBUG ("+  fileName + "): " + MSG );hint ("Tirp DEBUG ("+ fileName+"): " + MSG );}
    

     

    in script file:

     

    #define fileName "fn_AI.sqf"
    #define DEBUGTHIS true //this line enables extra loggin for this file only
    #include "MACRO.h"

     

    • Like 1
×