Infinite Loop - possible?

[sickboy 13]

Guys, didnt Kegetys basicly gave the solution to this problem, altough it was meant for something else.

Slightly edited:

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

_x = 0;

while{true} do

{

  _x = _x + 1;

  if(_x==9999) then {breakTo "myRoot"};

};

Ok, let's not call it a solution, but a workaround, still... better than the waituntil and while while while stuff if you ask me

[sbsmac 0]

Quote[/b] ]Guys, didnt Kegetys basicly gave the solution to this problem

No - unfortunately not. breakTo is not a 'goto' statement, it is more like the 'break' statement in the C language. Ie, in the example you gave, control will return to the point AFTER the while loop.

[sickboy 13]

No - unfortunately not. breakTo is not a 'goto' statement, it is more like the 'break' statement in the C language.  Ie, in the example you gave, control will return to the point AFTER the while loop.    

Bummer! ( and I thought I had the tip of the day, lol!

[Romolus 0]

@ColonelSandersLite:

I hate to tell you, but in games there's still quite a bit running with the frame cycle. This doesn't make the code unreliable at all. The problem with older games was that they took the frame cycle as time interval and therefor time elapsed faster with more fps. But even that doesn't make the code unpredictable, just unplayable.

Having a loop that runs with the frame cycle isn't really a bad thing in a game. I actually think it's a good thing since you as a player can't do anything between two frames anyway, so in most cases it's just wasting resources to do anything faster than that. If you're script is executed once every frame, then that's probably just the right way to do an infinite loop in a game.

And about coding standards and messy code: Now you're fighting a holy war here.

I'm a programmer by trade and I care a lot about programming standards and doing things the right way for work and personal projects.

But let me ask you just one question: Did you do any advanced scripting in OFP?

I'd say that at least 50% of the advanced scripting that was done for OFP were pretty bad hacks that would make my socks fly off when thinking about coding standards!

Heck if everyone adhered to coding standards in OFP scripting I bet we wouldn't be here talking about this right now because OFP scripting would have died long ago.

This is a game of how high you can pile up hacks until either the engine or you capitulate.

Trying to adhere to or expecting standards that you know from elsewhere will only make your hair turn grey.

@all:

Since I can't really think about a reason why I'd need to run an infinite loop faster than with each frame, I'd just use waitUntil.

If the engine is bogged down with other things (which results in lower fps), then why would you want to put additional stress onto it anyway by running your loop in constant time way faster than the frame cycle?

It might be harder to read for people not used to it but that's not the most important criteria in a game anyway. First it has to run and don't hamper performance and only after that it's allowed to look pretty.

There are tons of hacks and nasty things in every commercial game so don't get too fussed about this. Just make sure you know what you're doing.

[UNN 0]

Quote[/b] ]you did state that it appeared to be related to FPS.

I know I stated that, I just didn't categorically state it.

Quote[/b] ]waitUntil (like @ in OFP) appears to be bound to FPS (for want of a better term)

The word appears and the phrase for want of a better term were all meant to indicate this was just a theory of mine.

Quote[/b] ]2: Further, I did test it.  Simple division with the code I posted above yielded approximately 1 loop per execution, no matter what the FPS.  I say approximatly, because I did it with a wrist watch and fraps.  I did 5 tests, with FPS ranging from about 60 FPS to 15 FPS.  Each time, the division looked like this: 1,000 (number of loops)/15 (number of seconds the code took to execute)/60 (frames per second) = 1.111111.  Another example, on the opposite end of the scale, is: 1,000/67/15= 0.995024.  There where three other tests to be sure, but I stopped writing them down after my initial conclusions where reached.  If something had proven inconsistant, I'm sure I would have retested them more in depth.

Thanks for testing it and sharing the results.

Quote[/b] ]But don't take my word for it, since it's obviously "biased".  Never mind the fact that my biases are based on my test results... Run the test as described above for yourself.

Well I do think you do have a bias against waitUntil, but at least posting your test results shows it isn't just an off hand statement. But if you want to compare while to waitUntil, then you have to test them both together to. For example, if you devise a while loop that takes 1 second to execute, how would that effect the FPS and other waitUntil commands running in other scripts?

