Home   Help Search Login Register  

Author Topic: Life time of a script  (Read 4336 times)

0 Members and 1 Guest are viewing this topic.

Bluelikeu

  • Guest
Re:Life time of a script
« Reply #15 on: 13 Jul 2005, 01:35:31 »
Just as a general programming statement. The end of a file is already calculated upon its opening by the runtime environment. In no programming language can you just read the first, or second line without it being completely loaded into memory. You also cannot get, for example, the 5th line in a file without first reading everything before it.

Edit: On the part about loops. If OFP does not separate the script at looping areas, it would have to re-read the entirety of the script in order to run through the loop again. Lets hope it doesn't do that.

bit offtopic.

Thanks,
Bluelikeu
« Last Edit: 13 Jul 2005, 01:37:29 by Bluelikeu »

Offline bardosy

  • Honoured Contributor
  • ***
  • campaign designer
    • CartooDiv
Re:Life time of a script
« Reply #16 on: 13 Jul 2005, 07:58:34 »
THobson!

I examine your hanged man script before I post this question. And I want ask something about this: can you write it over to general? I mean not for two people, but for one. But if I use this general script to 100 peaople, all of them hanging?
Because I can't do that with my script. (I hanged only two, like you...)
Fix bayonet!

Offline THobson

  • OFPEC Patron
  • Former Staff
  • ****
Re:Life time of a script
« Reply #17 on: 13 Jul 2005, 08:11:39 »
The following is a general script for one person.  Save it as script called:  Hanging.sqs

The put the following in the init field of each unit to be hanged:

[this] exec "Hanging.sqs"

In init.sqs put Hanging = false.
To start the hanging set Hanging = true
To stop the hanging set Hanging = false

100! Your mind is as sick as mine.  You might need to lengthen the delay in the loop to prevent too much lag.


I have randomised a few things so they don't all look the same.
The script (not tested) is:


Code: [Select]
_victim = _this select 0

_start = random 360

;Size of swing from the centre in degrees
_swing = 10 + random 5

;time for one complete swing in seconds
_period = 10 + random 10
_degreespersec = 360/_period

@Hanging
#loop

~0.001
_victim setDammage 0
 
_victim setpos [getpos _victim select 0, getpos _victim select 1, 1.2]
_victim switchMove "paradead"
 

_victim setDir (_start + _swing * sin (_degreespersec * _time))

if not Hanging then {exit}

goto "loop"

Err... enjoy?
« Last Edit: 13 Jul 2005, 08:17:30 by THobson »

Offline bardosy

  • Honoured Contributor
  • ***
  • campaign designer
    • CartooDiv
Re:Life time of a script
« Reply #18 on: 13 Jul 2005, 08:30:31 »
Thanks!

Are you give permission to community to use it? (eg.: to me  :) )
Fix bayonet!

Offline THobson

  • OFPEC Patron
  • Former Staff
  • ****
Re:Life time of a script
« Reply #19 on: 13 Jul 2005, 08:44:56 »
Certainly - just say where you got it from.  It's hardly top secret or particularly difficult.  Like most things the difficult bit is having the idea.

Offline h-

  • OFPEC Site
  • Administrator
  • *****
  • Formerly HateR_Kint
    • OFPEC
Re:Life time of a script
« Reply #20 on: 13 Jul 2005, 14:50:34 »
Continuing the off-topic:
Just as a general programming statement. The end of a file is already calculated upon its opening by the runtime environment. In no programming language can you just read the first, or second line without it being completely loaded into memory. You also cannot get, for example, the 5th line in a file without first reading everything before it.
So, in light of this putting the 'exit' there does not do any harm anyway... ::)

I always saw the exit as a sort of a 'closing bracket' rather than an actual function like Baddo suggests it is...
After all, the 'exit' does not need to calculate or check any conditions, it just 'exits'...
« Last Edit: 13 Jul 2005, 14:51:10 by HateR_Kint »
Project MCAR   ---   Northern Fronts   ---   Emitter 3Ditor
INFORMATIVE THREAD TITLES PLEASE. "PLEASE HELP" IS NOT ONE..
Chuck Norris can divide by zero.

