next »

[Spooner]

Ack, the version you uploaded still had the _x error! Oops! The problem with _x being the forEach iterator and being a sensible name for x-axis position is a pain ;P Good to see you worked that one out! You'll notice that I use "_ids = _x;" to avoid overwriting the value in the nested forEach loop, but I didn't consider the _x script parameter.

I noticed that you pass the player's unit to the script. Well, when a player respawns, the unit changes, so that would break the script. Also, it wouldn't work when in an MP game, where each player object is different. Forget passing _unit and just use the player command to resolve both these issues. Make sure that you don't run the script on a dedicated server too, since it is just client-side eye-candy (At the top of the lights script, exit if dedicated server: "if (isServer and (isNull player)) exitWith {};").

As far as frame-rate goes, I found the frame-rate about the same in both versions. Remember that you can't compare the frame-rate of a player flying a Camel in one position to the frame-rate of a soldier standing in another position, which may have been giving faulty readings.

Consider what happens when the player is beyond the maximum distance away from the lights. The outer while loop will run continually without breaks and the machine will come to a halt, since no other scripts are being allowed to run. If the player is too far away, then you need to take sleep breaks on each iteration (I'd suggest a couple of seconds).

You used mod correctly, but it isn't strictly necessary for the "_i" loop. The value can only be out of range when you are looking at row (_i + N), when the value needs to be modded to "wrap it around".

Further ideas: Allow for two or more sets of lights to be lit at the same time (e.g. for two sets: _i off, _i + 2 on, _i + 28 off, _i + 30 on). If you do this, you could probably be fine slowing the speed of the lights a bit, without making it harder for the player to work out where the runway is (I'm suggesting this without knowing what these sorts of lights would look like in real life; anyone got a video link to an example?).

[[seven]]

Here's a link to a vid I found with blinking approach strobes.  As you can see they move very very fast.  To see them, forward ahead to about 1:20 in the video.
http://www.youtube.com/watch?v=PY3XvuuKJvI

I didn't look at the frames to measure performance.  I added some benchmarking code like so:

_time = time;

//Lights turning on and off.

_timepassed = time - _time;

 hint format["Time to end of runway is: %1",_timepassed];

I've uploaded two benchmarking examples in one .rar file.

Using the straighforward code (v1_1quad), I get around a 1 second average for the lights to reach to the end of the runway.

Using the array based code (v1_2alpha), I get around a 2.2 second average for the lights to reach to the end of the runway.

Both versions use the same sleep time of .01.

I think a 50% gain is worth the time it took to write all that code.

I think I'm going to do as you were saying and create one perfect, multiplayer-synchronized script for the main airfield (since at least 90% of takeoffs and landings occur there) and then work on something functions dynamically for all airfields once I finish that.  I just need to find a better way to activate the lights if it's going to be properly synched, I already have a few ideas.

[Spooner]

OK, I haven't checked this, but using _time is not a good plan since it is already defined, as commented in the definition for time.

Not to be confused with _time.
Within a script, the reserved local variable _time returns the time elapsed since the script started running.

time is also not updated except when sleeping, so it only really shows the time of sleeping, not other command execution.

I am totally convinced that the difference between the array/loop version and the repeated code version is negligible. What you will find is that there are twice the number of sleep commands actually performed in your looped version compared to your repeated code version. Using the on-off method you are using, the loop:

Code:

      for "_i" from 0 to (_numRows - 1) do

should be

Code:

      for [{ _i = 0}, { _i < _numRows}, {_i = _i + 2 }] do

This change will make the two scripts actually perform the same commands within one iteration (I'll hold my hand up to steering you in the wrong direction there! Sorry!).

Another thing to consider: Bear in mind that when you sleep for 0.01 seconds, then that actually will sleep for ONE FRAME (unless FPS is > 100, when it could more more than one frame), not for 0.01 seconds. This will become an issue that so far has been ignored by both of us, since the speed of light travel is very much dependent on current FPS.

As far as making a generic version once this version is complete, I know Mandoble would strangle me if I didn't encourage that ;P

[Mandoble]

As far as making a generic version once this version is complete, I know Mandoble would strangle me if I didn't encourage that ;P

In fact I'm tempted to strangle both of you  Really, you two took the most complicated way to solve the problem, and yoooou Spooner know that pretty well   

[[seven]]

In fact I'm tempted to strangle both of you Really, you two took the most complicated way to solve the problem, and yoooou Spooner know that pretty well   

Who says the problem is solved?  I still have more questions. 

I've been fooling around for a few hours trying to see if I could dynamically detect any runway edgelights that might already be present on a map, using nearestObjects to search around the ILS position I've been having no success.
Also, how can a I convert config files to text for reading  I tried downloading a tool called cfgconvert from bi but the link was no good. 

[Mandoble]

If you read the ILS position (landing start), the runway heading and the first taxi position (runway end) from the config (check OFPEC ILS to figureout how), why do you need to detect any edgelights? You have all the data needed to create your own ones, separated by the distance you consider optimum to do not affect game performance in any way. But not only that, you will have a script compatible with any Island, present of future. About airfields usage, Sara has two main airfields, one nicely finished, and the other not (SE corner), but in MP games probably side A will use airfield A and side B would use airfield B, and in that second airfield you will not find any pre-placed edgelights on the map.

[[seven]]

I have the ils position and direction figured out. 

The answer to your question is simple, I want to use the existing edgelights where they are already present, and create edgelights in the airfields that don't already have them.  The end result will still work with any airport on any map.

[Edit] Also, I don't seem to be able to figure out how to get the first taxi position.  I know to look for "ilsPosition" and "ilsDirection" for the other things but that's it.  How can I look through the config in a text editor so I know what I'm looking for when using code to read the config?

[Planck]

ilsTaxiIn and ilsTaxiOff are what you need for taxi positions.

ilsTaxiIn are the taxi points the aircraft takes to get to the end of the runway to take off.
ilsTaxiOff are the taxi points the aircraft takes to leave the runaway after landing.

The first taxi point for landing is generally the same as the ilsPosition anyway.


Planck

[[seven]]

New test version uploaded.

Whats new?

Automatic detection of pre-existing edgelights.

Creates edgelights if auto-detect is not activated.

Allows for "exceptions" when creating edgelights (so you don't have edgelights blocking your taxiway or whatever).

Multiplayer re-synching so the strobes start at the same time each time a cycle is finished.

Allows different airfield strobes to be controlled by different factions.

Controlling faction of an airfield can be redifined accordingly.

Includes switching script for use with addAction.

Plus more...

This is only a test version so there are no detailed insructions just yet, for now just fly around and have fun playing with the lights while you go barnstorming.

[Spooner]

1. Although you don't have a "server" in your demo mission, in some of your scripts you use:

Code:

if (not local server) exitWith {};

I know you know how to use isServer, since it is in another of your scripts (the simple isServer command made the "local server" workaround redundant)!

2) I don't really understand what you are trying to do with the synchronisation, "Multiplayer re-synching so the strobes start at the same time each time a cycle is finished.", which presumably uses lightsynch.sqf, so I can't say whether it is working as you intended.

3) When you turn on the strobes, you turn on the strobes at the closest airport, which is correct. When you turn off the strobes, you turn off the strobes at the closest airport, even if that airport isn't the same one that you turned strobes on at beforehand. At least as far as I can tell...

4) Number of other issues I was confused about, I can discuss with you in MSN at some point.

[[seven]]

I don't really understand what you are trying to do with the synchronisation, "Multiplayer re-synching so the strobes start at the same time each time a cycle is finished.", which presumably uses lightsynch.sqf, so I can't say whether it is working as you intended.

What lightsynch.sqf does is regulate the time when strobes begin again after they have reached the end of the runway, it is also used during single player operation. It is like a metronome.  The clients that are ready (the ones that have finished their last strobe) wait for the value to be true before they start the strobes again, they will all start at the same time give or take a few milliseconds.  So basically what happens is this: different peoples framerates cause them to have slight differences in the speed of the lights movement, but no matter how out of whack they get from one client to another, they always wait for the server to tell them when to start again.  I chose this rather than than true multiplayer synching because I don't want someone with a low framerate messing up the effect for everyone else.

3) When you turn on the strobes, you turn on the strobes at the closest airport, which is correct. When you turn off the strobes, you turn off the strobes at the closest airport, even if that airport isn't the same one that you turned strobes on at beforehand. At least as far as I can tell...

