chris330

Hi, Hope someone from Bohemia reads this I have a suggestion for a new command. I have a suggestion for a new command which does all the things enablesimulation false does, but still allows animations to run on vehicle control surfaces, sounds to behave normally, and for the player and AI to interact with the vehicle entirely as normal and collision detection to still occur. This and the new setvector commands basically would give very detailed and competent scripters the opportunity to build their own physics from scratch into the game, to have complete and total control over the vehicle in question, unhindered by the game engine trying to apply forces to the vehicle such as gravity for example causing odd behaviour to occur. At present to get really precise control over a unit only disabling simulation works, but that knocks out a tonne of other things too which would look too unrealistic to be useful. Reasoning: I've been trying to script a C-130 to go down a runway and then gradually have it's pitch increased then lift into the air at +5 or +10 degrees say. The code works fine when tested with enablesimulation false. When piloted by AI the plane trys to react in some way, when piloted by the player there's still some odd stuff going on, and even when the player just sits in the cargo seat bizarre behaviour still occurs. Even an empty plane behaves just as oddly and erratically at some moments. Reason being is the game engine is trying to apply forces to the vehicle in ways it thinks best. A simple setpos loop run at 0.001 seconds delay works ok but as soon as you try and combine this with a velocity component things go seriously haywire. I've spent maybe well over 100 hours actually testing this since the first engine came out back in 2001. In the Hercules example above the behaviour would be roughly right but you'd often see odd +/-2m wobbles after a time when the aircraft was lifting off the runway and when doing other things. With simulation disabled it runs beautifully. I've tried going right into the concept of time updates in scripts to try and run the position and velocity and orientation updates bang in synchronisation with the game engine loop but that doesn't work entirely satisfactorily either: http://forums.bistudio.com/showthread.php?t=89014 A command which could disable the engine applying forces and position and orientation updates to a vehicle would enable me to for example build an entirely new and realistic flight or tank control model from scratch for example. At present the game is not reliable enough to do this. A simple command to turn off collision detection would also be useful as I was thinking of trying out that too. This could be done by making a model with no Geometry LOD but that's a horrid patchy way around things. Far better to actually turn it off for that unit and remove alot of CPU overhead. Finally some commands enabling the user to activate manually through scripts things like tank track animations and aircraft control surfaces animating would be fairly essential too. With that I could compute for example the animation phase of a wing's aileron or elevator and combine it with my own flight model so it would look realistic. A good flight model wouldn't be much good without proper animations to go with it ;) These commands woud put the game's potential into the stratosphere and they aren't involving anything to be 'added' to the game, just for certain things to be turned 'off'. Thanks :)

Yegads... bugger just tested it and found the same thing myself. I'm goona make a special command request now.

That's good information alright mate thanks

Hi pal try this one. Use pretty much any values for the first two entries in the first array but leave the third entry in it blank. Used like this the first array controls only bearing. Must be of form - [x,x,0]. The second array must only contain [0,0,-1]. This will flip your aircraft upside down. The script is run to hold it at that position. I hope that helps ;) Your Mission

Wow that really is interesting. Never knew about it. Will the engines still make a sound and everything or does it lock all aspects of the vehicle's behaviour? This could be a solution to something I've been looking at.