Offline THobson

  • OFPEC Patron
  • Former Staff
  • ****
Re:Life time of a script
« Reply #21 on: 13 Jul 2005, 16:22:02 »
Slightly tidier (the global variable is destroyed when it is no longer needed), and slightly less CPU intensive (removed the not from the loop condition - normally I wouldn't bother but for 100 instances of such a fast loop it might make a difference):

Code: [Select]
_victim = _this select 0

_start = random 360

;Size of swing from the centre in degrees
_swing = 10 + random 5

;time for one complete swing in seconds
_period = 10 + random 10
_degreespersec = 360/_period

@Hanging
#loop

~0.001
_victim setDammage 0

_victim setpos [getpos _victim select 0, getpos _victim select 1, 1.2]
_victim switchMove "paradead"


_victim setDir (_start + _swing * sin (_degreespersec * _time))

if Hanging then {goto "loop"}

Hanging  = nil

exit
« Last Edit: 13 Jul 2005, 16:26:44 by THobson »

Offline Baddo

  • Former Staff
  • ****
  • Reservist Jaeger
Re:Life time of a script
« Reply #22 on: 13 Jul 2005, 16:55:34 »
Huh, what a response to my arguments, you guys are sensitive about the exit command.

:)

My arguments were based on the fact that OFP (like any other program that reads files) expects the EOF to come at some point and thus it is checking for it already so putting the exit there in addition is unnecessary.

I can not imagine a reason why BIS would program OFP so that after EOF it would not release memory that was used to keep the local variables and the contents of the file if exit was not used. That would be a very stupid thing to do with the script files which are not intended to stay in the memory after it has been read and commands in it have been executed. Forcing us to use some scripting command to release the memory is not a good idea... OFP has to deal with it without our help.

@HateR_Kint

The 'white space' in your script file is not something magical for a programming language like C++ that it couldn't deal with. The empty line has to be marked somehow to the file and OFP will go through these lines too, all the way to the EOF. It's not my or OFP's fault if you put many pages of empty lines to your scripts...

:P
Quote
And it has to do it like that, how else it would know a script had ended?

Well the answer is End Of File, a.k.a. EOF. Every file has an end and so do OFP script files. Arriving at the EOF, OFP will for sure know this is it. No going further from here.

 ::)
Quote
Suma said somewhere that OFP does not have a script compiler/parser/whatever so OFP doesn't seem to read through the script before executing it...

This really has nothing to do with the exit command or with the EOF. It doesn't matter when OFP goes through the script file, it still notices the EOF.

@qqqqqq

Sorry if your feelings towards the exit command were hurt, I didn't intend to do that.

;)

I did not say that having exit at the end of a script will cause lag. I said it is extra work for OFP (and for you too) because it's a scripting command that OFP has to deal with. OFP has to check the syntax of the command and only if it is correct then it is used, of course. And checking the syntax will take more time from OFP than simply just noticing that the file ended. This is common sense to me.

After finding exit, OFP has to do whatever is on the exit function. It can be the same code as what is executed when EOF is noticed by OFP.

It's the syntax checking part I am saying will make the usage of exit slower than just EOF, because OFP has to check the lines contents first character by character (you might have done a typo there, how can OFP know in advance that you don't do typos?) and then using exit can't be faster than just arriving at EOF because OFP is already expecting to see the EOF.

Huh. This is ridiculous but let's continue...

:)

Quote
Ending with exit could significantly speed things up.

What would the magical things be that the exit command does to speed things up? Maybe not releasing the memory used by the script and it's variables would be one way to speed things up momentarily, but that would lead to big problems later on, like filling the memory with garbage. So this is not possible and we already know this isn't true when it comes to how OFP handles scripts. Good job from BIS.

Quote
Quote:writing exit to the last line of your scripts is totally pointless