Quote[/b] ]Or are you too busy?

Well I'm sure we are all busy this time of year, it's just. I do not have a problem with the waitUntil being bound to FPS. In fact I have found waitUntil (@ in OFP) to be quite useful now and in the past. So I did not feel the need to personally test something that has always worked the way I wanted it to. What I did need to know was, will sleep work as intended in a waitUntil loop, so I did test that.

Quote[/b] ]Yes, that's what we programmers call "dirty code".  It's dirty code, because the waitUntil command name implies that is is for a boolean operation.

waitUntil is the only command that will sync with the refresh rate. So in that respect, it does what it says. Waits until at least a screen refresh.

Quote[/b] ]The only point you're really correct on here is the internal scopes.  An integer takes *very little* memory, compared to what a modern system has.  We're not programming in the days of huge vaccum tubes that hold a whole K of ram anymore.  Further, the outer loops are very rarely looping at all.

It's down to the individual, as to how efficient they want to make their code. But a line has to be drawn somewhere. I try and write code as efficiently as possible, but not at the expense of vague variables names e.t.c But a lot will depend on what you want to do in Arma. If your writing a mission, then you can control the amount of scripts being run at any one time. If your writing an addon to be used in a mission, then you don't know what else will be running alongside it. So some care has to be taken.

For example, if you created an infantry addon that automatically updated it's position on the map, using a loop and markers. Then you could have hundred of these loops all running at the same time, or you might only have eight. As it stands, your updating markers, so there is no need to make the loop any faster than the current frame rate. But because I might have the same script running across hundreds of units, I want that script to be as efficient as possible. In that respect WaitUntil is by far, the best solution. This opens up another possible thread. How much effort Arma has to put into interpreting individual commands in a script. I sometimes wonder if the code I add to a scriopt, in an attempt to make it more efficient, is in fact making it worse. Only BIS staff, with an in depth knowledge of the interpreter could probably answer that, for every instance.

Quote[/b] ]We're not talking about religion here, we're talking about *standards*.

Perhaps this is why this topic has taken on such proportions. IMHO we are not writing an operating system using an internationally recognised programming language. We are writing for a very specific application. So I would not adhere to your standards at the expense of efficiency and performance. If you had said from the start that, your while loop does conform to international standards although there are more efficient ways of doing the same thing in Arma. Then this topic would not have turned out the way it did. Instead you choose to say something along the lines of; The waitUntil command is unclean, anyone that uses it, is a sinner. That kind of dogmatic approach, sounds like a religion to me.

Quote[/b] ]1: BIS hasn't annoyed me at all, in fact quite the opposite.  The command is clearly designed with complex boolean operations in mind.

The way you talked about the waitUntil command, certainly suggested you were annoyed by it. At worst, you even consider it blasphemous.

Quote[/b] ]2: The rational is system based unpredictibility, and dirty code.  As stated above.  FPS in this game, depending on WHEN the code is executed on my OWN machine ranges from 20 in heavilly forested areas when looking through a sniper scope to 200 zoomed in on the map.  My modest 6800 xtreame SLI, running on one card card since the 6 series doesn't support hdr+sli+AA, produces these results.  I imagine that frame rates on the map can exceed 500 or more on some of the higher end systems with *REALLY NICE* SLI setups.

If that's not unpredictible, I don't know what is...  I'm not talking about systems 20 years from now, I'm talking about systems *now*.

This is the thing I object to. Terms like unpredictability, and dirty code. Clearly it's not unpredictable, we can predict that waitUntil, unless told otherwise by the sleep command. Will execute a loop on every frame. Calling it dirty, serves no purpose I can think of. Being able to execute certain lines of code, once, before each GPU update, is extremely useful. waitUntil offers a very neat and efficient way of doing this.

But yes, you are correct in the sense that. Sometimes you might want system wide loops, that need to execute every 0.0001 seconds regardless of FPS as they don't have to update anything visually in game. In that case, a while loop is ideal. In my experience while loops are ideal for specific tasks, waitUntil is a much simpler, kinder and more generic method of tackling the most common problems.

