The_Captain

I think I might have to cave in and use this, even if just for the debug log. (caCommsLogic globalchat format ["blah %1",blah]; is getting a bit tiresome. I already have my own implementation for most of the above components, so I wonder if it would be worthwhile to use the SPON implementations instead. (key eventhandling, local client commands/events, network broadcasts & client requests). I think I'm most interested in addPermanentAction and broadcastObjectVariable. I might want to look at your key handler and local/global eventhandlers though. 1) Is there built in always-on network traffic that I can turn off? I'm trying to have the absolute minimum of network traffic. 2) How many functions and scripts are running by default on the client machine? I don't want to be running more than what is necessary. Also, I used your spon_statusdisplay (and looked at the code) and found out the awesome trick: if you return true from a key handler, you override the default arma key behavior!! This is a real nugget of info that has seriously helped me out. I was trying my own map replacement, and my solution was to close the map displaypermanently, also killing gps, compass, and watch.... Thanks a lot! (The map is display #12, btw)

SP = Meh. Skirmish and MP = fun. In SP, the computer throws horde of dumb units at you at close range, which is very boring, and it spoonfeeds you objectives a la Call of Duty. However, in multiplayer you get to control a small force and cooperate with other players and try to dominate an entire map. This is where you get a bit of tactical planning. However, it's a tad twitchy: you still need to micromanage a lot, but in multiplayer, you only have 4-6 units to deal with so it's not too bad.

One thing I sometimes do to make positioning/sizing easier, is to come up with a target resolution for the screen; eg, 1280x1024. Then in image coordinates, I say x=512/1280 eg: ((1280-256)/2) y=256/1024 eg: ((1024-512)/2) w=256/1280 h=512/1024 That will give you a centered picture in the proper pixel ratio for a 1280x1024 screen, but I think people with slightly different aspects are ok, as long as you select the right aspect ratio in options for your resolution. (EG, if you have 1280x1024 and you select 5:4, your images will be as clear as someone with 1024x768 and 4:3 aspect).

Very nice screenshot! It has a good "soft" feeling without being photoshopped. Looking forward to this.

I saw that! For some reason I can't post comments. "Community Configuration Project As part of this patch, we would like to formalize community oriented approach towards fixing and improving some of the aspects of the game configuration files. [...] we hope to see a few simple config fixes contributed by the community in the final patch." That sounds incredible. I think high up on my list of fixes would be some of the TrueMods gameplay enhancements (transition fixes, dispersion, sway, etc), updated recoils from one of the good sources (Q1184 or Truemods), fixed manual missile control from anyone who has a good implementation (IE, TOWs from SLX mod), red's model fixes, and added 'binoculars' dummy weapons to the commander turrets of BMP's and shilkas: without a dummy weapon their commander mode is broken. Can be fixed by adding weapon binocular in parent definition of 'tank'... Heck I think I'll make my own small config fix pack with a few changes and submit it when the wiki is up.

Those T-55's will be very welcome in a frontal assault. (Shielding the T-72's and T-80's from sabot rounds...). Great stuff guys!

Quick comment: In the ICE popup menu, it says "press backspace to close" When pressing backspace, you bring up the arma command menu by default. From what I can tell from displayeventhandlers, if you return 'true' inside the handler code it overrides the default arma key behavior. (this works for display 46, the main display, not sure about dialogs). So if you do this, you might be able to prevent opening of the command menu (and forcing players to close it again) when they close the popup menu. Learned that trick from Spooner's status display. Very nice missions... though I've only tried them in the editor. Need to find them on a server.

Okay, I think I know what battlefield clearance is now, thanks to the VBS2 VTK website: "Handling of wounded and enemy VBS2 now supports battlefield clearance (dragging wounded), and the ability to command POWs (who may surrender depending on their situation and morale)." http://virtualbattlespace.vbs2.com/index.p....emid=79 This is sounding good.

Suma talked about wanting/planning to add firing out of non gunner positions in the sahrani radio interview with jerry hopper, and (I think) mentioned that moving around in them was not planned.

There's probably also a difference between recommended player counts and supported player counts. IE, perhaps the official game modes will only support 32 players with 8 AI per player. Given how much bandwidth that would all need, it sounds reasonable. However, that doesn't mean the game won't support more, just that their official maps/mode have that as a reasonable limit. We'll see.

