Jump to content

Recommended Posts

Test Example Mission for v1.1 available via dropbox at  https://www.dropbox.com/s/xf6x34963ixjue0/camouflagescript.Altis.zip?dl=0   I will update this mission with new script versions as they develop and put the link in the first post.

Watch camo level change on stance change. Two BLUFOR beside you have no camo set. Try just crouching and watch OPFOR search, spot and kill your prone mates usually long before they spot you crouching in same place. Make sure to set User1 keys to x and z as instructed above before playing or it wont work.

Edit: I should point out that the effect is intentionally quite strong in this test example, in an actual mission I envisage squashing the range of the combined factor so that the effect is a little more subtle.

  • Like 2

Share this post


Link to post
Share on other sites

DynamicCamo new Version 1.2 - read first post. Now includes much better handling of light level for dawn and dusk and takes account of the proper sunset and sunrise time for the date, with dawn and dusk fading of light factor starting one hour before sunrise/sunset and ending one hour after. Lightlevel can be rescaled. Next version will make specifc calculation for audibleCoef then trees and bushes near player.

  • Like 2

Share this post


Link to post
Share on other sites

I'm going to! My next step is a specific audibleCoef that gives proper weighting to the following factors - Fog ( strong impact on audibleCoef ) , Overcast ( moderate impact I think), Rain- (should have most impact), Stance - (moderate impact?), Uniform - (no impact) , Trees/ bushes (when I do them) - (moderate to strong impact), lightlevel - no impact or possibly more impact day v night)  Edit- and wind, I forgot about wind.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

DynamicCamo new Version 1.3 - script updated  in first post.  AudibleCoef now has its own specific calculation using its own specific factors as indicated in an earlier post.

  • Like 1

Share this post


Link to post
Share on other sites

I had noticed a while back that if player goes prone then stands quickly the prone camo level is retained until next stance change. Same with a bob to crouch then stand. This is not desired behaviour. I want soldier to be able to bob up and keep the camo level but only for a short period of say a few seconds.

I have now fixed this. Script will now run every five seconds and force update if there hasn't been a stance change to force one. So you'll get a camo update every five seconds or when you change stance. Ill include this in the next version.

Share this post


Link to post
Share on other sites

Im testing my bush, tree and "Hide"** objects factor now. 

Im picking up bushes no problems with neareastTerrainObjects in 2 m radius but its not picking up trees at all well.  I get the odd detection but it fails to pick up most trees in that radius.

Im using players pos as the search position - is it possible that nearestTerrainObject detects objects from their centre point and that trees have a higher centre point so aren't getting picked up?

That's the only thing I can think of given that I can detect trees when using a wider radius of say 20m. Any ideas on this? I'm going to test adding say a metre to the search postion z height and see if that sorts it.

**Many rocks seem to be defined as "hide" objects.

Share this post


Link to post
Share on other sites

Thanks, I hadn't seen that before!  Interesting and Ill look at it further. It seems to cover a smaller number of factors compared to mine and doesn't impact Audible Coef . But he obviously has a working approach to the terrain issue - im wondering if its a higher level test like testing for forest rather than an immediate area test for trees bushes etc.  I'm still hoping I can crack picking up trees adjacent to the player because otherwise Ill have to go for a broader terrain type approach I suppose.  Thanks for the link to that.

Share this post


Link to post
Share on other sites

I hope to eventually General Kong, while the script is now fully working ( and gives great camo in situations where it should) Im still very much in development and adding features and I want to wait a bit until Ive cracked all the major factors I want to include. If I can keep up my present pace that shouldnt be too long hopefully.

My next version will have a selectable debug mode which will print to screen various factors ie the calculated coefficients, number of bushes etc. and Ill put up a better test  scenario.

Im also considering how best to let users readjust impact of various factors to their own tastes as well as having the out of the box working version. Im thinking of parameterising the ranges set by the linearconversions so that the user supplies these in an array when calling the script to save user having to search through the script to adjust weights. 

Share this post


Link to post
Share on other sites
2 hours ago, The Real Bunc said:

Im is it possible that nearestTerrainObject detects objects from their centre point and that trees have a higher centre point so aren't getting picked up?

 

1

Yes, that's exactly what's happening. If you do the search in 2d mode, you will detect the trees more reliably.

However, because the class system in nearestTerrainObjects is weird, be aware that if you using 2d mode, you might pick up unexpected objects. Using "Power Lines" in the types array with 2d will find overhead powerlines, even though they are way above you.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

That's great Tankbuster. I'd wondered if the default 3D search might be the problem as well. I'll try 2d and maybe that will be enough to sort it. Edit  - It was. That saved me a lot of pi**ing about. Thanks TL!

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, Tankbuster said:

If you do the search in 2d mode

Tankbuster , what's the second mode ?

I really haven't understand , anywhere to read about ?

Share this post


Link to post
Share on other sites

Nearestterrainobjects does either a 3 dimensional search or a two dimensional search. I think of the latter as a map search.  It defaults to 3 dimensional search hence why I wasn't finding a near tree. 2d sorted it. 

  • Like 1