Wrong.    This is a significant expansion on your original unsupported assertion that writing exit merely slows the game down.    Even if it does slow the game down it indicates to anybody editing the script - including yourself six months later - that the script is finished and there aren't 20 more lines that have been deleted by Windows for no reason and without a trace.    It also makes a comment line "this is the end of the script" superfluous.    It also allows you to add at the end of the file comments or other information useful for explaining, editing or generalising the script.    It is also aethestically more pleasing, thereby making the world a better place.  It also has a pschological benefit since it bestows a sense of completion on the proceedings.

Well if you want to mark the end of files just so that you will know it's the end, then by all means do it. I don't care how you spend your time.

:)
Quote
Your assertion is not logically sound.

It is my friend. Trust me on this one.

@Mikero

Yes that's one issue but I trust BIS so much that I believe their parser is good enough to know how to cope with that kind of situations, and still be faster than exit<eof>.

@Planck

That's how I also thought it works and thus it makes sense that checking the syntax of the line where exit is will take more time than not having an exit command at the last line.

CONCLUSIONS

1. Use exit if you want to at the last line of your scripts, but when writing it to your files please always remember that it is unnecessary. You can't hurt yourself or anyone else by using it, and it definitely is not a source of lag in your scripts so this is not a big thing. It's a very small thing but hey at least we managed to build up a good conversation about it!

:)

2. EOF has been found and I am closing this file now and releasing the memory used by it for better purposes.
« Last Edit: 13 Jul 2005, 17:01:17 by Baddo »

Bluelikeu

  • Guest
Re:Life time of a script
« Reply #23 on: 13 Jul 2005, 17:15:22 »
This conversation is not over.... ;D

Offline THobson

  • OFPEC Patron
  • Former Staff
  • ****
Re:Life time of a script
« Reply #24 on: 13 Jul 2005, 17:40:52 »
We all have baggage.  Let me tell you some of mine.  Many years ago when the size of a sector on a disk was 128 bytes (that is not a typo - I have not missed out a k) I was working with a commercial program.  I was just finishing off a job at a clients when the system started to crash while reading a file that it had previously created.  After a lot of frustration I found that when saving a file that was an exact multiple of 128 bytes it did not write an EOF to disk.  I raised this with the company that produced the program.  Instead of getting a ‘thanks for your help that was stupid of us' I got a terse note saying that it was done this way to save disk space because the EOF would then require an additional disk sector!  The fact that this then crashed their own programme seemed not to worry them.

I learned several lessons from this: 1)  I do not make assumptions about EOF;  2) I do make assumptions about programmers.


So when I read:

Quote
I can not imagine a reason why BIS would program OFP so that after EOF it would not release memory that was used to keep the local variables and the contents of the file if exit was not used. That would be a very stupid thing to do
 I agree it would be a stupid thing to do, but that is no reason to assume that it is not being done.

Quote
I trust BIS so much that I believe their parser is good enough to know how to cope with that kind of situations, and still be faster than exit<eof>.
I don't trust.

I doubt though whether this is an area we are going to save much time.  How many times does a script exit? - on average less than once for every time it is called.  We need to look at things that are executed repetitively to get any meaningful gain.


Offline Pilot

  • Contributing Member
  • **
Re:Life time of a script
« Reply #25 on: 13 Jul 2005, 17:48:27 »
Ok, I know nothing about C++, and what I do know about scripting I learned from tuts and experimentation, but I, a mere humble newbie, want to say something to you geniuses anyway (that is not meant to be derogatory!  I admire anyone who can write computer programs)

It appears that BIS can't make up their minds about the exit command.  I have de-pbo'd some of their missions and the Red Hammer campaign.  Some of the scripts have the exit command, some don't.  Even the same mission will have one script with the command and one without.  I don't think having this command or not having it affects the script in any way, or if it does, it is so trivial it doesn't matter.

I personally use the exit command just to make the script tidier and 'feel' finished.

-Student Pilot

