Zombie_Mod

Well I for one am looking forward to armed assault!!! I'm going to migrate the new feckin Zombie Mod for it ASAP. I have ideas and I need a better scripting language to implement them with.... I also hope the 64 group per side limitation is a thing of the past. Come on BIS there's 5Ghz processors available nowadays, it's time to scale up those battles!!! Personally I am looking forward to the wildlife addons, especially if they can be used against your enemy to startle them, e.g. make a rabbit run and watch the opposition shoot at it Imagine the scenario, it's dark, you have no NVG, and you hear rustling... is it a rabbit, or is it the enemy? BIS you better not screw this up!! I'm 34, I don't have years to wait to play your games

Oh, is that so? Thanks for asking me if you can use them Dave!!! Just because I don't work on the zombie mod any more doesn't mean I agree to having scripts I spent hours on used in other people's projects  Those animations look very familiar, too....  Eeep! I assumed MiG asked your permission to modify the scripts when he started farmland  Dave, are these new zombies going to be part of farmland? If they are - then you may use my scripts as Mig and I are mates. I wouldn't do him a bad turn If these zombies are not for Farmland, it's still OK - you can use the scripts in the zombies but I request that my name (Scott Tunstall) is mentioned in the readme.txt of the zombies . Cheers, Scott

Yeah I thought about doing it so the zombies didn't know where you are, but rather "smelled" the scent of the targets (ie: every 5 seconds or so, a new "smell" would be created at the targets position, and the zombies would move to the position of the most recent smell until knowsabout target > a certain threshold) but back in the day, CPU power wasn't up to it. Now though, I think a 3Ghz CPU could easily handle the job. I just can't be arsed doing it. I've forgotten most of the scripting and I hate o2, for the record  As for the other things you mention - they already exist. The people who have been bitten are in the gblBitList array (I think - check my readme.txt). Once they die they resurrect. If you want to make it so that the bit people lose health, then create a script that loops through gblBitList every X amount of seconds, and subtract from their health until they die. Piece of cake. There is also an event handler (again see docs) that is called whenever someone is bit. You could make it so the target freezes.

I am actually considering returning to the zombie mod and creating some new zombies; I have a whole batch of textures I want to use, but I think I'll need to do it when on holiday as I'm really busy with work right now. Unless of course Mig wants to do the models and I'll do some textures - I'm not changing any model specific stuff like hit points, that took AGES last time I have some textures and ideas that I think would knock your socks off...

Oh, is that so? Thanks for asking me if you can use them Dave!!! Just because I don't work on the zombie mod any more doesn't mean I agree to having scripts I spent hours on used in other people's projects Those animations look very familiar, too....

I'm quite sure this is incorrect. The P4, and everything else since Pentium Pro have a 64bit data bus so it should be a single read/write operation. Using the movq with MMX registers appears to be quite close to twice as fast as the 32bit mov when accessing data that is already in the cache, but anything that needs to access the system memory seems to be simply bottlenecked by the memory speed no matter what method you use to access it. How is assembler optimised for a certain processor (Other than what features it supports)? Its supposed to do exactly what I code (as it does, verified by disassembling the executable) and the MS Visual Studio assembler does support MMX, SSE and SSE2 instuctions, which I doubt existed when VS 4 was made... It didn't force me to upgrade :P While the memory limit issue is valid (The 2GB limit of Windows especially), I dont think it would be very wise to make a game now or in the near future that would use that much memory and would require a 64bit processor - There simply wouldn't be enough customers that could even run your game. Doom 3 is a good example of an extacly opposite "policy" in my opinion, it ran playably even on a GF4MX. A 64bit platform does its job in what it is supposed to do, and that is allowing more memory to be used. But expecting massive performance increases is just not realistic in my opinion, and if you do not need the extra memory you do not need a 64bits. For the MMX 64 bit data bus you state exists, can you point me to some documentation? Secondly, if you look in C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt (or wherever your C runtime files are) you will see that the intrinsic assembly code for the runtime library hasn't changed since Visual C++ 4. There are no MMX instructions used there. Thats what I meant, the M$ runtime code hasn't changed for years. If you hand code assembly, all well and good... good on ya. If you thought I meant the actual compiler hadn't changed, well that's not what I meant Also, assembler can be optimised for a certain processor. e.g on some processors LOOP is slower than DEC CX; JNZ whereas on others it's faster. See here for more info: http://www.gamedev.net/reference/articles/article369.asp

