gammadust

looking good fabrizio :)

I can't login to the tracker, anybody else?

... Removing the need for the Dynamic Texturing script altogether, this being via facilities engine should have available right now: I insisted on this idea and i'll attempt at driving the point home more. Hopefully Dwarden is still keeping his eyes on this, there might be some feasible avenue for tackling our pet texture issues with no huge engine implementation requirements. Gallery with variations of a scene showing texturing | Full Detail / "half" Detail / noDetail | for assumed current blending modes, suggested blending modes, and it's ultimate aim by using the suggestions. Images are fully aligned for easy comparison. Basically i am suggesting 2 things: Adjust the blending transition to maintain it's 50%* level for a longer distance (might be relatively easy to implement) *or another percentage value where visual effect is more useful Adjust blending to increase constrast when Surface texture and Detail Map are mixed Overal saturation and luminosity emerges as an issue in extreme cases (probably due to my lack of representing in-game post-processing or missing the actual blend values), but that should not be an issue i believe. In any case i shall make a ticket out of this study. Edit: Can't login to tracker, i'll create the ticket when able.

Well i think technically it is possible, some stuff has been done to that effect, but even if automated (identifying limits of such places), would burden the engine significantly to be applied to whole map... Comparison Gallery: (click for 9 sets of images) * Note 1 - in some places, those extending further away from POV will have a repeating satellite image (ie. not corresponding with original satellite) * Note 2 - Only dry grass is a custom texture (yellowish), the rest are vanilla

I am very pleased with it too, this attempt at deriving an acceptable compromise of paramaters out of the topography of the terrain and the vision center, while removing the jitter. With the ultimate objective of having all 3 levels of textures always contributing some information towards the final render (at least where our vision is mostly focused)... I have to wonder if a much more stable* and direct texture level combination wouldn't be possible without any kind of dependence on fov and eye direction. Currently Satellite *multiplies* Mid Range, and apparently Mid Range is merely combined with Close Range via *transparency*, i imagine instead this latter combination be done via a multiply, this turn made with the luminance channel instead of the color one (which comes mainly from the satellite). This would assumingly contribute to break the patterning** of the close range while not getting rid of its detail (which is where most of it happens). * in terms of the blend parameters ** most of the time coming from the luminance repetition (not the color or high frequency contrasts) I already did, i even identified the place of the patch you had focused on in the performance test pbo, but unfortunately the (v?)ram cap is hit and the resolution falls back down the next mip, defeating the purpose, i was never able to get a hold of it up to the moment i started recording. I am sure it would even get better, since the tinting blobs as per default would drop down to a quarter of its size. I'll try to screen shot one or two while it lasts. Another thing i noticed when trying this out in Altis instead was that current parameters are not as effective, since now it is the detail of the surface type (and the binary nature thereof as present in the terrain class map) which leads to random patches spread out over a base surface texture, both of which very detailed but with noticeable diferences in color... (i'll try and get some screen shots or just go to altis and try to look for what i mean)

i totally missed the original issue in the op. :butbut: (i assumed it was the same issue has in the ticket) The desync has happened to me too, only when i accelerate the in-game time too much, it even gets more broken when making time go backwards, even if done in smaller time steps than a single big one... :j: The light strength of the sun, since it's global, appears to average out the island cloud coverage, which may be the reason for the desyncs in some areas of the map (just speculation). Adjusting the time appears to mess with the cloud generation, by not leaving room for the engine to adapt and update sun light strength values. I think the desync issue should earn it's own ticket, and not be mixed with the setOvercast misterious unresponsiveness. I don't know of any workaround to force it's syncing, but to prevent it from happening. Edit: just tested out your repro. Confirmed, same symptom i got when advancing time too fast. also noticed the actual overcast after the radio trigger was > 0.737773 and updating nextWeatherChange was reading ~23minutes to go (don't trust it too much this command, i find it not too reliable) try not skipping the time the full 24 hours but a value between 23.5 and 23.59 (give a 30-60 minutes headroom for the engine do it's thing), alternatively when {skipTime -24} use 24.5 instead. Edit 2: i changed your A trigger execute to: hint "Overcast 1"; skipTime -0.55; 0 setOvercast 1; // used 0.55 to fallback a little before 11h30, since mission is configured for sharp noon and added a B trigger with: skipTime 1.5; // results in cloud coverage - had to move code to another trigger since the engine appears to require a small delay before reseting the time back after setOvercast command usage - had to advance a full hour (in relation to the initial mission time) to observe cloud coverage and have light strength synced, other values (0.5 and 1.0 for skiptime did not cut it). i always use 0 setOvercast x (since "Zero time means immediate change" - wiki, yet the earliest i got was 30 minutes, i assume "0" will translate to "as fast as the engine can", hence my insistence on the 30 minutes steps)

Thanks for your kind words guys :) Until then, i'll try and provide more detailed instructions in regards to using the custom close range texture, or finally when i have a full set of custom surface textures i may provide the direct download and the +200Mb becomes worthwhile. *UPDATE* Script updated: - moved it from init.sqf and added option to a side script. - script does not use onEachFrame in order not to interfere with whatever mission uses it for other purposes - code clean up and added some comments to allow easier customization - significantly improved the smoothing of the transition (there are some very fringe cases where it still fails though) Video: OP Updated