Quote[/b] ]Technical data: Ok, I admit that maybe I was a little remiss here, but then, you never posted any either.  The sword cuts both ways.

I've only made two posts in this thread, prior to this discussion. Both contained examples showing aspects of both commands. Offering proof for the conclusions I was making.

Quote[/b] ]Examples: What in the world do you think that example mission and scripts where?

That just qualified what I had already implied. So thanks for that. But that’s not the point. If your going to post comments like command x is bad, don't use it. Then I think it's better to offer some real proof? Again if you had been clear about it, only violating your idea of programming standards, then it would not have been an issue. But you implied that, if people use command x, it will be detrimental.

Quote[/b] ]Generally, in my experience on these and other forums, people don't tend to want to be bored with details. They are just interested in the results or doing their own experimentation based on handy short tips provided by others.

I'm not particularly interested in trying to predict what most people want or coming up with a list of commandments. I'm happy to read as much information as I can, so I can get straight to the problem at hand. If I bore people with to much detail, then hopefully they will soon learn to avoid my posts. Wading through the forums has saved me untold hours in scripting and testing, so I'm happy to continue doing so.

Quote[/b] ]Again, any code inside a waituntil that does not have anything to do with making it wait until a boolean operation evaluates true is misleading.  It will only cause confusion if you, or someone else, visits your code without intimite familliarity.  Code should always be written so that it can be clearly understood instantly.

Again, I can't speak for anyone else. But I don't find the waitUntil command, confusing. So I can't agree with you on that point.

[ColonelSandersLite 0]

@Romolus

@ColonelSandersLite:

Having a loop that runs with the frame cycle isn't really a bad thing in a game.

That actually depends on what the video load vs processor load is. If your system is capable of rendering fast, and the loop you're running is processor heavy, expect to bog the game down heavilly. If you're really wanting to synch a loop with the frame rate (and there are several valid reasons to do that), instead of some arbitrary time, try this. Although, you aren't restricted to it, this is more fitting with existing standards.

_i = 0; waitUntil {_i = _i + 1; _i > 1}; (used the same way a sleep command would be)

But let me ask you just one question: Did you do any advanced scripting in OFP?

I'd say that at least 50% of the advanced scripting that was done for OFP were pretty bad hacks that would make my socks fly off when thinking about coding standards!

Yes, I did. The thing is that sqs format is unstructured, which causes a lot of problems. Even then, I tried to imitate structured scripting practices as best as it could be done with gotos and such.

Further, I will never say that you should let standards get in the way of doing something you couldn't expediently do otherwise, however, this is not the case here.

Simply put, there is no real difference between:

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

while {true} do

{

while{true} do

{

while{true} do

{

_i = 0; waitUntil {_i = _i + 1; _i > 1};

};

};

};

and:

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

waitUntil

{

//dostuff;

false

};

except a little tiny bit of white space, and a little bit of behaviour. The behaviour is likely not a big issue in 99% of cases, however, in the 1% where using it improperly results in a serious bug, you'll wish you hadn't done that retrospectivly. If the white space is such a problem for anyone, they could always one line it like this:

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

while {true} do {while{true} do {while{true} do

{

// do stuff

};};};

Trying to adhere to or expecting standards that you know from elsewhere will only make your hair turn grey.

I'm not worried about that, at the rate I'm balding, I won't have to deal with hair dyes .

Thing is, that you keep talking about hacks and workarounds, and I'm saying there's not one necessary here. Sure, if you *need* to find a dirty way around something, by all means, go for it. But if it's not a necessity, it's not a good idea IMO. It'll just give you a nightmare debug, give others problems following your code, and give yourself more problems if you revisit your code when it's no longer fresh. I prefer to use standards whenever it's possible to do so without too much effort.

@UNN

I know I stated that, I just didn't categorically state it.

Talk about splitting hairs...:rolleyes:

Quote[/b] ]But don't take my word for it, since it's obviously "biased". Never mind the fact that my biases are based on my test results... Run the test as described above for yourself.