Shouldn't it also work the same by using the MMX registers? ie: movq mm0, [esi] movq [edi], mm0 I tried this quickly on my P4, and while it is about 4% faster than the 'mov' method, it is pretty much equal in speed with the 'rep movs' method that memcpy of MS Visual Studio uses... Pretty much all of them I have seen over time... In low level (Linux) benchmarks there are things where it is a bit slower, and some other things where it is a bit faster. In Windows gaming benchmarks there seems to be quite equal performance. I dont have any links to such benchmarks but google should find them... If there is none or very little advantage of a 64bit version then it propably isn't worth the effort of maintaining and supporting two separate builds. By using MMX you can load 64 bit quantities of data, for sure, but on the P4 you're still limited to a 32-bit bus, hence to copy 64 bits of data you have 2 individual reads and 2 individual writes of bits 0..31 and 32..63. In AMD64 it's just 1 read and 1 write. I wouldn't use Visual Studio's assembler as a reference though, that's optimised for 386 processors, I noticed the code hasn't changed over the years since Visual C++ 4 I do agree that if it's not cost effective for BIS to produce 2 versions (32 and 64 bit) then they should not. But BIS are not a normal company, they have military contracts do they not, so I dare say they will already be developing for 64 bit PC systems now anyway, in order to model larger battlefields. I really can't imagine how legacy 32 bit systems are going to handle the massive islands and DirectX 9 textures, increased numbers of unit groups, dynamic range sound that we are all clamouring for. With 32 bit systems, as you know, you have a 4GB address space per process (no 32 bit motherboards at the moment support it anyway) I bet this ceiling will be a problem soon (meaning, disk thrashing.) Just saying. It's a moot point anyway; as I said, next year Doom 4 will force everyone to upgrade, just as Doom 3 forced us to upgrade to new Radeon and Nvidia gfx cards.

Oh I'm really excited with this Got me a CD (well rather, found the original in a cupboard) and gonna have a game... Downloading it now....

Propably. I dont know much about the internals of the memory bus used by the 64bit athlons... But wouldn't such function be bottlenecked by the memory bus bandwidth before the cpu? (Assuming you're copying blocks big enough that they wont fit entirely in the cache) If it improves performance considerably then why aren't the benchmarks considerably faster? Maybe, but more registers also means more things to store into the stack when doing a call. (The boring stuff) Well the memory bus bandwidth is always going to be an issue regardless of what architecture you are in; I still would expect the AMD64 to be faster though, just because you can move more data with a single instruction. I mean, memcpy at its easiest on a 32 bit system is: MOV ESI, OFFSET source MOV EDI, OFFSET source MOV ECX, count / 4 cpy: MOV EAX,[ESI] MOV [EDI],EAX ADD ESI,4 ADD EDI,4 LOOP cpy (Yeah, I know, I could use REPZ MOVSD too! Surely if you are moving 8 bytes at a time the number of memory accesses for both instructions and data will be reduced, and the number of CPU cycles required in the loop above will be halved? Sorry if you already knew this As for benchmarks, well I don't know why they wouldn't be considerably faster; what benchmarks are we talking about? Windows 64 bit in general? Well as the 64 bit system is still new I dare say the drivers for the system are a bit poor at the moment. (End of the boring stuff) I still think a 64 bit version of AA would be a good idea though... do what ID has done and push the envelope, blow the competition out of the water... give us a game that will take advantage of the latest hardware. You all know when Doom 4 comes out we'll all have to upgrade to 64 bit PCs anyway!!!