Offline Mikero

  • Former Staff
  • ****
  • ook?
    • Linux Step by Step
Re:Life time of a script
« Reply #26 on: 13 Jul 2005, 18:44:46 »
@Planck

Quote
I'm not sure whether it starts a search for a goto label from the next line after the goto and once it reaches the end of the file, it starts from the top again........or.......IF it immediately starts from the top looking for the first instance of the label.

in a separate thread, not 100% confirmed but 99.9% there, ANY goto causes a search to begin at the beginning. To put it in your words, the following is a statement of fact

it immediately starts from the top looking for the first instance of the label

This (can) significantly contribute to lag.

>exit warz

for the same reason, any thought of what's logical about what this command should and shouldn't do, is a bit more than the aesthetics, niceties and personal preferences discussed here. The only thing I'll put money on as a certainty, is that there will be a difference in performance between having an exit statement and relying on EOF. Which of these is actually faster / more efficient, is moot, but a difference there will be, because Bis have NOT crossed all T's and dotted all I's, despite comment to the contrary.

@BlueLikeU

You are referring to a C fread() command or similar that ultimately 'knows' the size (length of) the script. This is entirely different to testing for it, which takes up, sometimes considerable, extra cpu crunch. Thus, it might surprise you to know that *many* parsers will crash because they do NOT test for it and rely on a <newline> instead. This 'problem' is so endemic that many parser engines have a 'lint' routine, something external to the game itself, that actually checks text files to contain an ending newline and add one if not.

Just say no to bugz

Offline h-

  • OFPEC Site
  • Administrator
  • *****
  • Formerly HateR_Kint
    • OFPEC
Re:Life time of a script
« Reply #27 on: 13 Jul 2005, 19:49:50 »
@Baddo:
Now, I did not try flame ya ;D
Just shared me thoughts on the matter...
And, for the record, I'm not a real coder, my coding experience with 'higher' languages limits to very basics of C... :)
I seem to miss the part of my useless brain that could make me comprehend such languages.. How I ever learned to script OFP is beyond me... ::)
And, I have never 'studied' filehandling etc either...

But, I agree with THobson that you put a bit too much trust in BIS :P ::)
After seeing that virtually every aspect of the game is in someway bugged/untweaked/heavy/etc I wouldn't go and expect these things we've been discussing to be flawless either... ;)
Project MCAR   ---   Northern Fronts   ---   Emitter 3Ditor
INFORMATIVE THREAD TITLES PLEASE. "PLEASE HELP" IS NOT ONE..
Chuck Norris can divide by zero.

Offline Baddo

  • Former Staff
  • ****
  • Reservist Jaeger
Re:Life time of a script
« Reply #28 on: 13 Jul 2005, 20:05:31 »
@Baddo:
Now, I did not try flame ya ;D
Just shared me thoughts on the matter...
And, for the record, I'm not a real coder, my coding experience with 'higher' languages limits to very basics of C... :)
I seem to miss the part of my useless brain that could make me comprehend such languages.. How I ever learned to script OFP is beyond me... ::)
And, I have never 'studied' filehandling etc either...

But, I agree with THobson that you put a bit too much trust in BIS :P ::)
After seeing that virtually every aspect of the game is in someway bugged/untweaked/heavy/etc I wouldn't go and expect these things we've been discussing to be flawless either... ;)

:)

I'm taking this very easily. Nobody has been flaming me here.

 8)

If we don't have any problems with leaving the exit away, then why should we include it? Less is better if it brings us the same result. No don't answer to that question, I already reached the EOF on this thread so it's dangerous to continue around this topic I might experience a cra

Offline alimag

  • Contributing Member
  • **
  • I'm a llama!
Re:Life time of a script
« Reply #29 on: 13 Jul 2005, 23:34:36 »
If I remember correctly there is NO exit command at the end of any of the unpbo original BIS mission. It seems that the creators of the game do not feel the need to put it.

I'm not sure but I think that should say something about it.

Cheers