Donnervogel

Well I think the addon system just causes too much hassle so the only way to promote addons in MP is to make them part of a larger "mod" or some addon pack or something similar that provides good missions (this is crucial). Many OFP servers provided addon packs that were needed to play on their servers so that was ok. But you need someone to make missions for those addons

Well I think the addon system just causes too much hassle so the only way to promote addons in MP is to make them part of a larger "mod" or some addon pack or something similar that provides good missions (this is crucial). Many OFP servers provided addon packs that were needed to play on their servers so that was ok. But you need someone to make missions for those addons

ey the swiss navy is top secret!! No reports, no pictures and no mods allowed! Or have you seen any? QuietMan unfortunately the glorious Swiss high seas navy was cancelled after a study found that Switzerland has no sea access

Well the "problem" is that the aiming hole is pretty close to the real one. But the thing is that the real rifle has 4 (actually 5) settings. You can adjust the visor thingy based on what distance you shoot at and also switch to a night visor. There is also a setting that requires you to use a screwdriver to take out a screw to change one of the high precission settings into an close combat setting. Then also for CQB soldiers are trained to not look trough he hole at all but look over it. we call it "reflex shooting". Anyway I find the hole is very good in the size for 150+ m which is quite a ususal distance I tend to engage enemy AI at. Obviously for CQB it is too small but the question is where do you want to put the compromise. Also keep in mind that the SIG 550 is a rather long range relatively high precission assault rifle and normal swiss conscripts are trained to use it with iron sights on 300m while many soldiers are not so well trained in urban combat where CQB would most likely happen

It's the OFP derived AI. Objects are obstacles for it. If the AI is close to an Object it "feels" obstructed. it has been like that since OFP. I don't know the exact problem but I suspect it's some general flaw in the engine that AI is unable to "interact" with objects. You can see ti with shooting but also with movement (good example is the FDF AP mines which the AI avoided since it "saw" an object in it's way so it went around it And about the cover. The AI goes to cover (or better it will stand around close to something it thinks is cover so the thing is between him and the unit it wants cover from - you can tell it to do so by scripting for testing) but it usually won't fire from there because of this reason discussed here. So it will step out of cover again in order to engage. Arma (OFP derived) AI is not able to interact with objects is what I think and I think it won't be really changed anytime soon. But hopefully they will at least enable it to fire over objects. We need a major engine expansion or Game2 to see proper interaction with objects I think

Well this certainly looks great. But I think the key question is if this works smoothly in MP. I hope is does great work.

from my experience this is quite realistic. There's always some idiot having forgot to switch safety on - sadly. besides it was just funny in OFP when for example the mission was finished and everyone was running back to extraction zone and someone fired unintentionally and everyone goes panic looking for cover, lots of chatter in voice coms "where did it come from?" - "sorry guys it was me..."

I think kungtotte wrote that FSM, I remember giving him some FSM advice on it when he was doing it.

I suspect your vertical position working is due to something else. Also it doesn't depend on the bounding box but on the position and the corresponding model. Syntax: object worldToModel worldPos Example: object is a tank worldpos is the position of the round the tank fired. now when you getPos the round you will get it's worldPos coordinates. But if you want the round position as an offset to the tank model center you use myTank worldToModel positionOfRound this works flawlessly for me. however if I do tankRound worldToModel positionOfRound it will return [0,0,0] (as the offset is zero as I compared the tankRound model center world pos converted to model space with itself and there is no difference).

uhm yes. it works good. Remember. If you request the model space coodinates of the object position (given in world pos) that the model space belongs to, then it will be [0,0,0] because it describes the (world) position of the model center. But if you use the coodinates of a different object/place/whatever then it will be successfully converted to the model space of the object specified in the command.

let's put it this way. If the terrain wasn't totally flat and if there would be crosswinds and if I didn't aim about 2-3 meters above the m1 (yes that did bit is pretty much above the turret on 630m) the round has just splashed into the ground But the point was not to show my 1337 RPG skills but rather to show how the courve in Kronzkys plot looks "in real" so I had do stretch it out to a similar distance that he used. Also I am in no way an expert on RPGs but with enough initial thrust a fin stabilised projectile can easily travel a flat courve over 630m.

Well the thing you see is after some time of flight (a distance of about 800m) of the round. I did more testing with 7.5 and the differences are. With 9.81 as Gravity I am +/-0.05m on target after 1 km. With 7.5 I am 0.2-0.3m too high after one kilometer. It increases with the same trend over larger distances. 7.5 ends up too high. There is obviously some derivation that I assume is from rounding errors and some OFP script engine delays or something. But it's really minimal. I mean I didn't set up this test to prove the point that gravity is 9.8. I just happen to have worked on it for some time already and I just wanted to tell you that for what I am doing 9.8 seems to be closer to the value ArmA uses than 7.5. I can't tell much about falling speed. but maybe it would help if you caluclated the falling acceleration from the velocity vector (if you didn't do it already) of the object that is falling.

well the differences are not that big for other places (on earth at least - it would be somewhere inside +/-0.2 I think) 9.8 is a "generic" mean value for gravity on sea level. what the picture shows, as I write, is that the calculation (using formulas from my physics book) match very well with what OFP produces when I use the value 9.8, That you don't see the projectile drop is something else. It does drop. that's for sure. But that path goes on for kilometers And it's not spawned. it's pure math plus visualising the actual flight path of the projectile fired from the tank.

it would be good if you told us how you did your testing Because my scripts work fine when using 9.8m/s^2 for gravity (calculating ballistic trajectory curves for tank rounds for example) So I don't see any "weirdness" with trajectory. Infact I see that the trajectories behave realistic (not meaning that the weapons behave realistic but the physics behind the projectile work pretty realistic) EDIT: here's a picture, green is the calculated path and yellow is the actual flightpath of the round. Looks pretty damn close to my calculations And it uses 9.8 for the gravity

Hehe... Cool! Who needs Excel, if you can just draw a 3D-graph, real-time, right in the game! yes the good thing about that is too that you sometimes see things you would never have thought. Like that RPGs can deflect too like bullets It's pretty cool when you shoot t the turret of the M1 in a steep angle and it just bounces off I love arma btw it's about the length of the runway on Rahmadi. About 630m