And your point was? And there have been 80bit registers in x86 processors much earlier than MMX, ever since the first x87 math co-processor. And MMX's largest mistake was that it uses those same registers. I never said such things And thats exactly my point - When you use the processor in 32bit mode all that extra bandwidth and cache is giving you better performance. And that advantage will be lost when you use 64bit code. True, not everything will grow, but for example all instructions that use the now-64bit stack will use twice the bandwidth. 2 gigabits? :P I use many compilers. The point was that the x86-64 is a new architecture (or an extension) and compilers aren't propably capable of taking full advantage of the new features yet - Especially GCC which has never been the best in terms of optimizing code. If I use the processor in 64 bit mode then I am able to memcpy() 64 bits at a time, instead of 2 32-bit reads. This is by far a better use of bandwidth. Also, as I said, the 64 bit CPU has extra registers, therefore the amount of writes to temporary storage for "local" variables will be reduced, improving performance considerably and reducing need for bandwidth. And how can you say that a 64 bit stack will use 2x the bandwidth? That depends what is pushed on it. C++ compilers use the stack for local variables but if you have more temporary registers to use then I would expect stack usage to decrease, wouldn't you?

I wasn't aware that a 64bit build of Half-Life 2 was available? LOL, I remember this chat 10 about years ago when MMX came out - "no-one will use it for years" 1. We've had 64 bit registers (well, OK, 80-bit) for years already. MMX anyone? 2. Secondly, Kegetys, are you trying to say one MOV QWORD is worse than 2 MOV DWORDs? I don't think so. It's only an extra byte for the 64 bit instructions, I don't know where you get "double the cache and memory instructions", unless of course you are including the 64 bit data too - but that's the whole point of the extra bandwidth!!!! Show me an example. Also, with the new 64 bit processors you get more registers, not just 64 bit versions of AX,BX,CX etc etc... as far as I am concerned, a 64 bit version of OFP, written with a decent compiler (e.g. GCC) would blow any 32 bit system out of the water. Just one thing though - you really need 2Gb of memory for AMD64. 3. Compilers aren't matured enough? I'm interested in this. What compiler do you use? Cheers, Scott.

Come to think of it, I'd quite like to be able to lean around corners as well Of course, if the AI was shit you could lean out, kill one enemy, lean back in, wait, lean out... kill... repeat. Wouldn't it be great (edit: for MP) though? Maps like Hexenkessel CTF would be MUCH improved with leaning. I've not fired a gun in real life so if it's not realistic to lean and shoot, then so be it - keep the realism