Well I do think you do have a bias against waitUntil, but at least posting your test results shows it isn't just an off hand statement.

I *said* I'm biased against it. I also happened to mention that it was due to test results. In fact you quoted me on it. Why in the world are you repeating what I just said?

waitUntil is the only command that will sync with the refresh rate. So in that respect, it does what it says. Waits until at least a screen refresh.

I'm not saying that there's something wrong with that, I'm saying, that I will never use it as a script control loop. See:

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

while {true} do

{

while{true} do

{

while{true} do

{

// dostuff;

_i = 0; waitUntil {_i = _i + 1; _i > 1};

};

};

};

It's down to the individual, as to how efficient they want to make their code. But a line has to be drawn somewhere. I try and write code as efficiently as possible, but not at the expense of vague variables names e.t.c But a lot will depend on what you want to do in Arma. If your writing a mission, then you can control the amount of scripts being run at any one time. If your writing an addon to be used in a mission, then you don't know what else will be running alongside it. So some care has to be taken.

1st, you do know that i, j, k, l, m, n, o, etc are standard counter names right? Not just vauge variable names, but *standard counters*.

2nd, you know don't even need those right (see the code immediatly above)? Being a manual kind of guy, I like to tell the script to exit the loop when it reaches 10,000 instead of letting the auto do it, but it's hardly necessary. That's my preference, see below for more on that. And frankly, it still doesn't make a difference running dozens of scripts set up like that on hundreds of units at the same time. Yes, I know that from hard experience.

But because I might have the same script running across hundreds of units, I want that script to be as efficient as possible. In that respect WaitUntil is by far, the best solution.

I'm not argueing against using waitUntil at all. I'm arguing against using it in a certain manner. I'm *not* arguing against using it as a method of synching a script with the frame rate either. I'm arguing explicitly against using things that have nothing to do with waiting until the condition has been reached inside the wait until.

Quote[/b] ]We're not talking about religion here, we're talking about *standards*.

Perhaps this is why this topic has taken on such proportions. IMHO we are not writing an operating system using an internationally recognised programming language. We are writing for a very specific application. So I would not adhere to your standards at the expense of efficiency and performance. If you had said from the start that, your while loop does conform to international standards although there are more efficient ways of doing the same thing in Arma. Then this topic would not have turned out the way it did. Instead you choose to say something along the lines of; The waitUntil command is unclean, anyone that uses it, is a sinner. That kind of dogmatic approach, sounds like a religion to me.

I think I disagree with just about everything you said there. I'll, answer the first sentance below.

As to the second, we may not be writing an OS, but how many editors does ARMA have around the globe? Can you tell me? If it's just you, me, crashdome, Romolus, sbsmac, and special ed (first six that came to mind only), then hell, let's leave it all alone....

As to the second and thrird, your method is no more efficient than the one posted immediatly above, and that's what I posted above. That has nothing to do with the reason this topic turned out the way it did.

And no, but that's something else I will adress below.

Quote[/b] ]1: BIS hasn't annoyed me at all, in fact quite the opposite. The command is clearly designed with complex boolean operations in mind.

The way you talked about the waitUntil command, certainly suggested you were annoyed by it. At worst, you even consider it blasphemous.

No, see below.

But yes, you are correct in the sense that. Sometimes you might want system wide loops, that need to execute every 0.0001 seconds regardless of FPS as they don't have to update anything visually in game.

If by sometimes you mean "most of the time," and by 0.0001 seconds you mean "x number of seconds" then yes.

Quote[/b] ]Technical data: Ok, I admit that maybe I was a little remiss here, but then, you never posted any either. The sword cuts both ways.

I've only made two posts in this thread, prior to this discussion. Both contained examples showing aspects of both commands. Offering proof for the conclusions I was making.

Hmmm...

You know, that's not technical data, that's examples. You do realize that I had only made 2 posts as well right? As far as I can see, as of now, I've posted some technical data (even if it's a little rough), and you haven't.

If your going to post comments like command x is bad, don't use it. Then I think it's better to offer some real proof?

