KaRRiLLioN

Yeah I'm working on RTS-4 atm. BTW, Vic, I never had a grudge against any version of CTI. Â It's got its own style of gameplay which differs in some ways from RTS. Â The more mods, the merrier, IMHO. I made the original RTS sometime after the U.S. release of OFP, then followed it up right after that with RTS-2. Â RTS-3 came out shortly after the first CTI and I stopped improving RTS-3 just a little before ArmA came out, leaving it at version 1.52. RTS-4 will rely a lot more on strategy and choosing which territories you cap carefully, because of certain advantages you'll gain. Â Destroying the base will still be possible, but it won't be the focus because if you don't concentrate on territories, you won't have anything to attack it with. The goals will revolve around cutting off the enemy resources and then destroying their base. I hit a couple of issues with bugs in some scripting commands. Â I sent the info to Suma and hopefully they'll be fixed for the 1.05 release. Â Otherwise, I'll have to script around the problems. Â The most annoying part was that these issues only show up on a dedicated server so I didn't catch them until I started testing that. Â Ugh. In the meantime, I also have RWS Beta 9e (Real War Simulator) in working condition. Â We don't play it much because it requires a LOT of teamwork, and most people don't have the patience for it. Â It's similar to RTS except the bases are fixed and it doesn't matter if you destroy them. Â The entire conflict is based on inventory management and territories, and the commander can assign squad leaders dedicated roles like pilot, tanker, infantry, etc. Â You only have a limited inventory of vehicles and once you use that up--you're screwed. Anyway, don't worry. Â RTS-4 is about 90% to Beta 1 unless the new patch screws up something else.

The thing I hate about ArmA is that since it tries to ground itself in realism, it gives everyone something to bitch about. Like the complaints about pistols not going into holsters, or a little gray bump being out of place on the Harrier, or the rotors for the Blackhawk not being in the exact proportion to the real thing...the list goes on. Sometimes I get my kicks by just coming here and seeing what someone has found to complain about next--the shoelaces on the SLA soldiers' boots are too long, or something. I guess the bottom line is this: Â Do you enjoy playing the game? If some of the above complaints are too much a cross to bear, then perhaps a visit to the psychologist to sort out anal retentiveness is in order. As for *real* bugs: Â complain all you want. Â Like the ammo bug, or piss-poor flight characteristics on the Harrier. *shrugs*

We play it occasionally on my server (see sig) but it's not exactly a "serious" coop, per se. We had 20 people on it once, and the number of zombies hit the max limit which I set to about 100. It was pretty crazy. I did have a storyline in the ones I did for Nogova virus, although I never completed it with number 6 in the series. I've thought of some storylines for this one, and this first one does continue from the Nogova Virus series, if you notice the briefing and the beginning dialogue. BTW, zombies are assigned to each player. So if on easy it means you'll have 2 zombies per player, then the number will multiply. That doesn't mean that zombies won't chase other players, but they do pop up in the vicinity of an assigned player first and then chase the closest one in the group. For the best experience, however, I recommend very hard. It's dark, and there are more zombies. Oddly enough, though, I find visibility better than during the day when it's foggy.

Yes, the more players you have, the more zombies there will be.

Heh, good job. Try it on Very Hard though. Main difference is that it's night and a few more zombies. BTW, I updated my FTP link with the latest version of Virus. This version has the voices in it that add extra flavor. ;P Just use the link in the first post.

Edit: Main FTP is back up

Heh, the zombie leaps are very simple. Just a setVelocity with some trigonometry to get direction, etc. There are objectives in the mission. Just watch the radio chatter prompts and look at the map. I'll probably insert some dynamic waypoints for it as well.

Well, when you die, I forgot to mention that you transform into a zombie. Â So if you have teammates, you can attack them. I've found some decent animations for zombie attacks, but unfortunately none as good as the old ones from OFP. Â I've been digging thru the list of anims for more. I've got another version of this in the works. Â I added some TTS voice "acting", which sounds about as good as the voice acting in most B movies. I've also got the next chapter in the works. Â I hope someone releases farm animals for ArmA. Â In chapter 5 of Nogova Virus, I had zombie animals attack. Â It was fun running from crazy chickens. @ofpforum: someone did make zombie addons for OFP. Maybe they'll do it for this. I've discovered some ways to improve my old zombie scripts with new ArmA commands as well, so I'll experiment with those soon to cut down on some of the trigonometry with the new createUnit <array> command. And we do play this on my server. See my sig for details.

@IceBreakr: Bashing Dang, Ziggy, I thought Little Orphan Annie was the perfect way to end that one mission.

