Metal Heart

No problem

It's not a name, it's sort of a special pointer to the unit that the local player controls. It's pointing to a different unit on every client's computer, and since the "respawn.sqs" is also running _locally_ on each client, it works. However, if a player disconnects, the AI that takes control of his unit will from then on respawn with the weapon because it's not a player. Makes sense, eh?

It's not a name, it's sort of a special pointer to the unit that the local player controls. It's pointing to a different unit on every client's computer, and since the "respawn.sqs" is also running _locally_ on each client, it works. However, if a player disconnects, the AI that takes control of his unit will from then on respawn with the weapon because it's not a player. Makes sense, eh?

Lots of tutorials, scripts and command reference with examples & comments: Operation Flashpoint Editing Center ... You can also setup respawn without triggers... for a quick example with very simple instructions: 1. in main menu-> press multiplayer-> new-> select "new-editor" 2. place player 3. place marker named "respawn_west" (otherwise you'll respawn where you died) 4. save mission as "Respawn example" or something 5. alt+tab to desktop 6. create file description.ext to ofp/users/username/MPMissions/Respawn example.Intro: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">respawn=3; respawndelay=5; onLoadMission="Respawn example"; 7. create file init.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">~2 [] exec "respawn.sqs"; 8. create file respawn.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#start @NOT alive player @alive player removeAllWeapons player; goto "start"; 9. That's it. Make sure you have file type extensions visible so you don't have files ending like respawn.sqs.txt if you create them with notepad

Lots of tutorials, scripts and command reference with examples & comments: Operation Flashpoint Editing Center ... You can also setup respawn without triggers... for a quick example with very simple instructions: 1. in main menu-> press multiplayer-> new-> select "new-editor" 2. place player 3. place marker named "respawn_west" (otherwise you'll respawn where you died) 4. save mission as "Respawn example" or something 5. alt+tab to desktop 6. create file description.ext to ofp/users/username/MPMissions/Respawn example.Intro: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">respawn=3; respawndelay=5; onLoadMission="Respawn example"; 7. create file init.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">~2 [] exec "respawn.sqs"; 8. create file respawn.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#start @NOT alive player @alive player removeAllWeapons player; goto "start"; 9. That's it. Make sure you have file type extensions visible so you don't have files ending like respawn.sqs.txt if you create them with notepad

Yeah, obvious if you have done scripting or made mp missions before, I think that is not the case here. You shouldn't assume that everyone in the world automaticly knows all the things you consider obvious. One extra trigger hardly makes a noticeable difference but I do agree

Yeah, obvious if you have done scripting or made mp missions before, I think that is not the case here. You shouldn't assume that everyone in the world automaticly knows all the things you consider obvious. One extra trigger hardly makes a noticeable difference but I do agree

They should've gone OpenGL from the very beginning and we might not be having this conversation. Hell, maybe we'd be merrily playing ArmA on Linux-Box instead of OFP:E on X-Box.

Newton's 3rd law: "For every action, there is an equal and opposite reaction." The bullet & gun scenario is often used as an example of this law. It only seems that the bullet has more energy than the gun because it's something like 400 times smaller in mass. The same force that is accelerating the bullet out from the barrel is also accelerating the gun in the opposite direction. I'm quite sure that the atmospheric pressure doesn't have a significant effect to the forces caused by the explosion inside the barrel. I'm not going to pretend that I understood anything about your gas reflection and amplification theories though

Glide has pretty much nothing to do with OpenGL, it's the programming interface for the legendary 3Dfx Voodoo cards, while OpenGL is an Open Graphics Library that works on almost every card, programming language and on most operating systems. I don't see any reason why they'd include OpenGL, it's not just a quick hack like allowOpenGL="Yay!"; you know. While including Glide support might've been a good idea when they started making OFP (because 3dfx cards were so common back then), I'd say adding OpenGL support to ArmA doesn't seem like such a good move now. Unless of course, they're actually going to make a Linux version, then I'm just talking out my ass here.

Just using alive player condition doesn't work because, well, it removes all weapons when ever the player is alive. If you don't want to use a respawn script, you can use 2 triggers and a variable like this: (note that this works locally on each player) -Reset variable playerdead=0; in some units init line or init.sqs -Make trigger1: set activation repeatedly condition NOT alive player AND playerdead==0; on activation playerdead=1; -Make trigger2: set activation repeatedly condition alive player AND playerdead==1; on activation removeAllWeapons player; playerdead=0; Only problem is, that the triggers work somewhat slow, so it takes a fraction of a second before weapon is removed. Someone might shoot you before trigger2 kicks in and grab your rifle. This could be a problem if you're making a mission with only pistols, for example. So, it's better to use a respawn script. If you want to add load-out automaticly, add it to trigger2 on activation, and if there's more playable sides besides west, you need to use triggers with side condition to get them their corresponding load-outs.

Just using alive player condition doesn't work because, well, it removes all weapons when ever the player is alive. If you don't want to use a respawn script, you can use 2 triggers and a variable like this: (note that this works locally on each player) -Reset variable playerdead=0; in some units init line or init.sqs -Make trigger1: set activation repeatedly condition NOT alive player AND playerdead==0; on activation playerdead=1; -Make trigger2: set activation repeatedly condition alive player AND playerdead==1; on activation removeAllWeapons player; playerdead=0; Only problem is, that the triggers work somewhat slow, so it takes a fraction of a second before weapon is removed. Someone might shoot you before trigger2 kicks in and grab your rifle. This could be a problem if you're making a mission with only pistols, for example. So, it's better to use a respawn script. If you want to add load-out automaticly, add it to trigger2 on activation, and if there's more playable sides besides west, you need to use triggers with side condition to get them their corresponding load-outs.

Obviously it doesn't, but only because a rifle has much larger mass than a bullet, therefore the bullet attached to the stock wouldn't gain anywhere near the speed the one that is fired does.

Unfortunately, OFP (and thus ArmA, as far as I know) uses DirectX for gfx, sound and input so Linux version is quite unlikely. You might have some luck with emulators, at least I've heard someone's been able to get OFP running on Linux.

Well, uh, the original question was about shadows, I didn't mean that they're 3D in OFPE.

Here's some MP differences that come into mind comparing to GR: (prolly has some mistakes, I'm no GR expert, only played it through once a long time ago) +actual weapon sights +free aim, crosshair is not locked to the center of the screen +no crosshair at all on many servers +weapon sway, insted of exaggerated inaccuracy like in most games +realistic weapon sway when moving, arms hit or out of breath +ballistics (bullets are drawn towards ground by gravity) and ricochet damage +huge maps (standard islands about 50-90km^2, max 625km^2 or so) +realistic navigation with compass and map, or even the stars +lots of freedom in missions, no "invisible walls" or artificial boundaries blocking the way or guiding the player +NO heart-beat sensor or whatever that thing is +loads of transport, armored transport and combat vehicles, including air craft and naval units, every vehicle can be used by players +lots of great mods and addon weapons, vehicles, islands etc +dozens of very different mission types, from corridor DM/CTF to real time strategy with hundreds of units on huge maps +players can commmand 11 AI soldiers, even more with some scripting. Almost total control over AI, they don't just follow you around or move by preset waypoints. +acceptable view distance, about 1km on most servers (said to be about 2km in ArmA) +...and more -poor cheat and fake ID protection (might be fixed with ArmA) -relatively lot of cheaters in public servers for such an old game, and they don't even cheat to win, they just ruin games on purpose (so don't expect that great mp on open servers), mostly on CTF, C&H and CTI missions though -max players on internet games only about 30 (probably more with ArmA) -quite out-dated gfx without mods/addons (better with ArmA) -same deal with the sounds, there's good sound mods also -3rd person view on some servers Hehe, that came out as a bit longer rant than I had expected Well, what the hell...

Isn't this already in ofp:e at least to some extent?

Dohhh... No, it's nothing like BF and it is completely hetero, rest assured. I suggest getting OFP Game Of The Year edition while waiting for ArmA, shouldn't be more than 15€ or so and it's basicly 3+n games in one edit: Next Ghost Recon?

Equal numbers doesn't mean equal teams. You know, like in OFP it was rather common in pvp mp, for experienced players to team up against noobs.

It'd be better to let the admin handle JIP, not the players. Like the way admin can lock players to slots in OFP. So initially if the mission is JIP capable, you jip first as a spectator and then the admin decides what to do with you.

If they were models wouldn't they be scaled just like everything else?

It's very simple to come up with the ideas of "things", I'm sure BIS have considered about ragdolls, every graphics effect in the book and whatnot. It's making them happen what's hard, and takes lots of time and resources. And contrary to what many seem to believe, not everything is possible with current home computers, like some of the stuff you'd except from a standard corridor shooter, is simply not possible in a larger scale sim like ofp unless you accept one digit frame rates or smaller battles. I'd much rather have the processing power used for things like better AI, more units in missions and drawing the terrain at realistic distances than ragdolls or some other quite useless features (useless as in not really affecting gameplay).

I'd guess you'd need iron sights made for widescreen. Since they're just 2d pictures it shouldn't be too much work to mod but if you play MP on public servers it could be a problem. On the screen shot, squished sights don't look so bad that I'd go through the trouble though.

Hmmh, don't really like zombies, but Aliens, now that could be some scary stuff. Just imagine a giant horde of those mother*beep*s attacking your home town at night or something

That would be impossible. Sure, some basic "building blocks" of the simulation (like gravity or air friction) can be used in many different scenarios but it's quite impossible to do one magic algorithm that can simulate everything just like that. Basicly, you just approximate how something would behave, like a car or a plane, a box or a rope, and add a block of code to the engine that simulates just that, not make one universal simulation that starts from atoms and ends up in galaxies flying trough space and can simulate everything in our universe (I guess it could be possible but the processing power needed would be incomprehensible).