Sefe

You can find the respective thread here. Feel free to step into the discussion. Note that you also need the permission of the mission makers who are not listed in this thread before you can change a mission name. You are not on the safe side whatsoever if you haven't asked the mission maker before you rename the mission, wether he's in this thread or not.

Well, I don't know which so called version of OFP you run on your so called computer, but I run v1.85 and this is what I have done: The skill of all units is set to medium, daylight, clear weather, no fog, open terrain. In my OFP the Tunguska which replaces the Shilka doesn't recieve a single hit (because the so called threat settings don't identify it as dangerous for tanks) before it mows through the western tank rows. I don't know which so called circumstances you had to create to make east lose but you seem to live in your own so called reality anyway. How else could it be explained that you come up with some abstruse theories about streams of exploading bullets weakening tank armours with the heat created by the explosions? Hey Einstein, why do you think so many billions are spent in developing anti-armour ammunition when there's the magic Tunguska ammunition that can penetrate modern composite armour by simply warming it up a bit? You called others pathetic. Well do you want to know what I think is pathetic? It's pathetic when people (not mentioning any names) ask for constructive critizism and then can't deal with the critizism because they obviously can't accept that the reality looks different than they would like it to be. You declare the Tunguska to be a lethal tank killer. Could it be that you're adjusting realities to suit your image of the world as it should be (as opposed to what it is)? Your image of the Tunguska is so way off that I'm wondering why I'm even wasting my time with this discussion. Well, in fact I'm getting sick of this children shit. Do the Tunguska as you want it to be, but don't ask others for their input if you're not mature enough to accept it. I for my part will do myself (and maybe also you) a favor and won't reply to this thread anymore. Oh, by the way, thank you that you tried to please me. I'll try to please you in return: I'll keep may opinion about the overall quality of your config.cpp file for myself. You wouldn't be able to deal with it anyway.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Gen.Carnage @ Oct. 25 2002,17:12)</td></tr><tr><td id="QUOTE">try that same equasion with the tunguska beeing blown up after one hit? as said before, its armor was too heavy and is corrected.<span id='postcolor'> Have you tried the mission? The Tunguska isn't even being shot at.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Gen.Carnage @ Oct. 24 2002,15:23)</td></tr><tr><td id="QUOTE">the only thing that will be turned down is its armor, its firepower is relative to other tanks as in real life<span id='postcolor'> This is rediculous. Here's a schematic of the GAU-8A: You can see that half of it's length is just the magazine. And when you compare those pics you'll see the reason why: These are 30 mm lightweight rounds, fired by an Apache M230 automatic cannon: This is a 30 mm DU round to be fired by a GAU-8A cannon: Just to say "same caliber + same rate of fire = same performance against armoured targets" simply ignores basic physics. A GAU-8A round is a kinetic energy round. That means the armour penetration effect is simply achieved by the kinetic energy of the shell, not by explosion effects. The formula for kinetic energy is E(k) = 1/2 * m * v^2 E is the energy, m is the mass and v is the velocity. Hence the kinetic energy is increasing with the mass and the velocity. That's the reason why AP rods are made of DU or tungsten carbide, those materials are very dense (while being hard enough to penetrate armour) and therefore combine high weight and a low volume. And the propellant charge is that big to give the projectile a high velocity. The additional effect of DU is that it's self-incidentary. Ie., while penetrating the armour the rod ignites and releases a spray of fire to the inside of a tank that either kills the crew or makes the tank catch fire. In AA-guns you usually use self-destruct fragmentation rounds and a proximity fuse. Ie. they explode when they are close to the target and release fragments that can penetrate the relatively thin armours in aircraft. It's absolutely neglectable if the round explodes at 100 m or at 4000 m, because the effect is achived by the fragments, not by the velocity of the shell. The only thing that the gun has to do is to get the shell to it's target (while the GAU-8A also has to give the shell as much kinetic energy as possible - that explains it's massive dimensions). Due to their fragmentation effects, AA shells have no armour piercing and no incidentary effects. Maybe you can load the Tunguska with AP rounds but due to the considerably smaller propellant charge, it's much less effective than the GAU-8A ammo. You can't even penetrate the front armour of the M1 with the GAU-8A. Shooting at an M1 with AA fragmentation rounds is as good as throwing rocks. And as for the missile firepower, the SA-19 missile has a warhead weight of 9 kg. And this is also a fragmentation warhead, ie. there's no armour piercing effect - in contrast to a LAW that uses a HEAT (= high explosive anti-tank) warhead. So three missile shots to crack an M60 surely isn't realistic. And that the aircraft is thrown back by the shockwave may be spectacular but don't you wonder how 9 kg of explosives (most likely it's much less than 9 kg of explosives - don't forget the fragments that are also in the warhead) can have such an effect on a multi-ton aircraft? If that doesn't convice you that the Tunguska is too powerful, I'd suggest this sample mission (try it, it's real fun). Set up a duel west vs. east. West: 4 x M1A1, 2 x M60, 2 x Vulcan, 1 x Apache East: 3 x T-80, 1 x T-72, 1 x Shilka, 1 x Hind Play the mission and you'll watch how east gets busted by west. Now replace the Shilka by a Tunguska and play the mission a few times. In about 80 % of the cases the east will now win. Even if the Tunguska would be realistic (which it isn't), every mission maker with the slightest sense of mission balance wouldn't use the Tunguska in his missions.

Thank you very much. Now rectractable landing gears for choppers and other cool stuff will become possible.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (ACES_KEVIN @ Oct. 23 2002,00:51)</td></tr><tr><td id="QUOTE">Maybe not completely 100% realistic but still a kickass fun addon to play with.<span id='postcolor'> *cough* Not completely realistic? I was able to kill an M60 with a two-second burst of the gun. That's the firepower of the A-10's GAU-8A cannon which fires armour piercing ammunition in the size of milk bottles, not anti-aircraft fragmentation shells. The Tunguska wins every 1-1 duel with an M1A1 (!). When you hit an aircraft with the missile it's thrown back about 30 meters. Three missiles can kill an M60. Well, you can call that "not completely realistic". Over all, the gun is too accurate and too powerful. The missile's punch is much too big and the armor is way too strong. The Tunguska needs to be tuned down massively.

I was trying to have custom actions added to soldiers inside vehicles. But there are two bugs that hold me away from reaching this target: My first attempt was to add the action to a section of the vehicle in the config.cpp file: class UserActions { class MyAction { displayName="Select me"; position="volant"; radius=1; condition="true"; statement="hint ""This is a test"""; }; }; That works fine from outside the vehicle and also from inside the vehicle as long it doesn't move. But as soon as the vehicle starts moving, the action disappears. That's bug number one. To work around this problem I tried write a script that adds the action to the directly unit inside the vehicle (not to the vehicle itself). That led to strange results: Most of the time the action doesn't appear in the action menu while the unit is in side the vehicle. As soon as the unit leaves the vehicle, the action appears and it disappears again when the unit re-enters the vehicle. Sometimes however (and this is the strange thing) the action appears on the action menu even though the unit is inside the vehicle. That makes me pretty sure that it's a bug, not a feature.

Yeah, I fully understand that. And I will use preprocessors whenever I need return values. This really is a big step ahead. And I understand that you need the timeout to make return values work. But I was talking about sqs files. I don't need return values when I use an sqs-file. And sqs files are generally processed in real time. The code in sqs-files is even executed in real time within {}-brackets. This sample can prove that: _MyVariable = "" if (time > 60) then {_MyVariable="Test"; Goto "Label1"} Exit #Label1 Hint Format ["%1", _MyVariable] will work in a 'regular' sqs-script even though it uses goto (which would cause an error in a preprocessor). You need to init _MyVariable first though, otherwise it would be considered private inside the if construct. What I actually thought would be good is to introduce the option to have multiple-line while statements in real-time (not preprocessed) scripts. At the moment two different commands are seperated by either a CR/LF or a semicolon (I'm still talking about 'old style' sqs scripts). So the codes _MyVariable = "Test" Hint Format ["%1", _MyVariable] and _MyVariable = "Test"; Hint Format ["%1", _MyVariable] do exactly the same. And in the first option you don't need a semicolon at the end because CR/LF is as good as a seperator as a semicolon. But you need the semicolon in the second line because you have two commands in one line. But yet the script is still executed in real time, right? What I suggested was to ignore CR/LF while you are in a while or if construct (like you ignore them in preprocessors). The result would be that while you are in brackets, you couldn't seperate two commands by a CR/LF. But there would still be the semicolon you can use as a seperator. Here's an example: At the moment, this construct is possible within an sqs file: if (time>60) then {_MyVariable = "Test"; Hint Format ["%1", _MyVariable]} while this construct leads to an error: if (time>60) then {  _MyVariable = "Test";  Hint Format ["%1", _MyVariable] } The only difference between these two code snippets is that the second one contains CR/LF. Now if the interpreter would ignore all CR/LF from if to }, both snippets would be interpreted exactly the same. And as we're not in a preprocessor, all of this is executed in real time. Well, we can't have return values for this reason but when we need return values we will use preprocessors, not 'old school' scripts. But the real problem is that we can't use the ~ and @ in the same line as other scripting commands. So this is possible: _MyVariable = "Test" ~1 Hint Format ["%1", _MyVariable] while this isn't: _MyVariable = "Test"; ~1; Hint Format ["%1", _MyVariable] Therefore we need commands that do the same as those operators and that can be executed in a single line. I know that those commands wouldn't work in preprocessors, but why shouldn't they work in a real-time script? If we had the aforementioned Wait command, we could have this construct without even changing the interpeter: if (time>60) then {_MyVariable = "Test"; Wait 1; Hint Format ["%1", _MyVariable]} and hence, with the slight changes in the interpreter code that I suggest we could have this construct: if (time>60) then {  _MyVariable = "Test";  Wait 1;  Hint Format ["%1", _MyVariable] } Voilŕ, ofp scripting language suddenly becomes structural. And it would still be fully backwards compatible. Nothing that worked in the old interpreter would stop working in the new one.

My point is not exactly that ~, @ and goto are not allowed. I don't need goto when I have while and if. And if all other scripts are halted, sqf-files are useless when you want to exectue parallel running scripts (like me). My point is more that the following code is not allowed in a sqs file: while {_this >= 0} do {  Hint format ["%1", _this]  _this =_this - 1  ~1 } The interpreter needs the whole while thing in one line (which makes ~ and @ arguments impossible). Having block structures forced in one line is rather... er... unusual. BIS has shown that it is possible to interpret arguments broken up in multiple lines (in sqf-files). I know that the ; as seperator makes that possible. That's why C and Pascal want (almost) every argument to end with a semicolon. But I can't imagine it too difficult changing the interpreter code so that it ignores all LF/CR from the while or if to the final }-bracket. You could then force all commands inside the brackets/quotes to end with a semicolon (no compatibility issues here). Most probably this wouldn't even need a change of interpreter code as the semicolon already is a seperator. If you then introduce two new commands to replace ~ and @ (like comment replaces the semicolon), you can interpret the whole code inside the {}-brackets the same way you interpret preprocessors (except that they ere executed in real time). Maybe I want too much but as long as we don't have block structures in sqs-scripts, we have to solve the whole countdown thing with: #Loop  ? _this <= 0 : goto "Skip"  Hint format ["%1", _this]  _this = _this - 1  ~1 goto "Loop" #Skip which is a bad style of programming. And it gets even worse if you want to do if... then... else... constructs. With my suggested changes of the interpreter the whole thing would look much neater (presuming that the command that does the same as ~ is called Wait): while {_this >= 0} do {  Hint format ["%1", _this];  _this =_this - 1;  Wait 1 }

Well, with v1.85 we now have "while... do..." and "if... then... else..." constructs. This is a big step towards structurized programming. Well done BIS, this is what I've been waiting for a long time. Until v1.85 you had to use "goto" to create loops. "Goto" constructs are commonly considered to be a bad style of programming and the new commands give us the opportunity to create block structures like in C or Pascal. However after a series of tests, I (unfortunately) found out that the current system suffers from some serious deficiencies. I was hoping to be able to rewrite all my scripts with the new scripting commands but for a large number of scripts this is impossible, making the new commands worthless for many cases. I'll give you a little exercise. Let's see if anyone can find a solution. Could anyone write this simple script for me: It's a script that accepts any integer number > 0 as it's only parameter. Then it visibly counts down from this number to 0 in steps of exactly one second. That's all. Well, not completely. You may not use the following commands in the script: goto exec drop It doesn't matter if you execute this script with Number exec "ScriptName.sqs", Number call loadFile "ScriptName.sqf" or Number call preprocessFile "ScriptName.sqf". But it mustn't use a trigger or a game logic during it's execution (ie. it has to run independendly). Apart from that you can use any method: loops, recursion, preprocessors, what you want. And you may use as many files you want.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (GranQ @ July 11 2002,03:59)</td></tr><tr><td id="QUOTE">i am testing with replacing the "notebook" with something else.. so far it just crashed the game when i call the dialog.. is there anyone that find anything on what to do?<span id='postcolor'> May I kindly direct you to this thread in the OFPEC forums. You'll find a sample mission with some other objects that can be used as a 'canvas' for dialog elements. There are even more...