Hi thanks for the reply. Your use of the command sleep is a much conciser way of what I was doing: _elapsedtime = 0; _timeincr = 0.001; while {true} do {_elapsedtime = time; waituntil {time > (_elapsedtime + _timeinr)}; }; Both methods do however work by using a time delay which could straddle game engine frames. I did a test in Flashpoint and found anything which used a time delay often overshot a great deal. It can be proven by using a computed time versus actual time script. If you run some code with a hint showing two variables and make one of those variables time and the other expected tme based on a loop update of exactly what you would expect based on the designed in time delay - the computed time will lag the real time like mad because it's executing so much slower. Here's an untested demo: _timedelay = 0.001; _computedtime = 0; while {run} do {hintsilent format["Computed time = %1\nActual Elapsed Time = %2",_computedtime,time]; sleep (_timedelay)' _computedtime = _computedtime + _timedelay; }; Should produce a value of computed time which increase much slower when really if the script was executing with only a delay of 0.001 seconds they would be exactly the same. Explanation for newcomers or inexperienced folks: What is happening here for those who don't follow is - the game engine is updating the reserved game internal variable 'time' with each frame increase. You could think of this as 'hard' time. This does not mean the amount of actual elapsed time is the same per game engine frame though, but it means this is the very accurate right up to date time recorded as the game engine goes through its loop over and over, and acquires a new value for time on each occasion probably using the computer's internal clock. Computed time or 'soft' time *should* increase at the same rate *if* each execution truly were only delayed by 0.001 seconds. What was often found was actually the time delay was alot longer than 0.001 seconds which this script should prove. However That still doesn't really suggest that the script isn't executing fast enough to be at a high enough resolution to prevent any nasty game engine frame straddling as was correctly stated by ruebe. All it means is it just isn't consulting the computer's internal clock to get it's time reference, instead it's just relying on an unreliabe and unrealistic way of computing time with a fixed variable. I've just thought of a way to test this actually. I wonder if you could try: Untested! _mytime = 0; while {run} do {_mytime = time; [b]waituntil[b/] {time > _mytime}; hintformat ["Time Difference = %1",(time - _mytime)]; }; This relies on how frequently the game consults the variable when using the waituntil command. I suspect this *might* be done every game engine loop so would thus produce an uber accurate script loop update and keep it's execution right in time with the game engine. This is turning into a deep subject! I think this is what I'm working on now until I understand it all ;) ---------- Post added at 04:18 PM ---------- Previous post was at 03:35 PM ---------- I captured a picture of the time versus computed time in action. It's too big to show here and I don't have an image editor but it showed the following values: Computed Time: 1.54202 Actual Time: 28.584 ---------- Post added at 04:30 PM ---------- Previous post was at 04:18 PM ---------- Given the computed time loop is incrementing by 0.001 per run we can work out that: 1.542/0.001 (ignore the 4th and 5th decimal place it's a small error common to the game) = 1542 so 1542 loops have occured in the actual elapsed time. The actual elapsed time is 28.584 seconds so: 28.584/1542 = 0.019 seconds rounded to 3 decimal places. So with a time delay of 0.001 seconds the actual execution time per loop is 0.019 seconds which equates to: 1/0.019 = 53 loops per second. Now I could draw the conclusion that given that 0.019 seconds is so much longer than 0.001 seconds that obviously that's why I'm getting odd anomalies with setpos loops when executing them on vehicles which have a velocity (are in motion). But that's not correct. 53 loops per second sounds rather close to what you might expect the game's frame rate per second to be. So in actual fact it is executing quite fast and *might* even be in dead tandem - or perfectly synchronised - with the game engine's update time. I know I can work out how many frames the game loop is making per second by making use of some 3rd party software but I don't know how to do that. Does anyone? Is there some function in my graphics card driver or something that I can open to do this? Help! If I can get a solid number for actual game frame rate per second, and then contrast that to script loops per second, I can really see when something is in dead in time with the game engine's frame rate and thus not suffering from frame straddling. ---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ---------- This demo mission shows time difference per loop, average time difference over all loops, and loops per second which *might* be equivalent to frame rate but I'm not sure. Time Testing Mission The LPS does indeed vary exactly how you would expect a frame rate count to vary. It increases as you look up at the sky and decreases when more objects come into view. _mytime = 0; _i = 1; _starttime = time; run = true; while {run} do {_mytime = time; waituntil{time > _mytime}; hintsilent format ["Time Diff = %1\nAvg Time = %2\nLoop Rate = %3 LPS",(time - _mytime),(time - _starttime) / _i,1 / (time - _mytime)]; _i = _i + 1; };

I'll check in later tonight and have a look. It's easy enough to do and once you've got it figured once - you've figured it for life ;)

I still probably won't be able to work it out :D Thanks for posting that that's great! I wish everyone was helpful like you. If I can work out what's happening in my thread about update times I might make use of this instead of that function I wrote to setpitch. If you want F2k Sel I'll send you that mission I wrote where I did it. I could set vehicles upside down with it without any problems, although that might be different from gradually increasing their pitch like in a loop scenario.

Ahh!! Nice spot I never knew that cheers pal :)

Some highly well informed replies in this thread!!!

Thanks for the reply and the good info it contained ;) **I've just written a getpitch function and setpitch one too so I might give them a go now with that see if I can get it into the air like you said. I like the idea of simulating of rocket lifting, after watching some youtube vids that thought entered my head too ;)

