Rastavovich
-
Content Count
527 -
Joined
-
Last visited
-
Medals
-
Medals
-
Posts posted by Rastavovich
-
-
When it comes to OFP scripting I don't like jokes ;)
-
Quote[/b] ]Two issues with this, it is good practice to send everything to any function in an array, even a single variable. Â The reason is, if you screw up sending something in an array you will see some errors and will eb able to perort from the script with the problem. Â On the other hand, if you screw up sending witohut an array, the script dies before it starts. Â No debug possible. (you can literally get lost for ever on a large system with this)Second: Â save your passed variable to _x or _y whatever by using _x=_this select n; if you access _this select n more than once. Â This is more efficient in OFP scripting due to realtime parsing of '_this select 0' versus '_x'.
Your 2nd strongly depends on your first issue. If you pass only one variable (without array) the access for the game engine is as fast as if it would have to look into a placeholder.
But you are right creating placeholders when the variable is stored in an array and you have to access them more then once makes sense.
To your first point. You might be right there aswell, but I still prefere the only variable thing for myself and have no problems debugging it. But since you do the more complex programming you should have the better experience with it, so people (especially code newbies) should probably use your method.
PS: Thnx Dinger, I have allready enough pc trash here. BTW, what trigger functions are you talking about.
-
One good think in scripts is aswell if you try to avoid sin/cos functions.
Another issue I often see is the declaring of an variable and then the variable is a static value.
I also have seen quite a lot that ppl call a script [_this select 0] ....
and have then to use inside the script.
_x = _this select 0
instead of using
(_this select 0) ...
and then working inside the script with
_this
as the passed variable/object.
Those are all small issues, but especially the sin/cos stuff can ruin your fps when used wrong.
You should suspend/exit scripts as often as it is possible without it will affect something.
ie: You have a duster script. Over a certain height you could simply use ~5 or so to suspend it (for greater heights even greater values are possible), since those scripts tend to have quite some checks in it.
-
We dont use a script, it is the default radar of OFP. That should allready be the fastest possible implementation.
But we scan atm 15 km around the Tung (a 30 km circle, so over the map borders). This is not really necessary and it wont make the Tung fire earlier (well we could make it fire earlier, but then flying in OFP would be real hell).
-
The lag might be caused by long range radar of the tung, we will reduce the range, so hopefully it will run smoother. But it will take some time untill we release that version.
-
AFAIK that is caused by the way the OFP engine handles animations. It will allways wait untill an allready started animation has finished.
Vehicle alive animation have most time long animation periods, so it take some time to end that one, before the dead animation can be played.
So my guess would be, if you shorten the animationperiod, you have a quicker death.
-
How come I need OFP v1.92 to use this addon ? I already have v1.94B, but it still asking me for v1.92.. anyway to fix this ?Sorry fo the delayed answer.
Make sure you start the flashpointbeta.exe instead of the flashpointresistance.exe, else your game would run on 1.91 instead off 1.94.
Quote[/b] ]This is just a suggestion, I've never edited a vehicle in OFP......But why not have the two missile racks seperate? Like, you have to cycle to them? So you'd have Rack 1 and Rack 2, Rack 1 would fire missiles from the left rack, and rack 2 would fire missiles from the right rack.
Unfortunally that wouldn't solve the problem, since still only one firing point is allowed, so the both racks would share this point.
-
The Group Uplink links 4 Tungs of an group to an network. Only one Tung has its radar on and is visible on radar while the 3 other tungs get their data from the active one. So 4 tanks are rdy to fire,but only one is visible.
If you place a group of AI tungs and let a plane fly over it you can see how that works.
To all those who want a zip file. The .exe here is a Winrar self extractor, so no installer. There will be no info written to your registry nor will it behave in any other way shitty.
-
Well then the complete config might be usefull.
BTW: those values here don't change the firing behaviour of a sniper. The only change the firing range of the bullet.
-
Well, I tried it with the following code and it worked.
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; Syntax in initline of gun is: (this) exec "script.sqs"
? format ["%1",side _this] == "EAST" : _enemy = ["WEST", "RESISTANCE"]
? format ["%1",side _this] == "WEST" : _enemy = ["EAST"]
_gunner = gunner _this
_i = ((getdir _this) - 90) Mod 360
_i2 = 0
_posarray = []
#calculate
_posarray = _posarray + [[((getpos _this select 0) - cos(_i)*30), ((getpos _this select 1) - sin(_i)*30),0]]
? _i2 < 5 : _i = _i - 36, _i2 = _i2 + 1, goto "calculate"
_i = 0
#checkposition
? (format ["%1",side nearestobject (_posarray select _i)] in _enemy) : unassignvehicle _gunner, exit
? _i < 5 : _i = _i + 1, goto "checkposition"
~0.5
? !alive _this : exit
_i = 0
goto "checkposition"
BTW, you don't need the units name. You only need to know if it is enemy.
Edit: The 2 lines directly under #calculate are infact on line in the code, the 2 lines under checkposition aswell.
-
Of course it returns your gun, since you look for the nearest object around your pos, which is your gun.
You need to search some meters away (~30 meter behind the gun)
-
_badguy = nearestobject [_pos]
(No "," in the array)
should work.
Should return you the mggunner itself.
-
right...there is no getnearestobject, I just wrote it out of my mind.
nearestobject [positionarray] will return the nearest object -no matter what type- found around there.
After getting the object you can filter it (mainly over "side" and "distance").
-
well you should use getnearestobject.
Set the checkpoint around 20-50 meter behind the mg nest and check lets say every second. Then you should filter the returned object (if an object is returned).
Maybe you could also use 3-5 checkpoints, so you can check a wider field behind the gunner position.
-
Look at the cockpit section and you would recognise that the pic is no Lancer.
Infact the bomber shown on the pic is russian.
It is an Tupolew Tu-160 "Blackjack".
-
The OFP Addon Manager doesnt create those problems, it solves them (if used correctly).
I should know that, I wrote it.
-
That might be possible with full magazines, but not with magazines with only a few shots left.
-
Why dont you test his monitor on your machine? then you know if it is the monitor.
-
In both statement lines you use komma instead of semicolon between the orders, that might screw it a bit, else the error message would be handy.
-
Nice version, but the groundhandling is still far away from being perfect. It is still impossible to taxi on the airfields and the brake of the mig need some major improvement (can't explain why it needs 300 meter to brake down from 20 to 0).
BTW: check your pm SEA DEAMON.
-
We did some further testings and now the problem seems to be a bit different to my first post:
clients can read out the animationphase, but the dedi server itself cannot.
Could someone confirm that?
-
AFAIK, the animation points and selections are in the memory lod.
-
If that problem was reported before, please close this topic (didn't found anything likely over search).
The problem is the following: the server should animate a selection while the clients set textures, depending on the animationphase the selection has.
So the client read out the animationphase on a not local vehicle (vehicle is local to server). But it seems it cannot read it out correctly: vehicle animationphase "selection" seems to return most of the times "0" even it it should be something else, ie : "1". Randomly it seems also to return a correct value,
but most of the time it is simply the wrong value. The strangest part is, that the animation works correctly, so you can see that it moves, simply the "animationphase"-command cannot read it out.
On non-dedi servers this problem doesn't occure.
-
Mig-29 are quite expensive to maintain, at least for german Luftwaffe (keeping all replacement parts for only a small armada of planes is not very cost effective).
Good editing practices
in OFP : MISSION EDITING & SCRIPTING
Posted
Well scripts like the net services are really rare in the OFP community. There are only around 5 different "complex" scripts packages (including most of your scripts). Most scripts are around 10 - 20 lines at most and of a real simple nature.
Those simple scripts are most times simple to debug, even under different conditions.
As I wrote you do the complex stuff, so you have most experience in complex debugging and that way you are right that it makes sense to stick to your pratices.
Dinger: I do it like: one variable --> no array, more then one --> array (ofcourse). I dont have to remember that since I used that so often that I simply write (..) when only one variable is needed (which is infact around 70% of my scripts).
It is a thing of being "used to".
But I say it again, Bn808 and you are right, it is easier for ppl in general and they should stick to it (so forget what I wrote . But I am an waisted old bastard scripters who wont change his way of scripting in his old days (maybe I do, dunno yet).
Other good practice: Use a "clear" variable name. This way it becomes easier to read the code when you have to look through it some month later (or in case someone else look into your script). I think that a clear variable name even justifies a longer name (ok: _i is really often used for _index, I do it myself, so lets keep that;)