See below.

I'm not particularly interested in trying to predict what most people want or coming up with a list of commandments.

Ok, this is where you need to pay attention for all the "see belows".

1st, I *NEVER SAID* "THIS IS BAD, DON'T DO THIS" before you jumped down my throat. I said "IT DOES THIS, THIS IS MY OPINION, THIS IS WHY, AND THIS IS WHAT I DO".

Sorry for the caps, but perhaps you need them to "get it". I have always used *I*'s in my posts here, not *YOU*'s.

In fact, here's the majority of that post all over again (cropped to save some room here and there), just for UNN, annotated this time:

*IT DOES THIS*

Quote[/b] ]A quick experiment shows that waitUntil...blah blah blah...I have no clue how it performs on a dedicated server.

*THIS IS MY OPINION*

Quote[/b] ]However, you will never see *me* use this command in this fashion. Ever.

*THIS IS WHY*

Quote[/b] ]1: There's an inherint unpredictibility wi...blah blah blah...hem (sqs scripts anyone?).

*AND THIS IS WHAT *I* DO*

Quote[/b] ]Frankly, *I'd* rather just nest the loops as in *my* example above, and know that it will run for literally run for years on end and be system independent, than use a command like that one.

Now, can you tell me where in that post I say *you should do this*? Other than "What we really need to ask here, is why BIS decided to make loops quit after 10,000 loops." Which, to me at least, is perfectly moderate and reasonable.

2nd, This whole argument between you and me is because I said "IT DOES THIS, THIS IS MY OPINION, THIS IS WHY, AND THIS IS WHAT I DO" and you just had to read that as "OMG NOOB, UR WRONG PWND". If you had asked for clarification instead of jumping down my throat with

Quote[/b] ]I didn't say this, you're wrong an biased, WTF THIS is nasty and this ISN'T, you're an idiot, why do you think your opinion is better than everyone elses. Do you think you're god or something? OMFG!!!111one!eleveltyfirst!!"

Alternatly, perhaps you could have said, "I disagree, and here's why", instead of name calling, chest thumping, and posturing. I think you could have saved us both a few pages of typing if you had done either one of these. Frankly, I'm tired of it, and will deal with you no more. Everytime I run into you, it feels like I'm back in the friggin ubi zoo.

[UNN 0]

Quote[/b] ]2nd, This whole argument between you and me is because I said "IT DOES THIS, THIS IS MY OPINION, THIS IS WHY, AND THIS IS WHAT I DO" and you just had to read that as "OMG NOOB, UR WRONG PWND".  If you had asked for clarification instead of jumping down my throat with

Yes exactly, you should have made your reasoning clear from the start instead of just reacting.

Quote[/b] ]

Quote[/b] ]I didn't say this, you're wrong an biased, WTF THIS is nasty and this ISN'T, you're an idiot, why do you think your opinion is better than everyone elses. Do you think you're god or something? OMFG!!!111one!eleveltyfirst!!"

Alternatly, perhaps you could have said,

I think it's bad manners to imply that I posted something, when I didn't.

Quote[/b] ]Alternatly, perhaps you could have said, "I disagree, and here's why", instead of name calling, chest thumping, and posturing.  I think you could have saved us both a few pages of typing if you had done either one of these.  Frankly, I'm tired of it, and will deal with you no more.

Well this thread could have just contained two examples of infinite loops. But you set the tone of this conversation from the start.

Quote[/b] ]Using that command in that particular fashion is just nasty.

And maintained it to the end:

Quote[/b] ]Everytime I run into you, it feels like I'm back in the friggin ubi zoo.

Good job I read through the entire post, before replying to the rest  

[raedor 8]

Come back to earth, guys...

[Kirby 2]

Roughly translated, Raedor means chill out all he's asking is how to make a loop last longer than 10,000 or whatever. Not promote an argument over The best way about doing it

[walker 0]

Edit Miss read Post SQF not SQS

[KaRRiLLioN 0]

I solved it quite simply.  I just copied and pasted my main loop 5 times in a row, one after the other, so once it's done with one, it starts the other.  That's as clean as it gets.