Which version of RTS do you have? There were a lot of changes in addons between 1.4x and 1.5x. I never posted links for the 1.5x versions and now I mainly play ArmA, but I'll look for those missions if you need them. Just PM me though, since I don't frequent the OFP forums as much.

ArmA does have some annoying bugs, but TBH, I'm really surprised that for a game of its complexity and reach that it has so few bugs relative to say...BF2 or BF2142. It's been worth the price of admission to play the game since the November release and I'll probably purchase a hardcopy English version once it's out over in the US.

Most US servers sit empty during the day because there's no US release. Hopefully the 505 release will bring more players, but unless BIS gets a nice US release, things might be thin. My server is idle until around 9pm Eastern. We normally get a crowd of upwards 10-20 people with a high of 30+ on a few weekends. Depends on the mission being played as well, I guess.

I purchased and received a DVD copy of the game from buyArmA as promised. I would say that purchasing the special box version might be harder considering the suspicious packaging.

Speaking of SLI/Crossfire, does ArmA even work properly in WinXP with either of those yet? Seems whether it works in Vista is a moot point considering the poor SLI performance I've had in XP. In fact, I get better performance running one 8800GTX than I do SLI. Whether it's ArmA or Nvidia that's to blame, I don't know. And this DX10 thing chafes me. Too bad MS managed to kill off OpenGL.

I can see why they did it, though. Â That's a lot less movement the netcode has to worry about. Â I think it could be worked around in an addon, though. Â You could probably give it a different simulation type but remove any driver/cargo positions, etc and also put destructType as "House" or whatever that type is to get the interesting building destruction effects. The destruction sequence for buildings is actually a clever illusion using setPos, by having the destroyed buildings drop about 38 meters below the ground. For the time being, I think it's also as easy to have a client-side loop which looks for a public string. Â This string would in essence be a script and could have multiple uses. Â In this case, the builder client could publicVariable a script to set the position and direction of the building. The direction is the most problematical. Â If only that were global. Â Then I wouldn't mess with sending the other info to clients. Â In OFP RTS I had the buildings "grow" from the ground. MP issues strike again!

If you want to test on a dedicated server, all you need to do is start ArmA on your machine using the -server parameter and then start up your client as you normally do. Then you can change the server browser to LAN and you'll see your dedicated server. Even though it's on the same machine, the server will treat your client as remote and you should get reliable test results.

You need createVehicle to make the bomb. Â Plus you need the bomb type, which for a GBU is "Bo_GBU12_LGB". Â You can find other weapon types at Wiki Weapon Types. So, to create the bomb 50 meters in the air, it'd be something like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> bombPos = getPos target bomb = "Bo_GBU12_LGB" CreateVehicle [bombPos select 0,bombPos select 1,50]

Fun mission! The only complaint I have is that once you've tracked the nuke, it becomes very obvious where it will be when all the enemies suddenly spawn there. How about a version using that island population script and you have to find one civilian out of many? You could put in enemy civilians as well to make things harder. Just a thought. Also, using a trigger for that first variable does make it difficult to get around the JIP issue, unless perhaps you make the trigger activate only if missionstarted is false or something.

You probably need a game logic named Server so local server will work. Also, I have a script that does this as well. Check this thread. http://www.flashpoint1985.com/cgi-bin....t=55583

One thing I just found out about static objects is that they'll only setpos for the client that gives the command. In other words, you setpos a static object on your client, and it doesn't change for anyone else. Suma told me it was for optimization. Gonna be a pain to script for RTS though. Creating a base...ugh.

To do an execVM from an init field, you have to use a dummy variable to make the code parser happy. s = [] execVM "script.sqf" Put the s = at the beginning, in other words. Not necessary if exec'ing from within another script.

Did anyone ever figure this out?

I tested and confirmed. The sleeps do work. I put in several sleeps of differing length with some debug text and the intervals worked as they should. Since I know I have sleeps in every loop of at least 1 second, it concerns me if SQF's do eat up that much CPU.

Right, it's an infinite loop. Â In this case I'm talking strictly about infinite looping SQF's not run-once. Â So long as there's an exit from an SQF loop, I can't see that it would sieze all CPU power on the server for a noticeable length of time. Oh, and this is exec'd using execVM.

I've never had that issue AFAIK. Count Crew Vehicle only counts living crew, I believe. In CTF's and such we've had many instances where players and AI were killed in vehicles and they respawned properly. I suppose you could try to set up a debug statement, i.e.: player groupchat format ["%1",count crew _vcl] or something just to see if dead crew are counted as crew. If so, it's a change from OFP and something like your statement will probably work.