Share this post


Link to post
Share on other sites

Gotta hand it to you Bunc,this is great.Just used it in a cpl missions which enabled me to sneak into a camp,plant two bounding mines,steal some ammo then sneak-out-undetected then another had a UGV  roll right by me along with a foot patrol who were hunting me.Got the feeling they knew I was near but didn't know where.Congrats!

  • Like 1

Share this post


Link to post
Share on other sites

DynamicCamo v1.4 Please read first post. - 

 1)  Periodic auto recalc now means Soldier can now keep prone camo level for max of 5 seconds when bobbing down to prone then quickly up, or down to crouch then quickly back up.

 

2) Systemchat shows calculated values for debugging and tuning.

 

3) call to Spawn script now includes DEBUG switch to turn on information (see 2)  

ie cam= [this,"DEBUG"] spawn compile preprocessfile "camoscript.sqf" turns on DEBUG info. Replace Debug with empty string to turn off.

 

4)Sleep adjusted to 2 for better responsiveness.

 

5) Added camo factor for bushes, Trees and "hide" objects within 2.5 m radius of player. Typically there are between zero and three max found such objects in this sort of radius from quick testing on altis. 

    An additional factor representing this is now included in the calculation and influences the calculated camouflageCoef value . No impact of this on audibleCoef at this point as I feel its debateable whether this should make soldier more or less likely to be heard. ( breaking twigs and rustling )

 

6) as previously, adding additional factors like Trees/bushes beside soldier means me making some adjustments to the weighting given to other factors sometimes. I have done some first runs through with the values I've scripted at this point for the trees/bushes factor but this may need some tweaking. The overall impact on camouflageCoef will be that even lower values are being produced. This may mean the final linear conversion needs to be tweaked a little. 

 

7) my thoughts on handling uniforms has progressed. I have identified an initial and very simple method to do a first integration of something like that.  Its likely to mean I can give different uniformcamo factor values depending on if unit is a) civi b) soldier wearing ordinary uniform c) soldier wearing ghillie. More soon if all goes well. I haven't yet upgraded the accompanying test scenario. Ill try to do that soon. (Done)

 

Anyway please try this out and let me know any thoughts.
 

Edit; Oh, I think ive also figured a terrain factor adjustment method as well that looks quite straightforward. this means I could adjust the impact of the trees and bushes found adjacent to the player depending on the terrain they are in. So, for example, being beside a bush in a forest would make you harder to spot than beside a bush in a field and youd get a little extra dynamic camo from being in a field compared to in a town.

  • Like 3

Share this post


Link to post
Share on other sites

DynamicCamo v1.5 release. see first post 

Ok , bit of a delay due to real life intervening in my fun but here is my next version of DynamicCamo with some significant changes. ( New test scenario to follow)

 

1) DynamicCamo works between ai. Ai will have impaired visual and auditory detection of any ai unit on which the script is running. AI are impacted by same environmental and other factors as player is. Recalc for ai is not triggered by stance change but by autocalc frequency ( autodelay) Ai with the script running can have their own frequency for script update set using autodelay. supplied in the spawn argument.

 

2) DynamicCamo will now pick up different types of uniform and adjust camo values accordingly.  At this time Ghillie suits, sniper suits and viper suits give most camo. Uniforms designated combat or Officer or CTRG in their class names get less camo and anything else doesn't grant any uniform camo ( but all other camo factors apply)

 

3) DynamicCamo now allows easy adjustment of the Camo impact using arguments when spawning the script.

The spawn now uses arguments as follows when called

 

camo =  [this,"DEBUG", _cLo, _cHi , aLo, _aHi] spawn compile preprocessfile "camoscript.sqf"

 

"DEBUG" - Info/debug switch. Empty string to switch off.

_cLo  - set the bottom limit. Values above zero reduce the effect Default zero.

_cHi  - set the top limit for visibility. Values below 1 ensure unit always will always have camo impact. Default 1.

So for example  setting _cLo to 1 and _cHi to 1 would effectively turn the effect off, setting both to zero would make the unit always invisible.

Default values give the DynamicCamo the maxium influence. You can squeeze that influence into a desired range by use of _cLo and _cHi.

The same logic applies to _aLo and _aHi.

 

EDIT - Test scenario updated. Try crossing the fields and evading the patrols.

 

 

 

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
On 5/5/2019 at 1:41 AM, Tankbuster said:

Does it work as expected in multiplayer?

 

On 5/5/2019 at 4:51 AM, The Real Bunc said:

I've only ever scripted for SP so I can't really say re MP.

Heres one for you, how about teamswitch, if the player changes to a new unit, will the script take into account that the player has changed to another unit?

  • Like 1

Share this post


Link to post
Share on other sites

Gunter - re team switch - no it wouldn't because the script runs on a specified unit. I think if the unit you were switching to had the script already running or if the script could be started on the unit you've switched to when you team switch that would work. If you switch out of your unit my understanding is that the code will continue to run on your original unit and wouldstill be running when you go back to it. I think. I'll need to test that though.

 