I think the problem with using a killed eventhandler is that when the player dies, the handler adds the action instantly.. to the dead player. You need to add it after they respawn. So, when you run the eventhandler, have it run a script which waits until the player == the player (as norrin outlined), and it should be fine.

Spooner, over at OFPEC, released a simple attachment script. http://www.ofpec.com/forum/index.php?topic=30607.0 It's via the action menu, but it could probably be modified to be done through the gear menu instead. While it's not necessarily proper for soldiers to be attaching and detaching bits from their weapons midbattle, this feature is nice when you want to use both the ACOG and iron sights on the same rifle: as is, if you have an ACOG you can't use the back up sights, and a simple script like this allows for both. Some kind of weapon attach/detach system in arma 2 would be nice.

Your paa files need to be in multiples of 2 as mr. burns said, and probably compresed in DXT5 format (so they get mipmaps). If someone has a resolution lower than, say, 1024x768 and they try to display your image which has that size, they'll crash. Also, when i try to open up buymenupaa and transfermenupaa they crash my TexView2. BuildMenu and Menu are both 1024x768 and should be changed (or maybe even made as dialogs instead of images). Haven't tried it yet but I'll give it a shot soon. EDIT: This is pretty inefficient, but you can always increase the size of the image to 1024x1024 (add black bars on top and bottom) and resize the image in your dialog to these coords: x = 0; y = -.1666; w = 1; h = 1.33; This will put the 'black' parts of your image above and below the screen. When you make the PAA files, make sure they are dxt5 compression...

From what I have seen of OFP2, they have much more detail included in every aspect of the game. This would seem to require much more network traffic than in Arma, where clients generally "figure out" what they're supposed to do from limited information. Example: In arma you damage a humvee's windshield, it turns a "broken glass" texture which the client figures it should display. If in ofp2 you get individual bullet holes and other detailed damage effects, you're going to need more MP communication. This extended level of detail throughout the engine would seem to push the total number of players down from what an engine like arma can handle, but I'm merely speculating. Plus, 32 players is probably enough for 'most purposes' anyway.

Okay, I poked around my OFP directory. General barron did have a formation script within handsignals, but you're right, it was much bigger. Turns out the simple follow was by toadlife. This might be what you're looking for? I remember this one being pretty useful for me, too... Follow example mission\nby toadlife http://toadlife.net call with: [units gw1,[man1],5,180,5,0.5,"careless","auto"] exec "follow.sqs" <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredversion "1.85" ; This script will cause unit or group of units to follow another unit or group of units without joining ; any group ; Initialize this script with the string below: ; [[leaders],[followers],distance,degree,leeway,checkinterval,behaviour,position] exec "follow_toadlife.sqs" ; ; ** [leaders] = an array of units which will be followed, can be only one unit. Must be in array format! ; ** Example: [soldier1,soldier2,soldier3] ; ** [followers] = an array of units that will follow the leaders, can be only one unit. Must be in array format! ; ** Example: [man1,man2,man3] ; ** distance = Distance followers must stay from leaders ; ** degree = position relative to leaders followers will stay relative to the direction the leader is facing ; ** Example: 0 = directly in front of leader / 90 to the right of leader ; ** leeway = distance followers can be from their currently assigned position before they must move again ; ** checkinterval = how often the followers check their position releative to the leaders position ; ** behaviour = the behaviour of the followers ("careless", "safe", "aware", "combat", "stealth") ; ** position = position the followers will assume ("auto", "up", "down") ; _leaders = _this select 0 _followers = _this select 1 _dis = _this select 2 _degree = _this select 3 _leeway = _this select 4 _checkinterval = _this select 5 _behaviour = _this select 6 _position = _this select 7 "_x setbehaviour ""_behaviour""" foreach _followers "_x setunitpos ""_position""" foreach _followers goto "move" ~1 #check {if (!alive _x) then {_followers = _followers - [_x]}} foreach _followers {if (!alive _x) then {_leaders = _leaders - [_x]}} foreach _leaders ?count _followers == 0:exit ?count _leaders == 0:exit ?((_leaders select 0) distance (_followers select 0) > (_dis + _leeway)): goto "move" ?((_leaders select 0) distance (_followers select 0) < ((_dis + _leeway) * 0.5)): goto "move" ~_checkinterval goto "check" #move _lpos = getpos (_leaders select 0) _ldir = getdir (_leaders select 0) _lposx = _lpos select 0 _lposy = _lpos select 1 _moveto = [_lposx + ((sin (_ldir + (_this select 3))) * _dis), _lposy + ((cos (_ldir + (_this select 3))) * _dis), 0] "_x Move _moveto" foreach _followers ~4 goto "check"

