Night time or day time

[CarlGustaffa 4]

Hi

Does anyone know how the engine handles daytime? I mean, daytime changes throughout the year, but how does AI know when to use NVGoggles or not?

I.e. at January, daytime may start at 0800 while in July in may start at 0500. How can I use a check like this in a script, getting the same results as the engine would use?

[Toasted Duckie 0]

I believe AI uses their NVgoggles when it's dark only, so if AI is in nighttime on January at 20:00 it carries NVG's whilst when in daytime on July at 20:00 it doesn't have NVG equipped (as it's still daytime).

I'm not sure about this though, but you could test it out real quick, equip a AI guy with a NVG, go to preview. Then change the date to where it's still light and check it again...

[CarlGustaffa 4]

Well, yes, but how does the engine *know* it's dark?

Came to think of it, I made such a function for an aircraft panel I made for flightsim 9. Yes, I had help Now, this one is a bit too advanced because it takes so much extra stuff into the equation that is not needed for ArmA, such as plane altitude, size of earth, apparent refraction, and place on earth. Used this to automatically turn night lighting mode on some of the instruments that have a light sensor in real life.

I'll check if I can dig it up.

[suma 8]

Well, do this in engine is not as difficult as it would be for a mod. In engine I have access to all lighting variables and computations. Here is the actual code snippet showing the AI NVG decision:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">      Person *person = GetPerson();

     if (person->IsNVEnabled())

     {

       const LightSun *sun = GScene->MainLight();

       // check light intensity

       float dark = 1.02f-(sun->GetAmbient().Brightness()+sun->GetDiffuse().Brightness())*3;

       // randomize based on unit ID. apply unit skill

       float thold = 0.5f + ID()*0.02f - GetAbility(AKGeneral)*0.2f;

       saturate(thold,0.3f,0.7f);

       person->SetNVWanted(dark>thold);

     }

[CarlGustaffa 4]

Well, since you showed me yours I'll show you mine, lol

The "only" thing this doesn't handle is the planes attitude and shadowing caused by cocpit internals etc. But it did work anywhere on the world afaik. Written in rpn based language. I'm now quite sure how to port this into ArmA, since many variables are lacking or not used. Maybe a sine curve of amplitude 3 hours or so would suffice?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

// calculate sunangle for autodimming purposes. Thanks Arne for your help on this one. Holy moly!!

// explanation of the terms used:

// A:Variables are airplane variables

// P:Variables are global environment variables

// L:Variables are local writeable variables

// rddg is a radians to degrees converter function

// (>L:Variable) is current stacked value stored here

// zulutime+longitude/15

     (P:ZULU TIME,hours) (A:PLANE LONGITUDE, degrees) 15 / +

// (7.3*sin((dayofyear-3)/365.25*360)

     (P:ZULU DAY OF YEAR,number) 3 - 365.25 / 2.0 pi * * sin 7.3 *

// -9.8*sin((dayofyear-80)/365.25*720))

     (P:ZULU DAY OF YEAR,number) 80 - 365.25 / 4.0 pi * * sin -9.8

     *

     + 60 / - (>L:local_sun_time,number)

// declination is the sun height over equator

     (P:ZULU DAY OF YEAR,number) 80 - 365.25 / 2.0 pi * * sin

     23.45 * dgrd (>L:declin,number)

// sin(sunelev)=sin(decl)*sin(lat)+cos(decl)*cos(lat)*cos(localsuntime-12h)

// sin(decl)*sin(lat)

     (L:declin,number) sin (A:PLANE LATITUDE, radians) sin  *

// cos(decl)*cos(lat)

     (L:declin,number) cos (A:PLANE LATITUDE, radians) cos  *

// cos(localsuntime-12h) localsuntime-12h aka "hour angle" or "right ascension" of the sun

     (L:local_sun_time,number) 12 - 24.0 / 2.0 pi * * cos *  

     + asin rddg

// curvature of the earth effect cos(lowered horizon)=1/(1+height/earth_radius)

     1.0 (A:PLANE ALTITUDE,km) 6370 / 1 + / acos rddg +

// apparent atmospheric refraction effect

     0.833 +

     (>L:local_sun_angle,number)

I guess a simple G:Brightness would have helped here Btw, I had help with code, and I have no clues as to what is going on in here. I just rewrote it to suit flight sim.

My intent is whether AI will use illumination based artillery or not.

[CarlGustaffa 4]

Hmm, is there a good way to get the daynumber of the year? It should be able to handle the ArmA leap years if possible.

[dmarkwick 261]

Possible to drive it based on the sun's position? Assuming the sun is even an identifiable object.

[CarlGustaffa 4]

The other way, calculate daytime  based on calculated _day_of_year and dayTime to create minutes or seconds into the year, cheating with simple sine curves based on experiments

Some testing has given me this for finding day of year. Not sure it is the best way to do it, but it avoids counting and loops:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_year = date select 0;

_month = date select 1;

_day = date select 2;

_leapyear = [0,1,0,0,0,1,0,0,0,1,0,0,0,1,0];