And I just finished converting a ton of SQS scripts to SQF, too.  GAH.  

What I REALLY want to know is if changing the while do loops to infinite would break something somewhere else, or if BIS can simply adjust a hardcoded number somewhere in the ArmA code and release a 1.03 patch.  

I have a squadmarker script that loops and keeps tabs of squadmates with their names, etc. and it only sleeps for .02.  Otherwise the updates are a little jerky.  Unfortunately, that means it stops running at about 5:37 into the game, give or take a few seconds.

I'll probably nest the sucker for now.  I would just have it execVM the script over again after the loop, but it creates the markers, and I just figured out createMarker is global for some bloody reason.

[kronzky 5]

Using a for...do loop actually works quite well...

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">for [{_loop=0}, {_loop<1}, {_loop=_loop}] do

{

sleep 0.001;

// do whatever you gotta do...

if (your_exit_condition) then {_loop=1;};

};

DO NOT take out or reduce the sleep command, though, or it'll lock up.

[nubbin77 0]

When you say

Quote[/b] ]DO NOT take out or reduce the sleep command, though, or it'll lock up.

Could you make it "sleep 1;" or "sleep 10;" but not "sleep .00001;" That would be good because I want to do a marker script that tracks groups, but it doesn't need to update very much, like once every 5 -10 seconds. Not necessary to have it updates 100 times per second.

[UNN 0]

I knocked up a basic marker script to try out the three different loops. It's not supposed to be the most ultimate marker script every, all it does is create and move a marker in relation to the groups leader.

Called With:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Script=[Group This,"Team1"] ExecVM "Script.sqf"

WaitUntil:

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

_Name=_This Select 1;

_Marker=CreateMarker [_Name,GetPos (Leader _Group)];

_Marker SetMarkerType "Dot";

_Marker SetMarkerSize [1,1];

WaitUntil

       {

       _Leader=Leader _Group;

       WaitUntil

               {

               If (Alive _Leader) Then

                       {

                       _Marker SetMarkerPos (GetPos _Leader);

                       Sleep 1;

                       };

       

               !(Alive _Leader)

               };

       ((Count (Units _Group))==0)

       };

DeleteMarker _Marker;

WaitUntil literally waits until the code has been executed before checking the condition. So it needs an additional check before updating the marker pos.

While:

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

_Name=_This Select 1;

_Marker=CreateMarker [_Name,GetPos (Leader _Group)];

_Marker SetMarkerType "Dot";

_Marker SetMarkerSize [1,1];

While {(Count (Units _Group))>0} Do

       {

       Sleep 0.001;

       While {(Count (Units _Group))>0} Do

               {

               Sleep 0.001;

               _Leader=Leader _Group;

               While {Alive _Leader} Do

                       {

                       _Marker SetMarkerPos (GetPos _Leader);

                       Sleep 1;

                       };

               };

       };

DeleteMarker _Marker;

The While loops have an extra delay of 0.001, just in case it locks up or causes a delay when the last team member dies.

For:

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

_Name=_This Select 1;

_Marker=CreateMarker [_Name,GetPos (Leader _Group)];

_Marker SetMarkerType "Dot";

_Marker SetMarkerSize [1,1];

For [{_GroupAlive=(Count (Units _Group))>0},{_GroupAlive},{_GroupAlive=(Count (Units _Group))>0}] do

       {

       Sleep 0.001;

       _Leader=Leader _Group;

       For [{_LeaderAlive=Alive _Leader},{_LeaderAlive},{_LeaderAlive=Alive _Leader}] do

               {

               _Marker SetMarkerPos (GetPos _Leader);

               Sleep 1;

               };

       };

DeleteMarker _Marker;

The For loop has an extra delay of 0.001, just in case it locks up or causes a delay when the last team member dies.

[sbsmac 0]

@Kronzky Neat - I hadn't realised the for loop doesn't have a limit. Doubly nested whiles can therefore be replace with this:-

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

for [{}, {true} , {true}] do {

your code body goes here

Sleep or waituntil

};