(what I am going to do next is have a switch in the spawn arguments which allows you to select if the script is to run on just the individual unit or all members of its group. But that's different from your team switch question of course)

Share this post


Link to post
Share on other sites
45 minutes ago, The Real Bunc said:

If you switch out of your unit my understanding is that the code will continue to run on your original unit and wouldstill be running when you go back to it.

I was thinking in terms of when you died in a mission that you would teamswitch to the next available unit, thats how i normally play.

 

In my recent mission i posted May 4th, linked in my sig, i have it setup where you have 4 players, one whom you are the main player, when you die, then you teamswitch to the next player.

57 minutes ago, The Real Bunc said:

if the script could be started on the unit you've switched to when you team switch that would work.

An idea came to mind would be instead of just running on the player specifically, you could have a code that would encompass those players you define in an array.

So [ "player1", "player2", "player3"];

So as i quoted you, have the script already running on defined players, that way when the starting player dies, then switching to the player(unit) of choice would also have the script running.

 

Another idea for your script here is to create an editor module, kinda of like what Rydygier did on our project with HAS (linked in my sig)

basically the module is placed, and you sync the players, or units that you want to have the Dynamic camo, to the module, you would then open the module, and you can have a list of

various settings based on what you want to accomplish.

 

 

Share this post


Link to post
Share on other sites

Hi Gunter, yes I see what you mean. One of the things I want to check is how the script cleans up on unit death. You'll notice the main loop tests player alive. I have been wondering if that really should be testing unit alive i.e. the passed unit.

the idea of having an array of units on whom the script is run is also interesting and I'd like to think about that further.  

My own view was that it might be most efficient to destroy a script instance for a unit on that units death and where there's another unit simply to set an instance of the script running on that unit when required. But I need to think about your array suggestion.  I'm pretty sure the units and it's group can share one instance of the script ( once I make some modifications.). 

 

Another thing ive considered is that some of the checks eg fog level , overcast don't change too quickly and more importantly are the same for each unit using an instance of the script. This suggests to me I could externalise those bits and simply supply up to date measures for all instances of the script rather than each running its own checks.

 

What you are suggesting makes makes me think I need a layer of control that sits on top of/ outside the script itself and which controls termination and starting of script instances and keeps track of them. I'm wondering if that might also help with MP because my notion was that server owner should be able to define key parameters e.g. Setting the limits on the strength of the effect.  So server could broadcast the array with parameters but local machine would run instance of the script for player, with server running it if it was set for any ai. I'm in early stages of thinking about this stuff but I'm trying to make sure anything I design in now makes sense further down the line re MP.

 

oh and I'm considering offering a choice re the method to calculate the final factors. At present I'm using a sqrt of products. I'm thinking of offering a switch to other method(s) e.g. Average, geometric mean or some other function. 

 

much still to think about. All comments most welcome and appreciated.

  • Like 1

Share this post


Link to post
Share on other sites

@GunterSeverloh

On ‎5‎/‎17‎/‎2019 at 6:25 PM, Gunter Severloh said:

I was thinking in terms of when you died in a mission that you would teamswitch to the next available unit, thats how i normally play.

 

In my recent mission i posted May 4th, linked in my sig, i have it setup where you have 4 players, one whom you are the main player, when you die, then you teamswitch to the next player.

An idea came to mind would be instead of just running on the player specifically, you could have a code that would encompass those players you define in an array.

So [ "player1", "player2", "player3"];

So as i quoted you, have the script already running on defined players, that way when the starting player dies, then switching to the player(unit) of choice would also have the script running.

 

 

I tested Team Switch.  With each playable unit running the script the player simply gets the camo for the unit they are switched to and other ai with script running just continue running their scripts. That seems OK to me.  I tested sending <player> directly to the script rather than <this> to see if the calculation would "follow the player" through a teamswitch but it doesn't work that way. 

 

Given that then my next development I think will be to provide the option to run the script on a) single unit b) group c) passed array ( which I suppose could include groups though ill regret suggesting that when I have to code it I suspect)

 

On ‎5‎/‎17‎/‎2019 at 6:25 PM, Gunter Severloh said:

Another idea for your script here is to create an editor module, kinda of like what Rydygier did on our project with HAS (linked in my sig)

basically the module is placed, and you sync the players, or units that you want to have the Dynamic camo, to the module, you would then open the module, and you can have a list of

various settings based on what you want to accomplish.

 That would be great. I haven't done that before but I have looked at the *cough* documentation. I would be in serious need of some hand holding through that process I suspect. 

 

Share this post


Link to post
Share on other sites
10 hours ago, The Real Bunc said:

I tested Team Switch.  With each playable unit running the script the player simply gets the camo for the unit they are switched to and other ai with script running just continue running their scripts. That seems OK to me.

Ya agree, sounds like it can work, nice job.

10 hours ago, The Real Bunc said:

I would be in serious need of some hand holding through that process I suspect. 

About the only thing i can suggest for that if you do want to go that route, is maybe either PM Rydygier, Vonquest, Drongo, theres others,

all these members have created editor modules, im sure one of them could give you some insights on how to get going on it.

Hope that helps.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×