Nothing is truly random when generated by a computer. Not one thing. If you create programming to generate a random number, for example, it is not truly random because the coding of the programming determine the means by which the computer generates the number.
As far as maps are concerned, a map that you are not likely to see exactly as you see it again for weeks or months or ever could be considered “random”.
I think you are kinda lost here. Follow this carefully: If the server generates a map either by using a single guideline or by connecting pre-made map sections by using one or more guidelines, it must send the info on exactly how it did it to every client. Then, each client PC would generate the map exactly as the server did (unless you expect every client to download a new 40+MB map at every map change). When every client was finished COMPILING, the game could resume. This means that …uh oh, here we go… every player has to wait while the map is… here it comes, get ready!.. COMPILED BY THIER PC. Add this COMPILING to the calculations done to write the new map to memory and the HD as a temp file with all of it’s vertices, models, objects, textures, etc etc after it has been COMPILED (there’s that evil word again) and you can see that power is of the essence.
Let’s not forget that the bigger the map, the more powerful a PC needs to be to render it to the screen for playing it. Let’s also not forget that most gamers hardware is at least 1 generation behind the latest hardware. Not many gamers yet have an FX video card, or even a Gforce4. Currently, many cannot play in complex maps like Radar at resolutions over 800x600 with more than 30 FPS because their vid card is 2 yrs old or more. Not everyone is behind, but the point is that most people’s PC’s are always behind 2 generations, sometimes just 1 generation. It has always been that way, likely always will be because of the pace of hardware advancement.
Game makers always take advantage of new power, and every good game I’ve ever owned pushed the limits of my PC’s performance untill I upgraded something, most often the vid card and processor. This is because games that require more power are always coming out on the heels of new hardware technology.
Case in point: id Software is constantly changing the DOOM III engine because new technology keeps making them go back to the drawing board, so to speak, and add or change things. At some point, they will draw the line and release the game. Since DOOM III was begun, at least 3 generations of video card, 2 generations of motherboard, 1 generation of HD, 1 generation of RAM, and 2 versions of DirextX have been released. The game is still not out yet, and new technology does not wait for games. It’s the other way around.
Every time NVIDIA or ATI come out with a new vid card, the game makers buy it, study it’s capabilities, and see what they can do to add anything that might be new to their next game. Every time Microsoft releases a new version of DirectX they do the same thing: examine it and try to encorporate it. The next version of Duke Nukem has been set back many times and under development for about 4 years now for this reason. Perhaps Apogee is not dedicating enough resources to keeping up, or maybe they are just too indecisive. It’s either going to be one hell of a game, or a flop. We’ll see.
Q3TA does not require compiling? What do you think a game does when you tell it to load a map? Do you see those little icons loading? Does it load instantly? No. Far from it. When you load a map, the vertices, lighting, models etc are all recompiled and loaded into memory.
Pre-compiled? Do you have any idea how much memory and power a PC would need to have to keep numerous “pre-compiled” portions of maps hanging around ready for use??? Do you realize how long it would take the game to load when you start it??? I’m not interested in waiting 3-5 minutes for a game to load 8 gigabytes of files into memory. I’ll build a PC like that in about 3 or 5 years if the hardware is powerful enough by then.
Therefore, sending map data so each client can COMPILE the map the same way is the only answer, unless we all get fiber optic Internet connections next year, and that is not likely to happen for quite a few years. Even a cable modem would take quite a while at 1.5 mb/sec if the server were on a T1 line. How many servers have exclusing use of a T1?
Random map generation must be done locally as dictated by the sever. It’s the only way for the near future.
I think you are kinda lost here. Follow this carefully: If the server generates a map either by using a single guideline or by connecting pre-made map sections by using one or more guidelines, it must send the info on exactly how it did it to every client. Then, each client PC would generate the map exactly as the server did (unless you expect every client to download a new 40+MB map at every map change). When every client was finished COMPILING, the game could resume. This means that …uh oh, here we go… every player has to wait while the map is… here it comes, get ready!.. COMPILED BY THIER PC. Add this COMPILING to the calculations done to write the new map to memory and the HD as a temp file with all of it’s vertices, models, objects, textures, etc etc after it has been COMPILED (there’s that evil word again) and you can see that power is of the essence.
The uncompiled goldrush map is 14MB. No way anyone is going to download a file that size every game. Compiled, it’s 15MB, plus all the scripts and lightmaps, which are negligable.
Q3TA does not require compiling? What do you think a game does when you tell it to load a map? Do you see those little icons loading? Does it load instantly? No. Far from it. When you load a map, the vertices, lighting, models etc are all recompiled and loaded into memory.
No, not really. The BSP file is being parsed, vis data, lightmap data, textures, models, etc. are loaded into memory. CPU usage during map loading is minimal.
Pre-compiled? Do you have any idea how much memory and power a PC would need to have to keep numerous “pre-compiled” portions of maps hanging around ready for use??? Do you realize how long it would take the game to load when you start it??? I’m not interested in waiting 3-5 minutes for a game to load 8 gigabytes of files into memory. I’ll build a PC like that in about 3 or 5 years if the hardware is powerful enough by then.
But that’s how it works. Whoops.
Therefore, sending map data so each client can COMPILE the map the same way is the only answer, unless we all get fiber optic Internet connections next year, and that is not likely to happen for quite a few years. Even a cable modem would take quite a while at 1.5 mb/sec if the server were on a T1 line. How many servers have exclusing use of a T1?
Okay, you can sit there and recieve a 10MB file, then spend 16 hours compiling it. Enjoy.
Random map generation must be done locally as dictated by the sever. It’s the only way for the near future.
Random map generation is not feasible for the Q3 engine. There’s no way to move significant amounts of brushwork without having to re-vis and re-light the maps, and that takes much too long.
Next time you want to post technical info, please read up on it first so that you have some clue what you’re talking about. I’m no expert, but I know enough to tell that you’re clueless.
Compiling means building. You can save or not if you are making a map, but when your game loads one, it is compiled in memory. All of the data about locations of everything and characteristics of everything in the map is just COMMANDS!
That’s all. Just commands.
Put this here and that there. It is up to the game to COMPILE them once again in RAM. Sure as hell can’t play it on the HD alone kiddo. hehe
Um… that’s what I just said. You did not read it I guess before your come back.
Not really? Hmmm. Well, I hate to break this to you kiddo, but games use a lot of processor at almost all times.
You are talking about BSP files? PSSSST! Listen up. BSP files are maps for Quake I and Quake II engine games. Anything Q3 or later engine uses PK3 files. You are between 4 to 7 years behind. You think Wolf ET uses BSP map files and you are talking to me about how things work? ROFLMAO Just so you will know, Q1 and Q2 both use BSP files, but they are not compatible.
No, it’s not. When you start Wolf ET it does not load every map into memory before you can join. Sorry. Did you mean those BSP files you were talking about??? lol
Kiddo, you have very poor reading comprehension. Read the above again, then your response. hehe
And this from a kid who thinks Q3 engine games use BSP map files??? Kid, you are lost. How someone can play Quake III, RTCW, and Wolf ET for so long (4 years now?) and still think the map files are BSP’s is beyond me. Oh let me guess… for one thing, you have Windows set so that you cannot see file extensions for known file types. All this time, even after visiting game sites, and you still think these games use the old Q2 BSP format, all because you cannot see the file extension? OMG!!! ROFLMA!!! tears of laughter hehehe :blah:
Sorry, but that truly is funny. Here’s what you do: Change your view settings in Windows, and you understand more about these matters let us know.
Although weasel covered these, I do feel a need to cover them again in more detail for Ironmans sake as he clearly has a failing grasp of how not only the Q3TA engine works, but computers in general…
Q3TA does not require compiling? What do you think a game does when you tell it to load a map? Do you see those little icons loading? Does it load instantly? No. Far from it. When you load a map, the vertices, lighting, models etc are all recompiled and loaded into memory.
When it loads the map all it is doing is taking the compiled data from the file and placing it into memory for rapid recall. Some data (typically player/weapon models and other dynamic items) undergo a form of compilation (in the vaguest sense of the word) in that they are often sorted into ordered lists to expediate drawing/animation in game. The reason we wait for loading is because there is a LOT of data to load, it has sod all to do with compilation times. FYI the compilation of vertex data into those lists I mentioned happens in a few seconds, and is not a significant bottleneck of the loading process.
Pre-compiled? Do you have any idea how much memory and power a PC would need to have to keep numerous “pre-compiled” portions of maps hanging around ready for use??? Do you realize how long it would take the game to load when you start it??? I’m not interested in waiting 3-5 minutes for a game to load 8 gigabytes of files into memory. I’ll build a PC like that in about 3 or 5 years if the hardware is powerful enough by then.
I will assume by memory you are referring to permanent storage such as hard drives, the cost of which are incredibly cheap now. You can buy a 100 gig hard drive for around £60 these days, and that would be enough to store the prefabs for about 10 games with random map prefabs. Yes storage would be quite large for these games, but when companies feel they can release games like Enter the Matrix with it’s fixed, crappy levels and it still takes up 4gigs, I don’t think storage will be a problem in making random map generators.
As for loading times, theoretically they could be faster than current times because some prefab blocks might repeat in the level and so only need loading once. External lightmap data could be used so prefabs could share the data and save loading time there too.
And to finish off…
I think you are kinda lost here. Follow this carefully: If the server generates a map either by using a single guideline or by connecting pre-made map sections by using one or more guidelines, it must send the info on exactly how it did it to every client. Then, each client PC would generate the map exactly as the server did (unless you expect every client to download a new 40+MB map at every map change). When every client was finished COMPILING, the game could resume. This means that …uh oh, here we go… every player has to wait while the map is… here it comes, get ready!.. COMPILED BY THIER PC. Add this COMPILING to the calculations done to write the new map to memory and the HD as a temp file with all of it’s vertices, models, objects, textures, etc etc after it has been COMPILED (there’s that evil word again) and you can see that power is of the essence.
Here’s a c-r-r-r-r-r-razy idea: Why not just seed the random number generator on the clients? For someone who keeps harking on about how random number algorithms are not properly random and are simply generated by mathematical algorithms, it amazes me how easily the concept of sending the random number seed to the clients could escape you. So the sending of 64bits of data would be all the server would need to send to tell the clients everything they need to create the random map. Even a dial-up user could send that in less than a second - are we sure the internet can cope!? :moo:
As I mentioned before, there would be no compiling required. The Q3TA engine would use prefabbed versions. the Doom3 engine could (theoretically) simply peice the map together and be ready to run because it has no compilation needed even at the map design phase.
So perhaps you would like to go off and do a little research about the points you make then come back and pose some rational debate. Until then, stop spouting your ill-educated preconceptions about computers and computer games. KTHXBYE.
Weasel…
Random map generation is not feasible for the Q3 engine. There’s no way to move significant amounts of brushwork without having to re-vis and re-light the maps, and that takes much too long.
I was thinking about this… I think it could be done. If the prefabbed blocks were made so that a large or set size portal existed at the edges of the blocks then they could be joined up (and the portals would match) at map load time in the BSP tree. Might take a short while to calculate the joins and modify the BSP, but in theory I think it could work. I figure this is probably how Nosferatu does it - simply have blocks that have the same portal structure at their edges so they can be joined easily.
EDIT:
Had to add this after reading what ironman posted while I was writing this main post…
Ironman said:
You are talking about BSP files? PSSSST! Listen up. BSP files are maps for Quake I and Quake II engine games. Anything Q3 or later engine uses PK3 files. You are between 4 to 7 years behind. You think Wolf ET uses BSP map files and you are talking to me about how things work? ROFLMAO
Want some entertainment Ironman? Try this - open a pk3 file in winzip. Now browse through until you see the variety of .bsp files in there. PK3 is a compression format, not a map format. Excuse me while I step and cry with laughter.
To think, all this time I was arguing with a 7 year old/escaped mental patient/incarcerated mental patient/undiagnosed mental patient/redneck (delete as appropriate)
Actually that was a bit harsh on rednecks…
Compiling means building. You can save or not if you are making a map, but when your game loads one, it is compiled in memory. All of the data about locations of everything and characteristics of everything in the map is just COMMANDS!
[/quote]
LMAO@IRONMAN
That is almost as good as ‘that depends what your definition of “is” is’
Sure, you can define words to mean whatever you want, but if you intend to communicate, you should stick to accepted definitions. Loading a map is not 'compiling" in the commonly accepted sense of the word. No more than loading a MS word document is “compiling” it.
The reason q3 type maps have a multi-hour compile process to turn the .map (which you create in an editor) into a .bsp (which the engine can load) is to bake it into something that the engine can load load with a minimum of effort.
That said, random map generators have been done. AFAIK SOF2 had one, and from what I heard, it sucked ass. Which is no surprise. Moreover, the gameplay requirements of a complex team based game like RTCW or ET make it much harder to create fun, balanced maps for, compared to a straight DM or team survivor type game.
Ask a computer programmer what compiling means and they will give you a simple answer, then perhaps 3 more in-depth ones. To compile is to “collect and organize”. Placing maps in memory means collecting the data from the HD and organizing it into memory. The simple term for this type of compiling is “loading”, right? OK. So as not to confuse compiling a map for the first time, and compiling it into memory every time it loads, I will use the word “loading” instead.
How could you think that I was talking about HD space? Oh well.
As I said, pre-loading (compling?) prefab map sections that are large would require too much of the memory (RAM???) that I was talking about with current PC’s. Games do not load every map into RAM (random access memory). They load the one called for by the server.
I see what you are saying, and that technique may indeed be used, but I doubt anything for games of the future will load faster (forgetting PC power) than currently. As PC’s evolve, files get bigger, HD’s get bigger, RAM gets bigger, etc. There’s no going backward I’m afraid.
The game does not load BSP files into RAM by themselves dude. It load the entire contents of the PK3. A Q3 map is NOT in BSP format. lol It is in several formats. It’s not just a BSP. The BSP is only part of a map file. This is not the current file format the maps are in. BSP is just part of the map. In the past BSP files were all that was needed for a Q/Q2 game. [/b]Just as you said, open a PK3 and what do you see? A lot more than just the BSP. So don’t get all self-richeous because you are also wrong. If the BSP was all that a map was, that’s what you would load, just a BSP.
Show me a place where you can download a BPS and load it and play it in this game. lol Remember the format of the map file don’t you? It’s PK3.
PK3, redneck, is not a compression format. It is a file format. There is no such thing as a compression format. There IS however, such thing as a compression algorithm. hehe A PK3 file is a zip file with the extension .pk3
THINK
Before you go calling someone a redneck, think more before opening your mouth.
Ask a computer programmer what compiling means and they will give you a simple answer, then perhaps 3 more in-depth ones. To compile is to “collect and organize”. Placing maps in memory means collecting the data from the HD and organizing it into memory. The simple term for this type of compiling is “loading”, right? OK. So as not to confuse compiling a map for the first time, and compiling it into memory every time it loads, I will use the word “loading” instead.
Why that’s very gratious of you that is. How big of you to use the English language in the same way every other person on the planet does.
And FYI 9 out of 10 computer programmers will not give that definition of compiling. They will give the more correct (for this discussion) defintion that compiling is converting data into a more appropriate data format for a given application. EG source code is compiled from C++ text into assembly language for rapid execution. The definition you gave is the definition a librarian would give, not a programmer.
How could you think that I was talking about HD space? Oh well.
As I said, pre-loading (compling?) prefab map sections that are large would require too much of the memory (RAM???) that I was talking about with current PC’s. Games do not load every map into RAM (random access memory). They load the one called for by the server.
How so? Apart from a small increase that will come about from having to load in information about the prefab blocks and how they can link together, the maps would be no different in size to current human desinged maps of comparable dimension. Perhaps you would care to explain in detail how you think prebabbed maps would be so much bigger?
I see what you are saying, and that technique may indeed be used, but I doubt anything for games of the future will load faster (forgetting PC power) than currently. As PC’s evolve, files get bigger, HD’s get bigger, RAM gets bigger, etc. There’s no going backward I’m afraid.
In terms of the amount of data in maps/games there is no going backwards, but in terms of the hardware making the loading process faster, there are plenty of ways of going backwards. If I swapped my IDE drive for a nice striped RAID setup I could load the maps in a fraction of the time I do now. The reason technolgoy moves forwards is, in a sense, so certain aspects of the IT experience can move backwards 
It’s a funny old world.
The game does not load BSP files into RAM by themselves dude. It load the entire contents of the PK3. He said the BSP. This is not the current file format the maps are in. BSP is just part of the map. A map consists of more than just a BSP. In the past BSP files were all that was needed for a Q/Q2 game. Just as you said, open a PK3 and what do you see? A lot more than just the BSP. So don’t get all self-richeous because you are also wrong in a way. If the BSP was all that a map was, that’s what you would load, just a BSP.
Oh, did you not write this statemet:
And this from a kid who thinks Q3 engine games use BSP map files??? Kid, you are lost. How someone can play Quake III, RTCW, and Wolf ET for so long (4 years now?) and still think the map files are BSP’s is beyond me. Oh let me guess… for one thing, you have Windows set so that you cannot see file extensions for known file types. All this time, even after visiting game sites, and you still think these games use the old Q2 BSP format, all because you cannot see the file extension? OMG!!! ROFLMA!!! tears of laughter hehehe
Hmm, strange that. Even stranger that the BSP file IS the map file that the game loads. The bsp contains all the information about walls, what textures to use, what entities to place and what lightmaps to use to light the walls. (although now in ET we use external lightmap files). All those textures and sound effects that are also in the PK3 are referenced by the BSP so the game knows what to load and use.
The game does not load BSP files into RAM by themselves dude. It load the entire contents of the PK3
Okay, Q3 map loading for beginners:
The engine does NOT load the entire PK3. What it does is read the PK3 header and gains a list of what files are contained within the PK3. This list of files also contains a list of offsets. Using the filename list and the offsets list, the game is able to pick out and decompress single file data sections without loading the entire PK3 file. Much as you would do if you opened a zip file with a lot of files in it but only want to decompress one file. If computers really did load the entire contents of the PK3 into memory then older computers would probably fall over and die. The ET pak0 file is over 200MB in size. To copy this file takes my machine about 20 seconds, yet I can open and view the PK3 contents in less than 2 seconds. Isn’t modern technolgoy wonderful 
When ET opens the pk3 files, it loads the bsp requested by the server, this bsp file then tells the computer what other files are needed to be decompressed from the PK3 file for use in the game. The main reason loading takes so long is both because of the amount of data being loaded and because the data has to be decompressed into a useable format. If you look at games like UT2003 that use uncompressed formats, they are able to load the data extremely fast but use alot more disk space. I think with the larger storage media available today, the future will be uncompressed data packs for rapid loading.
Bizarre fact of the day: The special substance IBM created to allow them to create fast reading high density drives is called Pixie Dust.
LMAO @ almost everything IRONMAN says
although I can’t honestly believe that he is not taking this piss and just winding everyone up with his intentional dumbness
Hmmm. Well, a friend of mine is a programer for the John C. Stennis Space Center, and I have spent many years in his presence. He has used the term “compiling” that way for years. Perhaps that’s where I learned the term, from him, who learned it in college learning Computer Science and to program. Semantics are not important. Many words have more than one meaning. use the one that turns you on if you like. That’s fine with me.
You have missed something, but I can see how you did. I had been discussing how the Covert Ops, Mines, and mortar might be far more worthwhile in a game with much larger maps. Then the discussion moved to random map generation. So ultimately, the topic was very very large “randomly made” maps, which would require more powerful PC’s with much more memory.
With RAID you might see a small increase in load time. Where RAID provides speed increases is in access time only, not load time unless you are trying to load files from two disks at once, which would not likely be the case with any given installation. Two IDE drives make a RAID. That’s all they are… IDE drives. Many people think RAID is some kind of super fast superhero HD setup. It’s not. It does however, increase access time much of the time. I have RAID on my MD and 2 HD’s but the benefit of RAID to me is negligible, so why bother. Besides (and here’s the big disadvantage of RAID) if one HD fails, you lose all of the data on BOTH drives because Windows treats them as a contiguous drive. OUCH! No thanks. HD’s fail. It’s a given.
One more time dude. Read the above to leanrn about the NEW format that maps are in and that they contain more than vertices data.
And that is why a PK3 file contains all the other format files? They are there for looks huh?
Too much Monty Python and beer huh dude?
I always thought the source code would be compiled to machine code, not assembly. I’m not a programmer and I’m not interested in getting mixed up in this throwdown. I’m just interested in knowing.
I was starting to think he’s a wind up merchant, but then he wrote:
THINK
Before you go calling someone a redneck, think more before opening your mouth.
And suddenly it became clear that he’s actually serious. We should feel sorry for him really. If he really is this ignorant (not to mention obstinate) then his life will probably be arduous and depressing. Speaking of which, I made something for someone else the other day that might be more appropriate for him…
I always thought the source code would be compiled to machine code, not assembly. I’m not a programmer and I’m not interested in getting mixed up in this throwdown. I’m just interested in knowing.
I was just using it for an example. What it compiles into depends on your compiler settings. Final release compiles are usually compiled into machine language (or at least very pure forms of assembler) for speed purposes. But when debugging you tend to compile into assembler for readability and to better maintain the link between C++ code and machine instructions.
Pure forms of assembler? You mean “assembly or assmebler language”? An assembler is a program. What “forms”? Compile into assembler? You mean use assembly language to assmeble the assembler? Maintain a link??? Once it becomes machine language there are no links. Now you have an EXE. It seems your knowlege of programming and Borland’s interface is as extensive as your understanding that a PK3 file IS a map file, and not just one part of it, like the BSP or a texture or any other part…
Okay, from the top…
Hmmm. Well, a friend of mine is a programer for the John C. Stennis Space Center, and I have spent many years in his presence. He has used the term “compiling” that way for years. Perhaps that’s where I learned the term, from him, who learned it in college learning to program in C++. Semantics are not important. Many words have more than one meaning. use the one that turns you on if you like. That’s fine with me.
Hey, why not read back a few posts, you’re the one that started bringing semantics into it. You’re the one that knew what context the words were in but tried to turn them round to suit your bizarre contrary position to everyone else involved in this thread.
You have missed something, but I can see how you did. I had been discussing how the Covert Ops, Mines, and mortar might be far more worthwhile in a game with much larger maps. Then the discussion moved to random map generation. So ultimately, the topic was very very large “randomly made” maps, which would require more powerful PC’s with much more memory.
Actually, you were the only one discussing that, everyone else was discussing all the possibilities of random map generation, not just giant maps. This included regular maps randomly made using prefabbed blocks (the idea generally agreed upon to best suit the Q3TA engine)
With RAID you might see a small increase in load time. Where RAID provides speed increases is in access time only, not load time unless you are trying to load files from two disks at once, which would not likely be the case with any given installation. Two IDE drives make a RAID. That’s all they are… IDE drives. Many people think RAID is some kind of super fast superhero HD setup. It’s not. It does however, increase access time much of the time. I have RAID on my MD and 2 HD’s but the benefit of RAID to me is negligible, so why bother. Besides (and here’s the big disadvantage of RAID) if one HD fails, you lose all of the data on BOTH drives because Windows treats them as a contiguous drive. OUCH! No thanks. HD’s fail. It’s a given.
Yes, the main advantage to a type 0 (I think it was 0 anyway) RAID setup is HD failures not causing a loss of data. However, you can also setup up RAID arrays (which I think are called type 1) that will spread data across multiple HDs so that they can all pump data into the CPU much faster using synchronous reads.
Sure did. Download a map for a Q3 engine game. What format is it in? PK3??? REALLY??? Um, you cannot load just a BSP for this game. The format for the maps has changed from BSP to PK3. Just because a part of the map (vertices) is in a BSP file withing the map file (the PK3) does not mean the map is a BSP. What do you not grasp about that? Things have changed since Quake. BSP’s are not the map file anymore. Now they are just part of the map file… which is… tada! a PK3 file. Amazing huh?
Obviously you have not done any map editing for a Q3 game as you can quite easily load a BSP file as the map (assuming you have the related textures/sounds in local folders) - no PK3 necessary. There are a few reasons why maps are released in PK3s:
*) Compressed format - much less space used and faster downloads.
*) Cleaner - less files all over the users HDs. (also results in less fragmentation)
*) Anti-cheating. The PK3s are CRC checked to ensure that no-one has modified their downloaded maps and is trying to cheat.
Now do you see why ID moved to using PK3 to store their files? The engine still uses .bsp format files for map data, but all relevant files are contained neatly in PK3s.
One more time dude. Read the above to leanrn about the NEW format that maps are in and that they contain more than vertices data.
You took the words right out of my mouth
And that is why a PK3 file contains all the other format files? They are there for looks huh?
Too much Monty Python and beer huh dude?
Yeah, the PK3 contains ALL the other files. The ET PK3 contains all the map files, all the textures, sounds, models, etc. You said earlier that only the map the server requests is loaded on the client machine - yet now you turn around and say the whole PK3 is loaded.
Is any of this getting through yet? Are you going to ever open your mind to the possibility that you are wrong and that everyone else is right? Crazy as that may seem to you? (schizophrenics often beleive they are right and the whole world is wrong, you might want to seek out a shrink)
And what have you got against Monty Python? Some of the funniest people who ever lived they were/are.
Pure forms of assembler? You mean “assembly or assmebler language”? An assembler is a program. What “forms”? Compile into assembler? You mean use assembly language to assmeble the assembler? Maintain a link??? Once it becomes machine language there are no links. Now you have an EXE. It seems your knowlege of programming and Borland’s interface is as extensive as your understanding that a PK3 file IS a map file, and not just one part of it, the BSP part.
Okay, I’ll explain this in terms you might understand as well…
There are multiple forms of assembler language available due to multiple CPU types and multiple instruction sets. The terms assembler and assembly language are accepted as inter-changeable definintions of the instructions that make up an assembly language and ergo are the same in my uses of them. Because of these multiple assembler variants, there are “pure” forms that use only the instructions related to “x86” processors. EG they don’t use intructions specific to AMD 3DNow+ chips or Intel equivalents. That is what I was referring to by “pure” assembler.
Maintiaining links between source and complied code: When compiling in debug mode (in Visual Studio at least) it is possible to halt, modify and re-execute the code - this is know as “hold and modify” debugging. In this form, the code is converted to assembler but ran through an interpreter not in pure machine language form. This way the compiler can maintain the links between the source code instructions and the assembler instructions, making it easier to locate bugs. There is also “step debugging” where the code is in assembler, but you cannot modify it, only step through it to locate the errors. When you compile a final release, the code is compiled into pure machine language and all debugging facilities are removed from the code, making for smaller and much faster code.
Nobody agreed to anything. We were only discussing it. However, you are free to agree with yourself if you like.
Correct. However, RAID still puts all of your data at risk. When HD’s never fail (which will be never as long as they are mechanical) or are replaced with memory chips (coming soon to a store near you) and when the BIOS is finally gone forever (also coming to a store near you, possibly next year) I might consider a RAID array.
But the files within a PK3 ARE NOT located anywhere else. The game maker did not make the game that way. The files necessary for a map are in the map file - the PK3
waiting for that to sink in
Look in all of your subfolders for RTCW and Wolf ET. Do you see any textures or vertices files or brushes? No. Why? Because they are in the MAP FILE - the PK3 file.
waiting for that to sink in
You are stuck in the past. The map file is a PK3 file. The BSP is a part of the map file because it contains more than vertices data. once more: BSP files are no longer the map files for Q3 engine games!
waiting for that to sink in
I will not respond to your insolent and hateful comments. I do not want to stoop.