Jump to content

tonic-_-

Member
  • Content Count

    726
  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by tonic-_-

  1. At first I thought that was the problem but when I went through my extensive testing I created the vehicle and waited for around a minute and then assigned the variable and it still happened. I stopped reporting stuff on the feedback tracker due to stuff being assigned but never fixed. It may be fixed by now as I have not tested with the last two patches, I'll give it a whirl in a few and see if it's still a problem. Just figured I would post my past experience with setVariable as I make good use of it in most of the stuff I make which is MP-targeted. *Edit* Aha, they actually did fix the issue with the variables. So I guess that tid-bit can be left out although I believe it's still best for the server to just set the variable in case there are any other future hiccups with the network.
  2. The variables are suppose to be transferred to the server but they don't. It was like that in ARMA 2 but with the changes for the 'netcode' in ARMA 3 it does not work like that. As I said I struggled a lot with this in Altis life and constantly had reports of stuff not being set and narrowed it down to variables not being transferred to the server so instead of having the client set the variable I had the server create it instead and never had problems with it again.
  3. Are you setting the variable _unit? That's the only other thing that looks wrong with what you posted.
  4. If you read the wiki on typeOf you would see that you do not need to do str(typeOf _unit) because typeOf returns the units classname as a string already... https://community.bistudio.com/wiki/typeOf
  5. There are weird quirks with setVariable on objects. Variables as KK posted are assigned to the vehicles namespace so if the vehicle does not exist the variables no longer exist and will not broadcast. Another thing to note is that in MP environments which ever client sets the initial variable on an object controls that variable and whether to keep broadcasting it or not. Here is my experience with it over since ARMA 3 Alpha: (Server environment): Client 1 sets a public variable on Car 1 Client 2 connects and is broadcasted the variables attached to Car 1 from Client 1. Client 1 disconnects Client 3 connects but is not aware of the variables on Car 1 because Client 1 left and cannot broadcast that. A proper setting: Client 1 connects Server sets a public variable on Car 1 Client 2 connects and is broadcasted the variables attached to Car 1 from server Client 1 disconnects Client 3 connects and is broadcasted the variables attached to Car 1 from server Basically in short which ever client sets the initial variable on an object and broadcasts it controls its over-all broadcasting capabilities for JIP clients so if a client sets a non-existent variable on an object and makes it public everyone currently connected including the server is made aware of the variable but if the client disconnects the logic for that is lost to future JIP clients but stays current for clients/server that were already made aware of it. Obviously if a server sets the variable initially it will carry a JIP effect because the server obviously never leaves. Also to note it does not matter if a different client changes the already assigned public variable on a object it will still carry that variable to JIP clients even after the client that changed it left. I struggled a lot with this in the beginning because ARMA 3 has changed a lot since ARMA 2. Setting a variable to nil will basically unset the variable because nil as stated is equal to nothing, it's non-existent. As far as variables being set to nil being taken out of memory I suppose the best way to test is to set a variable with a string that will equal lets say 5MB's in size and look at the memory impact and then make that variable nil (unsetting it) and seeing if the memory decreases. The engine its self should not broadcast variables that don't exist but eh, this is ARMA...
  6. tonic-_-

    Blastcore: Phoenix 2

    WAT. Pretty sure he is British. This sounds like a fun game guessing what his nationality is so that we can pinpoint a possible release time. I have done a bit of cocaine to stay up for the release of the glorious Blastcore so hopefully he won't keep us in suspense for to much longer as my heart may give out.
  7. tonic-_-

    Legal violations by A3L: Arma 3 life

    Well then, well played. Good luck with paying taxes on that amount. Given the PayPal fee's that's roughly $89,881.56
  8. I don't see any worth in it, if anything a disadvantage. As you know pre-compiled functions are stored in the memory for faster access times where as with execVM it is reading the contents of that file and compiling it over and over again and temporarily storing it in the memory so if anything by using execVM over spawn on a pre-compiled or non-precompiled function would actually be slower given the read times from the file pointer. At best you are utilizing 100KB of memory. Now last time I checked this is 2014 and not 1985 so 100KB (rough max) should be absolutely no problem at all as far as memory usage goes. What you aim for in coding is performance, not saving small kilobytes of memory when it has no large effect over-all. As said above if using execVM for anything it's for pre-processing stuff (mission initialization) or things that are single-execution only.
  9. tonic-_-

    Blastcore: Phoenix 2

    It's finally happening! OH Boy! Can't wait :D
  10. _choix is a number and not an array, whatever you are storing in control 0896 is not an array, not to mention _details (Control 0902) is not a combo list, it is just a standard RscText type so using lbAdd will not work. What you are probably wanting is below, remove lbClear _details and the code below and replace with simply this: _details ctrlSetText _choix;
  11. tonic-_-

    Petition to Disqualify Epoch Mod from the MANW Contest

    Not saying that I agree with how Epoch was released, I get that people want to ensure a straight forward release and keep revisions the same to limit bug reports and other things but the CRC check does seem a bit over the top but they have the right to do that and it is not an impossible thing to get around, you can still easily modify the code it is just a matter of how much are you willing to put forth into learning. This does not qualify anywhere for them to be disqualified from MANW and honestly this seems way more of a personal attack then actual violations of the MANW rules. If anything the CRC check does not break any laws but voids the actual license making it not usable but licenses them selves are complicated and can only cover so much. As for the accusations of them using other peoples work (InfiSTAR was referenced). InfiSTAR uses code from SpyGlass which is made by me and is licensed under a CC license. InfiSTAR is not a good source of reference given the fact that he is using other peoples work and is selling it, so if you are serious about getting them disqualified then please provide factual information that qualifies them for being disqualified. What is provided so far seems nothing more then a personal attack and your own feelings towards the project as a whole. It is nice to have a healthy opinion on things like this and point out possible wrong doings but the biggest problems with these discussions is the misinformation that is being spread around which prevents proper judgement.
  12. Here is a modified variant of BIS_fnc_numberText which converts a number to a string that avoids scientific notation (4.1142e+008) fn_parseNumber = { private ["_number","_mod","_digots","_digitsCount","_modBase","_numberText"]; _number = [_this,0,0,[0]] call bis_fnc_param; _mod = [_this,1,3,[0]] call bis_fnc_param; _digits = _number call bis_fnc_numberDigits; _digitsCount = count _digits - 1; _modBase = _digitsCount % _mod; _numberText = ""; { _numberText = _numberText + str _x; if ((_foreachindex - _modBase) % (_mod) == 0 && _foreachindex != _digitsCount) then {_numberText = _numberText + "";}; } foreach _digits; _numberText; }; So with this by passing the ID you should get 411426821 returned as a string. i.e _newID = [_id] call fn_parseNumber; //411426821 Obviously when switching in an out of dedicated / server environments you will want to have checks in place to see if the ID exceeds 1 million or not so that way you can avoid any problems.
  13. It is not, it is sent directly to the server via publicVariableServer and then the server checks the conditions and then if it is needed it will tell the clients what to execute, If it is a specific client it uses publicVariableClient. It is a fairly robust system. Also the syntax originally posted is wrong which is why it is not executing but you are better off making it a function as it's not recommended to send code over the network constantly.
  14. tonic-_-

    JiP Setobjecttexture

    The work-around I provided can already do that? When spawning the vehicle in and setting the variable "texture" on it, just store the texture you want.. i.e Vehicle 1: _vehicle setVariable["texture","textures\SL_Offroad_Brit2344.jpg",true]; Vehicle 2: _vehicle setVariable["texture","textures\Other_texture.jpg",true];
  15. tonic-_-

    JiP Setobjecttexture

    setObjectTextureGlobal last I checked was/is a broken command. It breaks the ability to clear out the vehicle's cargo and also removes all variables attached to the vehicle. If nothing serious/critical is being done with the vehicle then by all means setObjectTextureGlobal is recommended. A way to do it without setObjectTextureGlobal which is the same way I've been doing it forever is to store a variable on the vehicle like so: _vehicle setVariable["texture","textures\SL_Offroad_Brit2344.jpg",true]; And then detect if the client is JIP which you can easily do with initPlayerLocal.sqf: if(_this select 1) then { { _texture = _x getVariable["texture",""]; if(_texture != "") then { _x setObjectTexture [0,_texture]; }; } foreach (allMissionObjects "Car"); }; Another way to do it with BIS_fnc_MP which is where you went wrong.. Car_colourblk.sqf (Take note of true, it tells JIP clients to run it. If you are constantly pushing out vehicles though it is not recommended to use this option and better to use the solution above due to network things) _vehicle = _this select 0; [[_vehicle], "set_texturesblk", nil, true] spawn BIS_fnc_MP; set_texturesblk.sqf is wrong, it should be this: _vehicle = _this select 0; _vehicle setObjectTexture [0,"textures\SL_Offroad_Brit2344.jpg"];
  16. One of the very first Coop missions I did back in 2011 was on this map. Personally prefer to have Lingor first but none the less great release and very enjoyable map :D
  17. tonic-_-

    Legal violations by A3L: Arma 3 life

    That sounds like America, if they can't pin you for murder or anything else the IRS (US Tax collector) will surely get you. No matter which way they try to word it, they are not receiving donations as they are providing a service. There is no such thing as "Donate and get faster application processing", that is called a paid service. Now give or take they may have received a few true donations it won't matter for the full amount they have received just out weighs it. If PayPal is "investigating" then PayPal has or will report the income to which ever tax agency is responsible. PayPal does not like getting on the wrong side of tax collectors and in fact with US Citizens if we receive/generate more then $20,000/yr with 200 or more transactions then PayPal automatically reports it to the IRS. I am sure there is a similar thing for EU tax collectors.
  18. tonic-_-

    CH View Distance Script

    postInit is ran in a non-scheduled environment. postInit: //--- Call postInit functions _fnc_scriptname = "postInit"; { { _time = diag_ticktime; [_x,_didJIP] call { private ["_didJIP","_time"]; ["postInit",_this select 1] call (missionnamespace getvariable (_this select 0)) }; ["%1 (%2 ms)",_x,(diag_ticktime - _time) * 1000] call bis_fnc_logFormat; } foreach _x; } foreach _this; preInit: //--- Call preInit functions _fnc_scriptname = "preInit"; { { _time = diag_ticktime; [_x]call { private ["_recompile","_functions_list","_functions_listPreInit","_functions_listPostInit","_functions_listRecompile","_time"]; ["preInit"] call (missionnamespace getvariable (_this select 0)) }; ["%1 (%2 ms)",_x,(diag_ticktime - _time) * 1000] call bis_fnc_logFormat; } foreach _x; } foreach _functions_listPreInit; postInit is called from a scheduled environment->non scheduled environment which can halt because its originally called from a scheduled->nonscheduled (which breaks the scheduled environment). This code is referenced from a3\functions_f\initFunctions.sqf preInit is ran from a scheduled environment but if you halt in it you halt the overall client initialization process.
  19. That is correct. The entire RV-Engine its self was leaked which includes its tools and everything. The only challenge that you have is knowing how to compile everything. The tool that BI uses to "encrypt" pbo->ebo is already out there and it works vice versa. The only thing a person will ever need to make that tool work for the current version of ARMA 3 is the key that is used during the "encryption" process. They changed the key that is floating around out there with the source files back in August I believe it was so it leaves the current key completely useless as the engine will not recognize the ebo pattern (I've tried...) If a tool to convert pbo->ebo was released by bohemia making the actual original tool they use work would be rather easy because digging through a single executable that is only around 230Kb is a lot faster and easier then digging through arma3.exe This will never be a feasible option for the modding community and to even make it "secure" like it is suppose to be would mean a rewrite of the packing method to make their source files that were leaked obsolete. This is not something I ever see Bohemia doing just for the modding community when it's not even a great option to begin with.
  20. tonic-_-

    TAW View Distance Script

    Probably won't end up doing it because lack of interest in arma. When you sync the Object view with the view distance it will dynamically change to the same distance as what you are in i.e in a land vehicle it will be 3000 and a aircraft it will be 5000. The only quirk I noticed with it is the setting in video options Visibility needs to be fairly high for large distances. Seems to be a minor bug with the scripting command.
  21. WHAT?! There goes my hopes and dreams of making money off your beautiful islands! I'm out, peace! (This was obviously a joke do not take it seriously) I'm probably done, I can't really say at this point because I have already burnt myself out on ARMA and do not want to touch it and the current situation going on makes me not want to touch it even more. I have a lot of concepts floating around in my head at the moment but again I am both burnt out and discouraged from even working on them. Who knows though.. I am bipolar so my mood changes a lot.
  22. tonic-_-

    Legal violations by A3L: Arma 3 life

    Makes sense, blame me because without me it wouldn't exist, seems logical. Highly intelligent people over there.
  23. tonic-_-

    Legal violations by A3L: Arma 3 life

    If they wanted to do something with the least amount of "chaos" possible then they would of not skipped out on crucial development time. I've done the research extensively and they have been "in development" for well over a year. I am sorry but if you spend that much time in development then code wise everything should be yours and completely custom. Code its self is the LEAST time consuming part of a mod design such as this. The most time consuming part is models which are also stolen (Irony). The island its self was already built so modifying it and making that work for ARMA 3 should of been at the most 4 months worth of work. I can say all of this from pure experience as I have learned it all for the ARMA series but personally prefer code. Their actions speak clearly for a profitable gain and not much more. I am sure in the very beginning they wanted to build something nice but once time goes on those thoughts and feelings always change when you realize the potential profit gain. This goes especially for the fact that they spent months an months hyping it up to only slack around, it's a classic money grab scheme seen by actual game publishers. In my own opinion I seriously doubt they will move off of my code in particular and I can say that from seeing how they've coded in the past. The way a person codes and then produces something later on speaks for what their capabilities and motives are. I also do not appreciate their constant attempts to discredit me because the only person allowed and able to do that is myself. I have done nothing but give back to the arma community and players and never expected anything in return. Although what I have given back a large majority of the community does not like :butbut: or at least the people that it attracts.
×