The switching script I wrote does exactly as you say.  But there is more than one way to skin a cat!   

The lights can be activated/deactivated however you wish.  For example, place a trigger over the airfield and use:

lightswitchonoff set [airportidnumberhere, true];

for the act

lightswitchonoff set [airportidnumberhere, false];

for the deact

The array lightswitchonoff holds the values that switch the airports off and on.  Use triggers, write a small script, whatever.  The sky is the limit on how you want to change those values! 

Of course I do plan on including more activation scripts for different situations but no point in doing so until I get things down a bit tighter.

As an aside, clients will only check the switch status of one (the closest) airfield at any given time.  If someone say leaves the lights on at pita for some reason, it won't be eating up the resources of people who are closer to antigua.

I have a good idea of some of the other things that you might find strange, hit me up on msn for those.  I also have some questions for you.

[Falcon 1]

Mind if I use this?

Will give full credit 

[[seven]]

Mind if I use this?

Will give full credit 

Of course you can, that's the point of posting it!  I have to warn you it isn't fully working for multiplayer yet however, spooner is helping out with some issues, hopefully I'll have updates for some of my scripts this week.

[Dwarden]

ok for some reason i'm unable to get this working in MP (and JIP) ... it seems to work ok only on local server ... not dedi nor JIP

[[seven]]

New version uploaded.  Should work for MP/JIP. 

Feedback appreciated.