I've blathered on alot about things I've suggested on here long enough so I thought I'd actually do something as it's been too long. Early stages of scripted takeoff script. Ok this one is also based on Utes. It used an empty plane with a disabled AI piloted moved into it. A regular plane would work just as well. The player is put in the cockpit next to the pilot. The plane is held by a script which waits for the Alpha signal radio. Once it gets the signal to start through a variable called 'go' the plane uses a while loop to slowly increase the plane's speed, and some trigonometry to keep the plane pointed at the target game logic called 'runwaylogic' you can find on the map. The plane does not takeoff yet and will either crash or exhibit very weird behaviour once past the game logic. Also if it gets above the specified input speed in the script launch command the script will disengage and the AI will take over and ...... bang. There's no setpositioning or AI input here at all, all this is done legitimately through the setvector commands to keep the plane upright and a trig altered setdir loop to keep the plane pointed at the target game logic. Trigonometry was also needed for the setvelocity loop as without it the plane looks like it is skidding towards dead West all the time and the velocity components in the setvelocity loop need updating to keep track of the vehicle's heading changes even when they are quite minor. Some momentum affected behaviour can be seen when you get near the target logic it seems the setvelocity command doesn't kill off all the vehicle's momentum and completely set it in the new direction. Some is retained and the vehicle appears to slightly skid. Interesting stuff! Maybe later this week or weekend I'll work on the next bit which is pitching the plane up on its rear wheels and pushing it into the air before handing over to the AI. Using this script you could actually make *anything* takeoff even a truck assuming it didn't blow up at 180 mph! Have some fun playing around with the 'runwaylogic' game logic's position in the editor as the plane will always aim dead for it and accelerate no matter what! :D Important: I've enjoyed making this so consider it a gift just for you because you asked the question and prompted me to have a great time! EGO is the constant enemy through life and no doubt to many this script will even at this stage seem quite complex. I am quite happy to spend as much time as is needed to show anyone else how to do this and thoroughly explain how it works so don't be afraid to ask - I won't be sitting atop my ivory tower basking in the exclusive rays of my own overblown glory, because if I pursue that attitude my life will turn sh*t, fast, for reasons I can't discuss here. **Edit I was incorrect in my statements about the setvelocity command. When I tried this with the player as pilot the plane's motion was perfect right up to the end. With the AI as pilot which is the default loadout on this mission as comes in the download you can see lots of aileron (pilot applied turning attempt) applied on the wings which adds a force which slight pushes the aircraft South as it moves. Seems the disableAI "MOVE" still doesn't really well, disable the AI :)

Ok here it is: Parachuting demo mission with two scripts, one to load troops into the plane and one to eject them. As said the first script loops through the units in the player's group and loads them into the Hercules. This happens so fast you don't see it. When you're ready activate radio channel alpha (I think it's press 0 twice then 1 can't remember tho!) and the next script will activate and cleanly unassign them from the vehicle then issue the "EJECT" action for each soldier so they open their chutes. All works nice and clean ;) **If you want some explanation how these scripts work just ask. You can open both of them in Notepad. To use this demo you'll need to extract the zipped folder and place the mission folder (the folder that contains the scripts and mission.sqm file) into your 'missions' folder in ArmA 2 and access the mission from the Editor mission name Jump Demo.

Hmm I'll have a look at this later tomorrow. First off I'll make a C-130 in the editor and jump out with a regular soldier (me) in cargo and see if a chute opens automatically. If it does then you can run a loop script to just use the unassignvehicle command on each unit. Just be sure you don't execute it on the pilot though! :p If no-one else had answered by tomorrow I'll make a quick demo for you.

You could try a setvector dir loop script along the runway and then slowly increment his pitch using the setvectordirandup command and then give him a setvelocity push into the air. This would force him to follow a set realistic takeoff path then make sure he has a waypoint to handover to once up and when the script exits. I do not know how to use scripts with time delays in ArmA 2 though I cannot work out how to simulate the simple old way we did it in .sqs format for Operation Flashpoint. Until someone throws some light on this I can't help you further. Anyone know how this is done using only .sqf files? Can you use an FSM to do it? Once that object's surmounted I can make a rough demo script which you can modify if you're still that interested in working on it, or want such a refined solution - there may be a much simpler easier way than what I've suggested.

Ok I actually managed to get a red ball in game using Brsseb's crate tutorial config from OFP! Once I'm happy with it all I'll post up a simple resume of what's needed in case anyone else journeys through tis topic in the future :)

It looks very good.