_feb = 28 + (_leapyear select (_year - 1995)); //1995 is first year in ArmA, 1996 is first leap year, included in ArmA

_dayinyearselection = [0, 31, 31, 62, 92, 123, 153, 184, 215, 245, 276, 306]; //looks weird, but febuary and current day added below

_dayofyear = if (_month <= 2) then {_day + (_dayinyearselection select (_month-1))} else {_day + _feb + (_dayinyearselection select (_month-1))};

_daysthisyear = if(_leapyear select (_year - 1995) == 0) then {365} else {366};

hint format ["days this year: %1\nday of year: %2\nfeb has: %3",_daysthisyear,_dayofyear,_feb];

Just found a bug in ArmA too now, thought it was in my own code. Turns out that the command "date" doesn't handle 31th of December in leap years (2000,2004) very good, but instead returns day 1.

[CarlGustaffa 4]

Well, I made this function that should determine if it is daylight available. It can't be as accurate as Suma's brightness based version since I don't have access to that variable.

Note that the leap year thingy is a little buggy in ArmA, and I'm not sure how the function will respond to that change, but I think it should use a result similar to what it would be the next day - which shouldn't even be noticeable.

A couple of words about the variables:

_baserise and _baseset is approximately when AI will toggle their NVGoggles at 1st of January.

_factrise and _factset is the maximum hourly difference of the base variables when comparing 1st of January with 1st of July.

_dayinyearselection looks very odd, but I think it should be correct. The current day and feburary days are added in later on, hence january has 0, and feburary and march are equal.

_normyear is a normalized year in minutes scaled to 0-360, allowing use of sin and cos.

You can precompile the function with this line i.e. in init.sqf:

fn_isDay = compile preprocessFile "bat\func_isDay.sqf";

And check the result with i.e. the following:

player globalChat format ["Is it daylight now?: %1", call fn_isDay];

Another problem solved

Please let me know if you find any mistakes or situations where the result is completely havoc.

Ahh, yes, nearly forgot

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

private ["_leapyear","_dayinyearselection","_isday","_year","_month","_feb","_day","_dayofyear","_daysthisyear","_minutesintoyear","_normyear","_baserise","_baseset","_factrise","_factset","_sunrise","_sunset"];

_leapyear = [0,1,0,0,0,1,0,0,0,1,0,0,0,1,0];

_dayinyearselection = [0, 31, 31, 62, 92, 123, 153, 184, 215, 245, 276, 306];

_baserise = 7.5;

_baseset = 16.5;

_factrise = 3;

_factset = 2.5;

_isday = true; //return true in case of function failure

_year = date select 0;

_month = date select 1;

_feb = 28 + (_leapyear select (_year - 1995));

_day = date select 2;

_dayofyear = if (_month <= 2) then {_day + (_dayinyearselection select (_month-1))} else {_day + _feb + (_dayinyearselection select (_month-1))};

_daysthisyear = if(_leapyear select (_year - 1995) == 0) then {365} else {366};

_minutesinyear = _daysthisyear * 24 * 60;

_minutesintoyear = (1440 * (_dayofyear-1)) + ((daytime/24) * 1440);

_normyear = 360*(_minutesintoyear/_minutesinyear);

_sunrise = _baserise-(_factrise/2)*((cos (_normyear+180)))-(_factrise/2);

_sunset = _baseset+(_factset/2)*((cos (_normyear+180)))+(_factset/2);

_isday = if ((daytime > _sunrise) && (daytime < _sunset)) then {true} else {false};

_isday;

[M.Andersson(SWE) 4]

LOL this is verry funny...

I did a small mission last night and some of the AI´s

i put had NVG´s on some didnt...

It was 5.30 in the morning and some fog...

You dont put on NVG´s in that situation in

real life..

[CarlGustaffa 4]

Well, I use this now to determine if a night mission (Domination mod) should be made, which includes static lights, and if AI should use illumination based artillery when they fire upon us. Not so much NVG usage This combined with always moonlight available causing some terrain illumination, and now prolonged illumination artillery fires should make NVGs less desired. Actually, not all roles will even be able to get them anymore.

And yes, I agree. The use of NVGs seem to me to be a bit misunderstood. And this is my attempt to try to remove a bit of this. First step on that route was figuring out if it was night or day

[zolop 0]

Did the script take into a account the skill level of the AI players? This might be why some of them Have Night-vision versus other AIs don't.

If you do this next time, make sure all the AI's have MAX skill in the editor, otherwise you will always get different result as a float variable uses the skill value to calculate wheather or not the AI will use goggles.

NOTE: I am a newbie to scripting and have little experience, but make the variables in this function/equation constant is needed in any situation to make any function/equation work the same way consistently. From that point when you ahve it working then try messing with more things.

[CarlGustaffa 4]

If you look at Suma's engine code, it takes both skill (ability) and adds a little randomness to the system.

My code doesn't have anything to do with NVGs or scene brightness whatsoever, it is only a way to determine if it is night or day by triognometric means. It is not "accurate" but will fill at least my needs: Use of illumination rounds, and setting up dynamic mission (Domination Main Target missions) as a night or day mission.