^^ nope. check the wiki again... :) "...for each recognized target" (by the unit), because of this i would loop always adding the found enemies to a custom array per group so that you don't delete an enemy not seen by one member but seen from another. "Lot of trial and error incoming" ... it comes around a lot when dealing with AI.

spawning happens in-game, not in editor... you should then look at config editing and specifically CfgVehicles class.

createUnit will achieve that. Look in Category:Scripting Commands Arma 3 list for commands you may need. *note the scripting language in armaverse is SQF not PHP. (if you got that idea from the forum tags... ignore them, it is just a formating tag)

I have tought of this approach too, but did not have too much hope for it, mainly because in more general situations it is too disruptive (one would need to save all the unit's current state before deletion and restore it back - and i am not sure we have all the commands necessary to achieve full fidelity to original state). In any case i haven't experimented with it. You can use nearTargets command to check for enemies (it will return an array which includes friendly/other units which you need to filter out). Don't forget to check for line of sight (the command does not distinguish those in from out) Let us know of your success...

Yes... just put the script directly in the init.sqf of a mission. The only limitation is in regards to the custom close range texture which must overwrite the original ones. It must be repacked into a pbo along with the remaining default textures. Unfortunately there is no better way that i know of to make this texture replacement mod without all this hassle (afaik).

Updating with some possibilities: Mid Range detail map, same as previous but using the 2nd less pattern prone option (gam_stratis_midrangedetail_a2.pbo) New customized close range texture for dry grass, removes patterning effect if used at high distances with default Unable to easily share this texture as a mod which implies uploading the full set of surface textures (+200Mb), you can only observe it's effect in the video. *** @Bohemia *** an appeal to allow modders to update that surface textures via config (override cfgSurfaces config without the need to repack all textures from map_data.pbo) A custom script which dynamicaly updates the transition between Mid and Close range textures on the fly (dependent on Field of View) - uses new setDetailMapBlendPars command Video: ***warning lengthy video*** bare with me on some comments regarding texturing from the beggining or skip to 6m35 to go straight to the meat of it Textures: download (dry grass for Stratis and Altis) To install them, you must unpack original map_data.pbo to a folder, extract these textures from zip and overwrite the original ones, finally repack it all up again and put it in one mod folder. Script: (still very experimental)

I'm interested in helping fabrizio, if you still need more testers... :)

Elsewhere i noted that the weather change appears to always land on half hours or full hours (which implies a maximum of 59.99minutes wait from the time setOvercast is used). I never bumped into 90 minutes waits unless i mess something up.

^^ you can try to get inspiration from this function: /* Simple Day Weather Cycle by gamma Description: - Allows setting a overcast forecast for each half hour of the day - Repeats forecast each day - May break with time acceleration - Initial startup may imply waiting for more than half hour* for first overcast set (works as expected after that) * If mission is set to start at 16h15 minutes it will only set the overcast at 17h00 (wait of 45 mins) ********************************* **** LICENSE CC BY-NC-SA 3.0 **** Creative Commons Attribution-Non-Commercial-Share Alike 3.0 License */ GAM_DayWeatherCycle = [] spawn { // LUT with forecasts for each half hour (starts at midnight) // 1) example: cycles between full overcast and clear each halfhour //_halfHourForecast = [1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1, 0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0]; // 2) example: weather transitions _halfHourForecast = [1,1,0.9,1,0.8,0.7,0.5,0.66,0.33,0,0,0,0.5,0.65,0.7 5,0.85,0.95,1,0.75,0.85,1,0.9,0.95,1,1,0.75,1,0.95 ,0.8,0.7,0.6,0.4,0.5,0.2,0,0.1,0.2,0,0.1,0.25,0.33 ,0.5,0.66,0.45,0.33,0.25,0.5,0.5]; while {true} do { _daytime = (round(daytime * 2)) / 2; // round daytime to each halfhour _nextchange = (_daytime + 0.5); // next half hour _cycle = (_daytime * 2) % 48; // current cycle (48 cycles a day) _setOvercast = (_halfHourForecast select _cycle); // select overcast from LUT 0 setOvercast _setOvercast; GAM_hintDebugText = format [" (cycle %1)\nDaytime: %2\nOvercast: %3%4", _cycle, _nextchange, _setOvercast * 100, "%"]; // debug waitUntil {daytime >= (_nextchange - (1 / 60) )}; // wait for minute 29 or 59 before looping (otherwise engine calculates new value for next hour instead of half hour) }; }; GAM_hintDebug = [] spawn { // show debugging info while {true} do { _daytime = (round(daytime * 10)) / 10; hintSilent format ["Current\nDaytime: %1h\nOvercast: %2%3\n\nForecast%4\n\nTime left: %5m", _daytime, round(overcast * 100), "%", GAM_hintDebugText, round((nextWeatherChange / 60) * 10) / 10]; sleep 0.25; }; };

The thing is they have, currently the engine does: Satellite Overlay Texture (High Range) > Low resolution (1024px/~1000m) Unique Texture per Sector > Seen at maximum opacity over below textures from 1000m Detail Texture (Mid Range) > Medium Resolution (1024px/~40m) Tiled Texture per Terrain > Seen at maximum opacity over close range from 0m Surface Texture (Close Range) > High Resolution (2048px/~2m) Tiled Texture per Surface type > Seen up to 1000m (typical is much lower - 40m?) Sattellite is always overlayed and tints both the Mid Range and Close range. Detail texture inherits color from sattellite but is tiled, hence prone to pattern effect. Surface texture also inherits color from sattellite but is much more likely to create the dreadful pattern effect, only mitigated by the fact that it employs exacly the method originally suggested in the OP, despite at a different scale, which diversifies the seams. Bohemia provided the command (setDetailMapBlendPars) that, by extending the surface texturing up to 1000 meters, allows us to see for ourselves that merely rendering a specific texture by surface type is not sufficient to obtain a good silluette breaking effect, and comes with the unwelcome side effect of horrific patterning at medium/long distances. This workaround of NordKindchen works because it does manually at the Sattellite texture level what is done by the engine at the close range and for this reason is able to circumvent the patterning effect. Suggestion to Bohemia:

^^ like in what's the point of dedicating so much one's free time into a feature while other required features for one's fullfilment are not in. Only NordKindchen can evaluate to what extent his effort will be rewarding to himself or not, only him is able to remove any obstacle. Hopefully Blastcore 3 can convince him.

Have you any idea of the absolutely insane amount of repetitive image editing is on NordKindchen's table? Those are hundreds of images for Stratis, nevermind Altis. Keep your fingers crossed indeed so that he manages to find the time to do it. And be thankful that he finds it worth it to whatever he expects from A3 enjoyment in return. Calibrate your expectations to reality first, april joke later.

If so, it makes sense, beyond that distance the implied downsampling of the close detail resolution should make no difference. Still, that command looks very promising. Many thanks devs.

Nah... the PR distortion fetish remains:

delete nvm... i am missing some syntax here.

2 things: While {True} Do { While {{alive _x} count crew v1 == 0} Do // {alive _x} is not inside a forEach structure > _x is unknown // count crew v1 == 0 would recommend adding () > count (crew v1) == 0 // if you are checking for 2 distinct conditions use AND // the following should work instead // While {(alive _unittocheck) AND (count (crew v1) == 0)} Do { Player Sidechat "inner"; Sleep 30; // I actually want this to halt aswell and exit the loop, if in the middle of this sleep Hint "I don't want to see this if the crew is above 0 ... wtf!"; }; Player Sidechat "outter"; Sleep 10; };

That is a custom function and you should look into its code. Either follow _poss variable usage in it's original context, check for script comments, or try to derive it's meaning by what is done with "_this select 4" in the body of the function. As a last resort contact it's author.

try using currentCommand to check if a unit is asking for support. Alternatively, and probably more efficient, check if any support vehicle/unit has a "HEAL","REPAIR","REFUEL","REARM" order under way, and hold deletion if that is the case. (This is not tested, but i do know inner group heal requests can be detected this way)