Langnasen makes some interesting points and makes them well too. Not sure he should be *moderated* for that either. If I had to call it I'd say the versatility and moddability of the game and the nice visuals are well worth the asking price. Also when it comes to the amount of commands available to the user Bohemia appear to have really listened and made loads and loads more available. You can do almost anything you like now. ArmA 2 is about to teach me a shed load of stuff about game programming and physics engines through stuff I'm able to work on using the editor and for that I'm really grateful. I paid about £20 for it it's worth every penny ;)

That's really good exactly what I was hoping for thanks ;)

Hi I just happened across FSM Editor in the BI Tools download. Things like these have a habit of interrupting what I actually want to work on - I have a project running now. I have a very excitable nature though I've got a disorder which makes my brain hyperactive (asperger's) and makes it very hard for me to be relaxed and rational and when i see stuff like this I get so excited about their potential I can overload and think like 9,000,000,000 thoughts in 1 minute for a whole hour and be exhausted for the rest of the day. So I'm going to ask instead of racing off full throttle trying to find out for myself. What generally can FSM's do? They sound very capable indeed, just what can they be used for? I'm aware of two types. User made and Native. Native being engine coded and un-editable *I think*. My questions are: 1)Do the Native FSM's run constantly without being started manually throughout the entire life of any given AI unit? 2)Can you read what state the Native FSM machine is in - i.e. what the unit is doing? Likewise can you do the same for a User Made FSM? 3a)Could it be used to alter the way AI commander's give orders to their drivers depending upon what state the commander's combat and movement FSM is in? 3b)Could you basically disable AI movement yet still have the Native FSM run which handles target detection and response so you could input your own desired AI behaviour when, for example an enemy was detected? 4)If 3b) cannot be done by interacting with the Native FSM, can a User Made FSM be built that mimics the Native FSM's functions like registering enemies detected and such like and use these as triggers to initiate User Scripted responses? Thanks!

Can anyone throw some light on this? I could tbh research it myself but I'm in the middle of a big chapter in my maths work for uni. Anyone who knows anything about it feel free to chuck it into this thread ;) Thanks for moving it by the way.

You know exactly what depravity refers to, your intellect gives this away - and you are being argumentative and point scoring for the sake of it, even in the face of rational and calm analysis. You sound exactly like I used to be all the time. You present attitude is not worth conversing with any longer, I know this from having been the way you are. Live as you wish, accept the consequences of your own actions and choices good and bad and blame no one else for them :)

You may be right. We could argue all day about whether or not the presence of unpleasant things subtly affects other areas over time or not. I suspect it does. I also suspect it does alot of subtle harm to those who play it for no real reason such as the GTA games. It's not like it's depicting violence for the sake of demonstrating in a realistic way an important part of history or anything. It's just depravity for the sake of it. But. No-one has the right to tell you what to play or watch. Absolutely not. That must never happen. Free will must be exercised always. Even to the user who wishes to watch or interact with something unpleasant. Ultimately I believe the life an individual lives is a product of the quality of their own actions and intentions. And they must be allowed to complete that process themselves 100%. Have a good think though whether or not the subtle effects of allowing your consciousness deep into an environment like the one in Fallout 3 is good for you. That's all I will say, just consider what it is you're interacting with, and make sure you're ok with that choice. Beyond that people need to stay out of each others way unless one person specifically asks for help from another sector. Trying to oppose that which others are doing on the grounds of morality to try and 'contain' or 'prevent' something growing in the world or any given environment - just frustrates and brings down good people who should be minding their own business, and also prevents others from experiencing a lesson they ultimately either deserve or need to have. Play what you choose, do what you like ;)

Is this a brand new build? Must have taken forever, dimensionally it looks perfect. This is a really good addon.

It's funny you mention Fallout 3. I was just thinking about it when I read this thread. I've just bought it and played it twice. It's going to the charity shop. It's the only way I can imagine anything as utterly horrid as that piece of filth could ever do anything good - to make money for a good cause by being donated and then sold. One of the things I've always loved about Bohemia is that the games still adhere to a solid sense of drawing the line once something has been represented well enough. They have a very good clean feel to me rather than the horrid pursuit of utter revulsion and depraved terror that games like Fallout 3 go after. No I would not like to see that kind of adult content in a game I really like as it would pollute it with things I want kept away. If you want depravity goto a sex club or rent a good educational DVD about child abuse or open a good history book or better yet just play Fallout 3.