The point here is that something might not be better because OFP is supposed to be customizable and you can forget about stuff like (purely hypothetical) DXDLL2 that adds those wonderful DX11 effects to the outdated armed assault engine. Or not to mention those people who get e-stoned for having PB or some similar hopeless hack label them cheaters for no good reason. No, we are just being pragmatic. OFP is also supposed to be multiplayer and if you leave the game wide open to cheats, then it'll be a dead duck. DXDLL is an exploit that exposes a "feature" in Flashpoint anyway. OFP wasn't exactly *designed* to allow that extensibility, Kegetys and wossisname must have been up all night with the tools from sysinternals.com studying how the flashpoint system loads DirectX I remember talking to Keg and Fearsumm a while ago about it. If BIS were using the COM object Library properly (and they can't have been, as they were using Win32 LoadLibrary to load the DirectX library into memory, instead of properly using CoCreateInstance to create the COM interface) then DXDLL wouldn't have been possible. You know you can use the DXDLL concept to cheat, too? Kegs and Feersumm used CRC32 to determine the texture that is being rendered - how difficult would it be, to say: IF SoldierTexture being rendered RENDER pure white (or yellow) texture all over END IF And make the soldier stand out? Luckily Kegetys and Fearsumm did not release their source code otherwise no doubt this type of thing would already have appeared.

AI and squad communication in any mode has to be the priority IMHO. Ex: I'm fed up of waiting for a squad member to say he's "injured" in a slow voice, after I just clicked "Reveal" on a sniper that's taking out my men. I have to wait for "4" to finish his sentence before the sniper is revealed, a right pain in the ass. When I say "Get Down!" or "Sniper 6 o clock" , number 4 can go fuk himself at that moment. As for the AI, well let's put it this way - the enemy spends too much time sitting in the open, being shot to bits. And, I have noticed the enemy waits a while before shooting at you, or runs right past you. In Multiplayer the AI is a complete liability. BIS may have had the excuse back in 2001 that CPUs at the time were not powerful enough for the complex AI code required, but they do not have that excuse now.

Hell no, need a reason? Just play several games that feature these anti-cheat systems online ... What, like Quake 3 - the most successful online deathmatch game? Maybe you kids have your own private clans, but for the more casual player who DOESN'T want to devote much of his time to a clan and private server, we have to use Gamespy or All-seeing-eye to find matches. And guess what? They're jumping with cheats. You can't say you can spot a cheat, because even innocent people are being kicked for being too good. Tell me, oh wise ones, how do you tell, out of 16 players, who's using the "create tank" cheat? Or who is using the "everyone gets 50% damage at start" cheat? Or the "guns move up and down themselves" cheat? You can't. Therefore it is important to have a trusty anti-cheat system. Something is better than nothing. You people in private clans are being completely SELFISH.

Now that is the funniest comment I've heard in a while. Very little cheaters in OFP??? You should try the All-seeing-eye servers mate, there's 100s of cheaters there. Older players like myself, who appreciate a good game of Hexenkessel CTF or TNT St Pierre CTF and are prepared to wait for the player lobby to fill, can't enjoy the game as some 13 year old takes umbrage by being shot too much and then deploys a cheat. End result: random suspects get kicked off, maybe banned from servers for no reason (ie: me) Anything that helps gets rid of the cheating arseholes is worth it in my opinion. Not all of us want to join a clan you know, on our own wee private server...

As long as you aren't passing all of the work off as your own and giving credit where credit's due, I don't mind.... As for ripping the sound files, that's fine too - just make sure you credit where you got them from (me), I spent a lot of time getting those sounds, it's the least you can do. Finally, don't name the zombies zombies.pbo, that means they will overwrite my work and severely piss me off Scott

I really wish I'd updated the zombie AI... I had loads of ideas that even now no other game has implemented Still... look on the bright side guys, I'll be back to write more zombie stuff when AA comes out (unless AA is shite ) - hopefully BIS will make developing 3D objects and testing scripts easier this time....

I wish I still had my resistance CD I would like to play this mission. Oh well... shit happens Glad to see you're still using the zombies folks! I'll see you later in Armed Assault... Scott

Never play it anymore.. I had a 3 month absence from the game, got 100s of emails asking where the hell I was... after re-installing to see if I could get back into the game, I took one look at the stock graphics and went "yuk" - they look pretty crap nowadays!!! Only reason I'm on here is to see how many people are still using the zombie mod... that's it. I will of course buy flashpoint 1.5, if it's any good. If it's not, I can see me giving video games up for good. Which might not be a bad thing

thats good to know dude, he left again Sorry Waiting for Flashpoint 1.5 now....

Hi guys, yeah I can confirm the zombie mod is dead for me, I just can't bring myself to commit time to develop for a 4 year old game But... when Armed Assault comes out, I may write a new version of the mod, especially if the new BIS engine has better scripting support, and if it will support more units It's only now that PC specifications and power are becoming ideal for OFP's size and potential,so it may not be long before you guys get to see 1000 zombies on a map at once... which is what I wanted all along. I want to scare the players, I want an RPG where you have to survive in the dead world, and most of all, I want to play as a zombie It's been a pleasure writing the zombie mod for you guys. Glad you enjoyed it. See you in Ofp 1.5!!!! Scott

They still having problems with the Jurassic mod? Jeezo... I forgot about them... I formatted my hard disc a while back, my PC had a virus... of course, I had all my work kept on sourcesafe, so I got it back no problem... OFP is still not installed on my PC, but I figured I owed the zombie mod my return. The potential is too good to waste. I've made up my mind though, I'm not doing any 3D modelling - I've had enough of faffing around with that stuff PS: Why don't the Jurassic guys just take my scripts and amend them?

I'll post a working link later. Scott

No sir, it has resurrected itself.... I'm back.