OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: funkster on 11 Sep 2005, 04:12:12
-
Hi all,
Just a quick question. What am I doing wrong here?
@ (unitReady WAfour) ((WAfour doFire Emtwelve), (setAccTime 0.1))
Thank you muchly!
-------------------------------------------------------------------------------------------
EDIT: O, I think I need square brackets right? Im off to try this.....
-
Hi, use this
@unitReady WAfour
WAfour doFire Emtwelve
setAccTime 0.1
-
LOL, thanks. Thats so simple, for some reason, i thougt it all had to be on the same line...
I am eternally indebted to you my good freind....
-
Ive unsolved this thread cause I have another issue (not just syntax).
When I use the line :
@unitReady WAfour
WAfour doFire Emtwelve
setAccTime 0.1
It is in a cutscene, when the tank is ready to fire, it goes into super slow mo, and fires.
This works, however, the unit fires maybe around, I dont know, a second, sometimes longer after commanded to, hence ruining the whole scene.
So, what I wish I could do is addEventhandler ["fired", go into slow mo] !
But there is no such event handler, nor is there a unitFired command which I could use.
I cant think of a way to tell the script to execute certain commands instantly after a selected unit has fired....Can anyone tell me a way to do this?
Thanks.
-
Ive unsolved this thread cause I have another issue (not just syntax).
When I use the line :
@unitReady WAfour
WAfour doFire Emtwelve
setAccTime 0.1
It is in a cutscene, when the tank is ready to fire, it goes into super slow mo, and fires.
This works, however, the unit fires maybe around, I dont know, a second, sometimes longer after commanded to, hence ruining the whole scene.
So, what I wish I could do is addEventhandler ["fired", go into slow mo] !
But there is no such event handler, nor is there a unitFired command which I could use.
I cant think of a way to tell the script to execute certain commands instantly after a selected unit has fired....Can anyone tell me a way to do this?
Thanks.
Well, in this situation you would probably want to use a fired eventhandler:
WAfour addeventhandler ["fired",{_this exec "fired.sqs"}]
fired.sqs
_unit = _this select 0
_mags = magazines _unit
{_unit removemagazine _X} foreach _mags
_unit removeeventhandler ["fired",0]
exit
-
O ok, thanks.
So there is a 'fired' EH after all huh? Its not listed in the EH tut....
Thats good to know, but what is the code you have given me for - fired.sqs?
why do i want to remove magazines? Wont OFP remove each magazine automatically every time a unit fires?
Cheers,
funkster
-
O ok, thanks.
So there is a 'fired' EH after all huh? Its not listed in the EH tut....
Thats good to know, but what is the code you have given me for - fired.sqs?
why do i want to remove magazines? Wont OFP remove each magazine automatically every time a unit fires?
Cheers,
funkster
Wow, what kind of tut left out the fired EH? Its probably the most important one of all! :o
-
the code he gave you will stop them from firing a sencond time, which is what you asked for ;)
-
Nononono, you have misundersood me.
What I wanted was for the scene to go into slow mo, as the tank fires, then go back to normal speed.
What happens currently, is that it goes into slow mo, and simultaneously execs doFire, however, you can wait for around 10 seconds or more (1+ seconds in real time) before the tank fires. This ruins the cinematic effect, I want the script only to go into slow mo AS the tank fires, rather than before.
Using Kyle's suggestions, I have implemented an event handler to detect when the tank fires;
WAfour addeventhandler ["fired",{_this exec "fired.sqs"}]
However, I have created the following code as "fired.sqs"
~ 0.05
setAccTime 0.1
WAfour removeEventHandler ["fired", 0]
~ 0.8
setAccTime 1
EXIT
So, in theory, only when the tank has "fired", does "fired.sqs" get called (which then implements slow mo for ~ 0.8 seconds).
In reality, I find that often, what may happen is it can go into super slow mo for around 20 seconds, the tank hasn't fired yet, and only when the tank has fired (after 20 secs or more )does the script exit and return to normal time.
What does this suggest? - That the "Fired" EH can be true, even before the unit has fired, sometimes it is true when the unit is attempting to fiire, but cant aim properly....
* Anyyway, so how can I ensure my script is called only at the exact moment that the unit DOES actually fire?
* And why does is "fired" EH true, even before the unit fires???
Thanks lotz.
-
In reality, I find that often, what may happen is it can go into super slow mo for around [qoute]20 seconds, the tank hasn't fired yet, and only when the tank has fired (after 20 secs or more )does the script exit and return to normal time.
What does this suggest? - That the "Fired" EH can be true, even before the unit has fired, sometimes it is true when the unit is attempting to fiire, but cant aim properly....
* Anyyway, so how can I ensure my script is called only at the exact moment that the unit DOES actually fire?
* And why does is "fired" EH true, even before the unit fires???
Thanks lotz.
Please don't make assumptions, when you assume, you make an ASS out of U and ME. Now to solve this with my magic thread solving powers. Make sure you get rid of the command you were using before to slow down the time. I know whats happeneing, the time is being slowed down from SOMETHING ELSE, and only after the "setAccTime 1" from the fired EH is executed does it return to normal. The fired EH only fires when a unit fires, I thought that would be obvious, so the source of the "setacctime 0.1" executing too early is something else that you must have forgotten about, which is probably the original method you tried. So find that command, remove it, and everything should work fine.
-
No, thats not whats happening.
The setAccTime 0.1 ONLY gets called through "fired.sqs"
"fired.sqs" ONLY gets called through the "fired" EH.
There is varying times between when the time slows down, and when it returns to normal, suggesting the code gets suspended / stuck somewhere in the middle of fired.sqs.
fired.sqs is a small script, printed a couple of replies above, so I wont copy it again.
The only thing that it could get stuck on I think, is the removeEventHandler command, I suggest that the fired EH gets called ddue to something happening (like conditions are good for a shot, and the unit is told to fire, but for some reason is not quite ready to), and then it gets stuck on the removeEH command, which it cant execute until the unit actually does fire - or something like that.
It cant be what you suggest Kyle, because I only have the setAccTime command through the fired EH, nowhere else, so it has to be this that is causing it to be called early somehow......
???
------------------------------------------
EDIT: PS, ill double check my script, just to make sure nothing else is causing it, but Im 95% sure I dont have any other command that could cause it to happen..... Away from home cpu right now, but find out b4 long.
-
on the contrary funkster, what YOU are suggesting is absolutely impossible. event handlers don't just fire because the tank was able to, or was told to, they fire because the tank fires, and only when it fires, no more, no less. if the time slows before the tank fires there IS SOMETHING ELSE causing it.
more importantly, if someone trys to answer the problem that YOU COULDN'T SOLVE, never, NEVER throw it back in their face. out of sheer respect for the people trying to help you, even if their idea or attempt doesn't work, you THANK them, because if they didn't try to help you, you'd never figure it out.
here's a suggestion:
show us the mission, so we can see for ourselves what is happenning, and end this useless bickering
-
No, thats not whats happening.
The setAccTime 0.1 ONLY gets called through "fired.sqs"
"fired.sqs" ONLY gets called through the "fired" EH.
There is varying times between when the time slows down, and when it returns to normal, suggesting the code gets suspended / stuck somewhere in the middle of fired.sqs.
fired.sqs is a small script, printed a couple of replies above, so I wont copy it again.
The only thing that it could get stuck on I think, is the removeEventHandler command, I suggest that the fired EH gets called ddue to something happening (like conditions are good for a shot, and the unit is told to fire, but for some reason is not quite ready to), and then it gets stuck on the removeEH command, which it cant execute until the unit actually does fire - or something like that.
It cant be what you suggest Kyle, because I only have the setAccTime command through the fired EH, nowhere else, so it has to be this that is causing it to be called early somehow......
???
------------------------------------------
EDIT: PS, ill double check my script, just to make sure nothing else is causing it, but Im 95% sure I dont have any other command that could cause it to happen..... Away from home cpu right now, but find out b4 long.
Ah I see now, and in that case I believe I can solve your problem. Actualy I'm sure you can figure it out if I give you this hint, ~0.8 is not 0.8 seconds when acctime is equal to 0.1 ;) Also, just triplecheck everything because it sounds like there is something else slowing down the time before the unit fires.
Also, if a script comes accross an error, it won't pause, but keeps on running untill it is told to finish. And, yea, don't say I'm wrong I do know what I am talking about.
-
Hello All
Just passing through an I thought that I'd chuck in my two cents.
Here's a fundamental query for the community - does the "~pause" command refer to computer clock speed or does it refer to some sort of "game" speed ?
In other words, if I "setAccTime 0.1", then have a line that says "~1", does the script wait 1 second or 10 ?
It's a simple query to answer (pity I'm at work !). Simply write a script that does this
setAccTime 0.1
~1
SetAccTime 1.0
hint "Hello world !"
Now all you do is run the script and time the delay until the hint is displayed - I'll bet that it will be 10 seconds.
If this is the case then there is the answer to your problem.
If not then I'm stuffed too !
Cheers
Roni
-
Hello All
Just passing through an I thought that I'd chuck in my two cents.
Here's a fundamental query for the community - does the "~pause" command refer to computer clock speed or does it refer to some sort of "game" speed ?
In other words, if I "setAccTime 0.1", then have a line that says "~1", does the script wait 1 second or 10 ?
It's a simple query to answer (pity I'm at work !). Simply write a script that does this
setAccTime 0.1
~1
SetAccTime 1.0
hint "Hello world !"
Now all you do is run the script and time the delay until the hint is displayed - I'll bet that it will be 10 seconds.
If this is the case then there is the answer to your problem.
If not then I'm stuffed too !
Cheers
Roni
Yes thats what I was trying to hint to funkster, that when you slow down time in the game, you actualy slow down ALL time, anything in seconds is also slowed down. so 0.8 seconds in 0.1 acctime would really be ~ (approx) 8 seconds.
-
If that's true then "~pauses" are linked to script cycles and not the PC clock. This could lead to all sorts of grief !
I remember my first draft of a time dilation script that I wrote (all fixed now !). At first, all I did was write a simple "skipTime _delay, ~1" loop, then discovered that the faster computers were actually travelling through time faster ! I was getting sunset for some players and sunrise for others !
I fixed it by having the server action the skipTime then shout the new game time (_hostTime) to the network via a publicVariable declaration. The client machines versions of the script simply caught this variable and skipped forward just enough to catch up (skipTime (_hostTime - daytime).
Intersting to see that the actual loop times might also have been different too ("My ~10 is faster than your ~10 !")!
Roni
-
on the contrary funkster, what YOU are suggesting is absolutely impossible. event handlers don't just fire because the tank was able to, or was told to, they fire because the tank fires, and only when it fires, no more, no less. if the time slows before the tank fires there IS SOMETHING ELSE causing it.
more importantly, if someone trys to answer the problem that YOU COULDN'T SOLVE, never, NEVER throw it back in their face. out of sheer respect for the people trying to help you, even if their idea or attempt doesn't work, you THANK them, because if they didn't try to help you, you'd never figure it out.
here's a suggestion:
show us the mission, so we can see for ourselves what is happenning, and end this useless bickering
Kyle:
First off, sorry Kyle if you thought I was being rude, I was not, only impatient. There was no offence intended.
As for the time, I know that the time is not the same, I put ~ 0.8 because Iwanted 8seconds of slow mo. What i am getting is around 15- 30 seconds, now in normal time, 1.5 - 3 seconds is a long time to wait for a unit to fire once it is supposed to...
Triggerhappy:
talk about overreacting buddy! thanks, my ears are ringing!
Frankly, the only reason I wrote something like that was because Kyle wrote "never assume, it makes an ass out of u and me" which I thought was rather rude - I was only asking a question after all.
Yeah I was a bit out of line there, but still,
There was no need to come down so harsh about the whole thing - I found it rather patronising actually...
"On the contrary, what you are suggesting is impossible..."?
I never said anything was impossible?
Yes, you are probably all right, I was probably wrong, Im about to go and check my script. I do appreciate all the help that people give in this forum - very much!
;D
-----------------------------------
EDIT:
Like I said, Ill go and check the script to see if something else is causing the slow down, if not, then Ill post the miission, but I dont know where to host it, its around 5MB.
-
Hi again,
I have checked the script, its not something that is happening there, from what I can see, Ill post all the script towards the end (the relevant section) here so you can see. If anyone knows where I can host a 5MB or so mission, then Ill post a link to it.
>>~ 2
_cam camsetrelpos [35, -18, 11]
_cam camsetFOV 0.73
_cam camcommit 7
WAfour doTarget EMtwelve
WAfour selectWeapon "HEAT120"
~ 1.4
WAfour addeventhandler ["fired",{_this exec "fired.sqs"}]
~ 0.1
WAfour doFire EMtwelve
WAfour setBehaviour "COMBAT"
WAthree setBehaviour "COMBAT"
~ 1.1
EMseven setCombatMode "RED"
EMeight setCombatMode "RED"
EMnine setCombatMode "RED"
EMten setCombatMode "RED"
EMeleven setCombatMode "RED"
EMtwelve setCombatMode "RED"
WAthree setCombatMode "RED"
WAfour setCombatMode "RED"
WAfour doMove getPos EMseven
WAthree doMove getPos EMtwelve
_cam camsettarget getPos EMnine
_cam camsetrelpos [0, 0, 200]
_cam camsetFOV 0.7
_cam camcommit 43
~ 30
titlecut [" ","BLACK OUT", 4]
5 fadeSound 0
5 fadeMusic 0
WAthree saveStatus "a1stat"
WAfour saveStatus "a2stat"
exit
Any ideas?
Thanks.
-
Hi again,
I have checked the script, its not something that is happening there, from what I can see, Ill post all the script towards the end (the relevant section) here so you can see. If anyone knows where I can host a 5MB or so mission, then Ill post a link to it.
>>~ 2
_cam camsetrelpos [35, -18, 11]
_cam camsetFOV 0.73
_cam camcommit 7
WAfour doTarget EMtwelve
WAfour selectWeapon "HEAT120"
~ 1.4
WAfour addeventhandler ["fired",{_this exec "fired.sqs"}]
~ 0.1
WAfour doFire EMtwelve
WAfour setBehaviour "COMBAT"
WAthree setBehaviour "COMBAT"
~ 1.1
EMseven setCombatMode "RED"
EMeight setCombatMode "RED"
EMnine setCombatMode "RED"
EMten setCombatMode "RED"
EMeleven setCombatMode "RED"
EMtwelve setCombatMode "RED"
WAthree setCombatMode "RED"
WAfour setCombatMode "RED"
WAfour doMove getPos EMseven
WAthree doMove getPos EMtwelve
_cam camsettarget getPos EMnine
_cam camsetrelpos [0, 0, 200]
_cam camsetFOV 0.7
_cam camcommit 43
~ 30
titlecut [" ","BLACK OUT", 4]
5 fadeSound 0
5 fadeMusic 0
WAthree saveStatus "a1stat"
WAfour saveStatus "a2stat"
exit
Any ideas?
Thanks.
Make sure that WAfour doesn't fire ANY weapons after it is given the eventhandler and before you want him to, because that will set off the eventhandler (grenade throwing, and placing of mines and satchel charges counts as firing too).
-
Thanks Kyle :)
No, he is actually set to CombatMode "BLUE", so there's no chance of him firing before he is told to.
You can see why I think that the fire EH is being set off before it actually fires right....? I mean, what else could it be?
-----------------------------------------------
O, btw,
WA refers to West Armour - M1A1s,
While EM refers to East Man,
so the situation is im waiting for the M1A1 to fire a HEAT at a Ruski solder.
-
Well, having stumped me, there is only one thing left to do. Attach the mission (in a .rar or .zip file) to a post (the Attach: box down at the bottom) so I can take a look at everything.
-
funkster, you should probably put a wait until thing ,@, somewhere in there to wait until the fired script is done.
And I have 2 questions:
1. How long does it take for a heat to reload?
Because that might have something to do with it.
2. Does the fire EH simulate firing as in the bullet leaving the chamber (tank shell in the barrel) or pulling the trigger (clicking the mouse while reloading and because of the reloading no bullet comes out)?
-
hmm, thanks guys.
Merc:
thats what I was originally thinking.
Maybe its loading the HEAT...
But I didnt think that it could be the computer 'trying to fire' while the ammo aint loaded, that actually an interesting idea....but sounds unlikely.who knows?
as for the @ command, I dont understand how that would help... What exactly do you mean?
Kyle:
Id like to attach the mission, but I was saying before that its 5mb. If I find some site that will host downloads for free, then Ill post a link, but I dont know where would do that...
ANy0ne know of place?
Cheers.
-
www.rapidshare.de
The @ command is a wait for command, its used just like a "?" except without the ":". For example:
_ammo = WAfour ammo "HEAT120"
@ WAfour ammo "HEAT120" < _ammo
<the rest of your script>
And as stated MANY times before, a fired EH can ONLY fire if the unit ACTUALLY fires, as in the weapon is able to fire and does succesfully fire. NO EXCEPTIONS.
Second, selectweapon will NOT work for Heat ammo, since it is a magazine not a weapon. The only way to make the AI to select Heat is remove all of his Sabot rounds (WAfour removemagazine "Shell120"), and if you want him to get it reloaded quickly, remove the weapon and add it again:
WAfour removeweapon "Gun120"
WAfour addweapon "Gun120"
WAfour selectweapon "Gun120"
I can't garuntee that it will make the reload instantanious, but it will make it shorter. You might want to set the units skill to 1 (all the way to the right) and call the above code at the begining of the scene.