gammadust

yes... between (less than 30) and (less than 60) minutes to a requested/setting forecast. think of it like you can only get the engeine to reach your modified parameter at the following in-game daytimes: ... | 12h00 | 12h30 | 13h00 | 13h30 | 14h00 | ... (spaning a full day each 30 minutes) ie. changing the weather at 12h17 will result the change to be reached at 12h30. ie. changing the weather at 13h32 will result the change to be reached at 14h00. use nextWeatherChange to check how many seconds are left for the actual change to occur, after that the engine randomizes the weather once again.

Let me add something. When messing with the weather in search for parameters triggering the rainbow i noticed that the "manual/auto" setting in the advanced intel dialog appeared to have some influence in the responsiveness of settings. I opted ultimately to do my tests setting them all to "manual".

That was his point. But on those cases Bad Benson described it starts to get blurry distinguishing a donation from a payment. Lets separate the issues here too: 1) Player donates (he can't expect anything in return there is no promise of any kind). [No Promises == Donating] 2) Modder makes releases dependant on "donations". He is actually selling! [Promises == Selling] We presently live in 1), and we assume there is no selling even if there is some kind of promising from the modder. It is very blurry and unclear, improving on this would be a step for the better. Defining a system even for donations alone would impose clearing eventual situations such as these, they are rare, as such, not much needed). But it would protect all interested parties. All possible "deceit" falling in this category is either the "donator" responsability to avoid or to denounce in the case of the very transaction be miscaracterized as donation by modder, when in fact is a sell (promise was made). Going forward to some kind of 2) would by definition impose that clarification. PR deceit would be also clearly defined. An idoneous party should mediate the transaction to protect the buyer (escrow). Edit2: (I missed your edit) You rightly made it general, i shall follow. As far as that goes they let their disappointment be known. Either prefered the status quo or their concerns were dismissed (personaly i agree in regards to the steam agreement) I interpret it as method of exerting pressure on who's deciding, not so much on players which will miss such mods and teases (them being used or collateraly affected is a fair point but you have to admit it is their only leverage). So far the exchange is "Mods for Attending our concerns" (fair deal imo depending on concerns being reasonable or not). But then you go into the hipothetical "Mods for Money" (Like in: Our concerns have not been attended, we're willing to mantain the deal if money is exchanged instead), not advancing too much: would there be or not a broken promise? Only the case at hand can tell. I won't judge it in advance. Teasing may be conditional and is not the same as making a clean promise. Nothing wrong with entitlement as long as it consists of something which is rightly owed. The word evolved with undue negative load. There is a trend in labeling with word "Entitled" people which are not entitled to what they claim, but because whatever they claim it is in excess of what they could rightly claim. Not minor observation, do note the perversion of the actual meaning against the common use (read it twice if needed). Now, i do think this is still a valid point, as far as the current state of affairs imply by all practice the assumption mods are freely accessible. We'll have to choose if whatever trade off in the balance actually compensates for this status quo to be diminished or cease altogether (unlikely). Edit: It is not about a "need", it is about the possibility to improve on the present state for us (Players and modders alike). If we reach the conclusion there is nothing to gain, you'll have my neutrality. Or worse, that we can only loose, you'll have my opposing vote. I am not a moderator, if they find this thread more suiting elsewhere, i am sure they'll move it. Maybe a bit at the expense of OP's purpose, for better or worse the discussion took off on this one.

^^ 90% of which on editor and alt-tabbing to notepad :P (648h here - no reset) good to hear :)

^^ this has been said. That improved bridging between Bohemia and the community was suggested here (by [APS]Gnat). I have to say that independently of the issue of this topic, cohese documentation would be advancing the above considerably. The topic at hand could just make it official. In a way i believe there are some steps that would help tremendously the final goal if they were to be conquered in stages. In other words we should "stratify" the ambition "paid user-made content" into smaller more manageable steps.

one order of magnitude later for those...

Just how you put it previously made it look like those mod teams had been incapable of any kind of altruism' date=' which is demonstrated already beyond measure. If they [i']may[/i] have now a prospect of a "Christmas", it would be nothing but late.

_tst is of data type STRING (yes because typeName returns a string), not exacly whatever string you stored earlier. Shouldn't you be verifying the contents of _tN itself in addition? what does _tN contain immediatly before the switch structure? Another possibility: wiki discussion on setVariable. It is an old comment but might still be relevant.

Common guys... i'm trying to stay sceptically optimistic here :butbut: So at best only if by "kickstart" we mean the model (not the platform of the same name) and Bohemia santioned at that. But i do think there is some merit to the idea: Firstly, it is not so ambitious and that demanding as we generally tend to understand as "paid user-made content". It is less likely to stress the concerns beyond possibilities. Secondly, it would provide a sort of escrow service (where the deal is only finalized if modder stated promises are actually fullfiled). This means protection for both parties but mostly the "donator". Thirdly, it would, imo, increase the likelyhood of a player to actually "donate" since it makes more clear what exacly is he receiving in return, ie. "kickstarter goals". This would be an improvement over present donate at will if modder provides means to donate. Unless Bohemia provided the platform itself there wouldn't be much in it for them. Likewise in regards to Valve/Steam. In any case the above would constitute a step forward in regards to alowing for more incentives/commitment in the scene. There is a related issue. Does the modder sell the mod or what exacly does he sell (let's use the strict word here)? An easy way out is following the Full/Lite DLC solution. Requiring a modder to provide both versions would assure that anyone could use the mod and those willing to pay for it would have the benefit of additional goodies (ie. high res textures). This solution requires the modder to differentiate via cosmetic/secondary/usability stuff. And might be hard to implement depending on mod types. But it addresses one of the biggest issues in regards to community fragmentation. Another approach, not mutualy exclusive with the above, is for the modder to sell after-support. Mantains the advantage in regards to fragmentation (limited effectiveness if it means fixing bugs - there it is Curation again helping in preventing prominence of this eventuality). Harder to assure the player of modder keeping his part of the bargain (escrow advantage is neutralized) In any case this is dependent on the modders ability to close up Full versions addons from public scrutiny. (The "free software" freedoms mentioned in earlier post of mine would be only ensured by the Lite version). Or alternatively: Bohemia packing these Full versions themselves.

Just did some tests. Whenever i set setOvercast the requested value is targeted to be reached and "snapped" to the next half-hour / full-hour. Example: setting it at 12h05, the value will be reached in 25 minutes (this is checked with nextWeatherChange, command which appears to be working, yet if before those 25 minutes have passed i request another weather change the time remaining for the change goes above 30 minutes (assumed maximum): second setting at 12h06, the value will be reached in 54 minutes. This second time reset is then subsequently overwriten until the first affected half-hour has passed (ie. 24mins) All these tests and haven't actually correlated the actual value with its visual representation (i assume visually there will always be some discrepancy because weather is not necessarily being generated on top of the player)

"it's like with games that mainly promote grinding and farming of numbers. you will hardly be able to exist in the game, if you just ignore that grinding is the best way to succeed." That is familiar to me... and my GuildWars 2 experience. Such a beautifully made game, so much interesting gameplay complexity to dive into, yet cooperative fullfilment does not scale well with the level of dedication. Making a "system" out of the modding scene no matter how good it is may bring this effect, simply because there might be not enough breathing room to take the relaxed way... "it's like playing bf3 like arma, all slow and realistic, just to be raped by all the high speed coke addict mad men/women who constantly sprint and spray (i play like that and enjoy it just for the record)" That made me rolf!

@PapaRomeo Is the top-left icon showing? As a mod version it should show in any mission existing or editor, if so, it is properly installed. Just press 0-8-1 to bring the menu. in regards to installation and i've just verified from scratch: - Remove any @GAM folder you may have. - Download latest here - Copy @GAM folder only to your main Arma 3 directory - Edit your Arma 3 launch parameters and add "-mod=@GAM" in Steam Library > Arma 3 Properties > Set Launch Options (detailed instuctions) Beyond this, something may be conflicting. Icon present but not working - How? Do you have any mods - Which?

Cloud generation takes a lot of CPU cycles. That expected behaviour is unrealistic. It is a trade off to have such beautiful clouds. MP issues stand and require for the engine to be deterministic which i assume it is (ie. seed value always generates the same weather - engine only needs to sync the corresponding seed) (Edit: I assume wrong)

I disagree in regards to the community having no influence. Crudely speaking BI is indeed a business and i have no doubts there is monetary motivation on their side. Valve likewise but they have much less at stake. This is obvious. At the same time Bohemia is risking considerably if opting to simply ignore the modders stance on the issue. So there is some leverage on the side of modders. If we can't impose an outcome (as you said the decision is BI's), influencing the decision is not outlandish. The more they cater to community's concerns the best chance they have to keep it. Likewise inflexibitlity on our part will only lead to loosing what we have now (the best modding franchise in the industry for the genre). Call this thread a negotiating table (more of a public tuning of community's stance).

i've now tested: x = "x"; tst = switch (x) do {case "x": {"A"}; case "y": {"B"};}; // typeName tst = "STRING" tst = "A" x = ""; tst = switch (x) do {case "x": {"A"}; case "y": {"B"};}; // typeName tst = "BOOL" tst = true x = []; tst = switch (x) do {case "x": {"A"}; case "y": {"B"};}; // typeName tst = "BOOL" tst = true so it looks like somehow your _tN variable is lost on the way or is not found. Since Switch does not fail if no case is found it returns the success of the switch structure instead (i assume)

have you tried: _tst = []; switch (_tN) do { case "x": {_tst = [1,1]}; case "y": {_tst = [2,2]}; }; it is your guess that the Switch type return will be updated to your variable (at least looking at the wiki), Well example 2 supports your syntax but try the above anyway...

@[APS]Gnat that is not too fair. Specially since those teams have contributed with no compensation prospect in mind. Let them have their Christmas, as players we have Christmas all year round. The current "anything goes" does not make the scene too different from this quote: These are pillars of copyleft licensing. (Please ignore any tangential anarchic considerations, it is not the reason i am bringing this) One of the primary concerns (with which i agree with) is how can we maintain the above freedoms if we are to "monetize" the scene? In principle there is nothing incompatible between commercialization and those freedoms. The problem may come only down to the practice and in one extreme example: I am mentioning this not because we should all adopt copyleft licenses, but because this is a type of license that actually helps preserving the cooperative scene. And specially because there is no principled/ethical incompatibility with commercialization. (ie. GNU > Linux > RedHat - which is commercial) This type of licensing is a "mitigating solution" and could be the/a reasonable trade off in order for a modder to commercialize his project. It is opportune to mention the subsequent problem: the likely mushroom explosion of paid for addons if nothing is done to address it. Anyone would try out and milk the cow of course. Without furthering the point too much (i've done it elsewhere), Curation would be increasingly necessary. This would stress our coordination capabilities in finding an effective consensus. Now we still could face problems regarding enforcement of licenses (making sure they are respected). The stepping up of the game on all sides that undoubtfully monetization would again stress this community's coordination capabilities. A dismissive SW report button approach doesn't cut it, in my view, this is likely the biggest weakness.

@Iceman77 i totaly get what you mean. But the same thing is already an issue before any monetization comes into play (i value moral authorship very much). Having said that, users of knowledge and creators of knowledge (never quite a different species in Arma) should hone their modesty skills and exersize common sense when evaluating originality. Usually the deeper and complex the issue the more originality (not a given though). I can't exacly remember what was the function i helped you with, but i shared it in public no strings attached (not necessarily the case of a mod). Also the function was either a pure math concept which i cannot claim any authorship over or an script/engine access which is most probably already public knowledge, and the same applies. But i had the ultimate option to help or not, of course, and your argument stays valid. So authorship in such a modding environment depends mostly on originality of concepts certain mods bring up not exacly the line for line code implementation. Example: Mod uses new math method, new scripting implementation, new engine access method (config), new game content/feature, associative capability to conceive it all together, results in a very high value authorship mod. This is true independently of some section of code being reused and sourced from somewhere else (ie. Wiki), even disregarding different variable naming which never count to originality. The underlying fear here reminds me of freemagenta.nl. Public knowledge is not patentable.

try synchronizeObjectsAdd and synchronizedObjects

It's called "testing the waters". Result: water is cold and salty. Bohemia will have to bring a good effort in warming and sweeten the waters if this idea is to become welcomed. But i'll repeat: we stand a better chance if we help Bohemia know what heat and sugar is made of.

Interpolation methods

i had noticed this early on too, it appears related to paralax, or differences on how it is accounted for in the case of clouds rendering and the rest of the scene. As if there was less precision in one case to another. I suppose RV4 passes distance, direction and (fov or lens length) to the Truesky component, differences in the latter calculation (difference lens properties) could lead to such discrepancy. Edit: i did a lot of panorama stitching, and a thing i remember is that the wider the lens the more compressed would be the pixel resolution/(per spacial angle) at the borders of the frame the further away from lens center it got. If for any reason one had used different lens lengths one would get noticeable resolution differences at the seams. Follow this for an example, notice how the fov/lens length stay the same but the plane of projection is different.

look into addAction and removeAction and

It does not have to but it is very likely to... Imagine all of us in this thread can make an addition operation. Imagine we want to know the sum of all members posts since they joined. Each of us knows the amount of posts to add. Problem: how can we reach the actual sum of all if we each make the addition operation simultaneously? We can't. Each of us MUST add and communicate our sub-total IN SEQUENCE to the next guy so that we can reach a final result. (Note the sequence order is irrelevant in this example) Now arma and many other games are composed of interdependent systems (each poster), the breath and complexity of which will allow, or not, to reach results simultaneously. Arma and simulators generaly, focus on fidelity to reality, shortcuts are not an option in many cases. Optimization in these cases is finding in the sub-systems' calculations (orders of complexity higher than simple addition), opportunities to communicate stable information to the next dependent sub-system. When you get 20% usage (whole of a number of cores) just means that there are sub-systems waiting for each other to provide information to act uppon, while not having any other option to proceed with own calculations.

Opt-in to dev branch (> steam game properties) or wait until it is in main branch. Ninja'ed