I tested this up to 90000 iterations just to ensure there wasn't a 16-bit limit somewhere.

[sbsmac 0]

@UNN

Quote[/b] ]For [{_GroupAlive=(Count (Units _Group))>0},{_GroupAlive},{_GroupAlive=(Count (Units _Group))>0}] do

Wouldn't this be easier to write as

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">For [{},{(Count (Units _Group))>0},true] do ?

Similarly with the leader test

[UNN 0]

Quote[/b] ]Wouldn't this be easier to write as

It's probably better writen that way, as I'm assuming it checks the condition before executing the code in the loop.

That first parameter in the loop, is effectivly checking the number of units, before it thinks about executing the code. Otherwise it will execute the code regardless. Ok, not such a big deal in this example. But if the delay was set to 100, then it would wait 100 seconds before realising there are no units left to update.

It's just the same as writing:

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

If (Count (Units _Group)>0) Then

      {

      For [{},{_GroupAlive},{_GroupAlive=(Count (Units _Group))>0}] do

             {

             Sleep 0.001;

             _Leader=Leader _Group;

             For [{_LeaderAlive=Alive _Leader},{_LeaderAlive},{_LeaderAlive=Alive _Leader}] do

                     {

                     _Marker SetMarkerPos (GetPos _Leader);

                     Sleep 1;

                     };

             };

      };

[nubbin77 0]

Basic question here.  What am I doing wrong.  I haven't been able to figure out how to execute a script with variables in an array.  I thought this is what I should be doing:

In the editor, in the leader of a group of infantry.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">gw1 = group this;Script=[gw1,"INF1"] ExecVM "nubfunctions\fnmarkermove.sqf"

then in the script I have:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> private ["_group","_marker","_Leader","_GroupAlive"];

_group = this select 0;

_marker = this select 1;

If (Count (Units _group)>0) Then

{

For [{},{_GroupAlive},{_GroupAlive=(Count (Units _Group))>0}] do

{

Sleep 0.001;

_Leader=Leader _Group;

For [{_LeaderAlive=Alive _Leader},{_LeaderAlive},{_LeaderAlive=Alive _Leader}] do

{

_Marker SetMarkerPos (GetPos _Leader);

Sleep 1;

};

};

};

It errors out after "this select 0"  saying it expects an array.  

isn't this an array?  Script=[gw1,"INF1"]   how else to you execVM an array?

Also, is it necessary to make the variables "private" in the first part of the script?  when is that necessary? only in functions?  I tried with and without it being private so I know that's not the problem here.  However I don't see what I am doing wrong with transmitting the array to the script.

The only example in the BIKI is

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">var = player execVM "test.sqf"

[sbsmac 0]

I'd be inclined just to write this as

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

_group = _this select 0;

_marker = _this select 1;

for [{},{(Count (Units _Group))>0},{true}] do

{

_Leader=Leader _group;

for [{},{Alive _Leader},{true}] do

{

_Marker SetMarkerPos (GetPos _Leader);

Sleep 1;

};

Sleep 0.001;

};

I think your problem was that you weren't using the 'local' version of 'this' with an underscore.

[nubbin77 0]

that worked thank you. I knew it had to be something obvious.

[silola 1087]

hi,

I think, with a simple marker script, it's also possible to loop the script itself.

First you preprocess the script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">fShowMarker = compile preprocessFile "ShowMarker.sqf"

After the marker for the group was createt, the script is started:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[_group,_marker] spawn fShowMarker;

The script looks then as follows:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">private ["_group","_marker"];

_group = _this select 0;

_marker = _this select 1;

while {(count (units _group)) > 0} do

{

_marker setmarkerpos (position (leader _group));

sleep 0.2;

};

if((count (units _group)) > 0) then

{

[_group,_marker] spawn fShowMarker;

}

else

{

deletemarker _marker;

};

bye

silola

[5133p39 16]

Just in case someone missed that information:

Since the ArmA version 1.05 the max limit of 10000 iterations was removed.

From now on, you don't need to nest multiple While loops to achieve the effect of an infinite loop.