I think that was made by General Barron. Perhaps check www.ofpec.com ? It might be hanging around there in the editor's depot.

Thanks for the clarification, Maruk. Battlefield clearance == medical evacuation? I should say, that I have a very similar system to what arma 2 has propsed in one of my own MP missions: teamswitch and group respawn within the same squad, and a rudimentary incapacitation/bandaging system, and it does make for good gameplay. Rescuing your incapacitated former-self in the middle of a firefight as one of the other squad members is good fun, and far more enjoyable than save-reload. I'm interested in seeing how Arma 2's system develops. [OMG teamswitch *and* revive in the same mission! ]

From what I've seen of OFP2 so far, the thing I like the most is the dry, washed out color scheme. It makes the environment and models look quite real.

I noticed an old arma 2 video on youtube of building destruction, which clearly shows a soldier climbing onto the deck of the BIS m1a1 before getting in. He doesn't go in the hatch, but it looks a hell of a lot better than 'climbing the invisible ladder'. http://www.youtube.com/watch?v=i8jVCFPEmX8&NR=1 - Towards the end of the video.

Correct me if I'm wrong, but I thought setSkill array was not implemented, and that only setSkill was functional. That certainly is a command I'd love to see working though!

Sounds like they have the right approach for PvP. You can't really have armies fighting when you only have 4-5 soldiers. Plus, having a squad means PvP might be fun even in a map for only 4-5 people, so you don't need all 32 for a good battle.

Also, we don't have any details of how they will implement 'revive'. 1) Will 'unconscious' units be invulnerable? 2) Will all "kills" turn revivable units unconscious, or will some ordinance kill outright (sabots, LGBs, headshots, .50 caliber bullets, HEAT shells, etc)? 3) Can 'unconscious' units die if they are not revived in time? 4) Will revived units return to full health/mobility? Revive could be a LOT more or less gamey depending on how BIS revive follows the above conditions. Personally, I'm hoping units are only sometimes able to be revived (other times simply killed), can be killed while unconscious, will die if not revived in time, and do not return to full health without a medic. What I *don't* want is certain units simply falling to the ground and play some stupid "writhing" animation even when hit by a TOW missile, and going back to full health when I wave my hands over them. I hope revive is mainly a feature to improve survivability in small arms fights, not a type of 'invulnerability'. I would like it to be a 'limbo' state between alive and dead, so units who are hit with small arms rounds or caught in part of a grenade blast can be returned to the fight.

That means something didn't work properly within your loop. It could be one of two things: 1) looks like you're trying to set the value of the first element to 10. However, you need to use the set command to set an array element. http://community.bistudio.com/wiki/set 2) You might need to put parentheses around "test select 1". Depending on the order of evaluation, you might end up performing a command on the number, not the thing the array returned. Best to put those in parens.

For my mission, I figured I might be able to cut down on network traffic by having each client set the flag texture of a local flag individually. Since setflagtexture is global, I figured that running it constantly on the server might add to overhead, and since my clients can detect when a flag changes hands, I gave them a locally created flag and set the texture on the clientside. However, now I'm wondering... even though I'm using the command on a local object, it's still a global command. Might arma be sending the command over the network anyway, trying to set the flag textures of client flags over the network? In that case, my plan would have backfired, as now every client will be invoking the global command... I would assume if you use a global command like setpos or setdir on a local object, that arma won't go out and try to use that command over the network. I wonder if this would apply to setFlagTexture as well. Thoughts? Is there maybe a way I can test this?

I'm hoping this is either changeable with cadet/veteran, or at least configurable by the mission maker. It sounds like it will be good in many situations, but I want the ability to turn it off, either for specific missions or if I want to make gameplay harder.