Review IWD2 review at GameAxis

[Sheriff_Fatman]

Oh dear. You guys really are either completely clueless or would rather dig your hole deeper than admit you're wrong. I'm not going to be able to move you on this, I understand.

However, I do think the other readers of RPGCodex have a right to know exactly how much they can rely on the opinions of S_P. Let's face it, he doesn't stint in giving them (looking down the old threads, it looks like he tries to have the last word wherever he can) and he IS criticising real development companies on a regular basis, after all.

I understand that noone here knows me and that S_P has spent a long time projecting an image of authority by not letting anyone else have an opinion. So, don't take it on faith from me - ask someone who should know. The links below are for the MSDN Magazine. To put that in perspective for people not in professional development (which I sincerely hope includes Rosh and S_P), this is the official magazine for the official developer network for Microsoft - the makers of the O/S and the DLL architecture in question.

• Exhibit A: An In-Depth Look into the Win32 Portable Executable File Format. This is an explanation of how PE (portable executable) files, including both EXEs and DLLs, work.

  • ... The distinction between EXE and DLL files is entirely one of semantics. They both use the exact same PE format. The only difference is a single bit that indicates if the file should be treated as an EXE or as a DLL. Even the DLL file extension is artificial. ...

  • The author, Matt Pietrek, writes debuggers for a living. This requires him to understand software architecture. Saint_Proverius mules content from other sites and was involved in a Quake II mod. You can decide for yourself who knows best.
• Exhibit B: An article on DLL entry points. I'm including this because one of the few actual things Rosh has put forward amongst his smokescreen of personal attack, it that DLLs have no entry point.

  • A DLL can optionally specify an entry-point function. If present, the system calls the entry-point function whenever a process or thread loads or unloads the DLL. It can be used to perform simple initialization and cleanup tasks. For example, it can set up thread local storage when a new thread is created, and clean it up when the thread is terminated.

As for dumb clients, there seems an all too obvious place to send you two idiots. Note the "dumb client" section and particularly note the difference between this and more balanced client-server models.

Even if we ignore the strictest definition of a dumb client (where no data is stored locally), for a system to have a dumb client, THE CLIENT DOES NOT PERFORM APPLICATION LOGIC. I'll admit, the Quake architecture has a lot thinner client than I would have initially guessed (since this thinness is paid for in bandwidth), but it is not a dumb client. If it were, cheating would be virtually impossible.

Which brings me onto your pet DLL. Client-side mods for Quake perform logic within that DLL. They don't just use it to point to graphics. How do yu think people use it to create bots if it is not capable of performing logical functions? If Quake really WAS entirely processed on the server, cheating would be very rare. Clearly, that's not the case.

Now, I've been very tolerant. I let you start off talking about Counterstrike, then move onto Quake at your convenience. I let you talk about Quake to the exclusion of other FPS (which may have fatter clients and different modding architecture). But don't keep trying to feed everyone this shit. It's nonsense and all you're proving is that you're willing to be dishonest to pretend to make a point and that you have some serious gaps in your knowledge. Your last couple of posts demonstrated, for instance:

• You don't understand the difference between a mark-up language and a programming language (eg. you can't tell HTML metadata from logical code)
• You can't tell the difference between a data structure and a program (eg. you think a list can be executed)
• You don't understand the distinction between "executable" and "Windows executable" (eg. you think something has to run on a Windows O/S to be considered executable)
• You don't understand the difference between compilation and execution (eg. You thought that just because lib files cannot be executed, DLLS can't either)
• You don't can't tell a client-server architecture from a host processing architecture (eg. everything you've said on dumb clients)

Stop digging your hole, S_P. Be a man, suck it up, and try to win some credability back by showing everyone you can admit when you're wrong. I have NEVER seen you admit to being wrong or even to the possibility of being wrong. Noone is infallible, so you must have been bull-dozing over those times when you've been wrong so far. That might increase your standing with people who don't know much or people who are only interested in seeing others put down (like Rosh), but it isn't going to get you any respect from anyone else. If that doesn't sway you, at least think of the other admins. They're loyally backing you and sharing any embarrassment resulting from you posts.

BTW, do you realise that you're currently arguing for DLLs not to be considered part of the codebase, when Rosh's initial criticism of NWN was that it is not as good for modding as FPS because it doesn't let you modify the codebase? Just thought I'd point it out.

 

[Saint_Proverbius]

Exhibit A: An In-Depth Look into the Win32 Portable Executable File Format. This is an explanation of how PE (portable executable) files, including both EXEs and DLLs, work.

• ... The distinction between EXE and DLL files is entirely one of semantics. They both use the exact same PE format. The only difference is a single bit that indicates if the file should be treated as an EXE or as a DLL. Even the DLL file extension is artificial. ...

• The author, Matt Pietrek, writes debuggers for a living. This requires him to understand software architecture. Saint_Proverius mules content from other sites and was involved in a Quake II mod. You can decide for yourself who knows best.

• 
  
  I honestly don't care what Matt Pietrek says. Anyone with any classical CS training is taught from the first classes that there are two types of file on a computer, data and executable. An executable is a file that you can execute and it'll run. A DLL requires an existing and loaded application to run.
  
  That's the way it's been even before there was a Windows. UNIX has used library files since the beginning. They've always been considered data. MicroSoft can write all the papers and cliffnotes they want on the subject, it won't change the definition for people who know better. There's nothing MicroSoft likes to do more than fuck up long standing conventions they didn't make or own the copyright to - kind of like them wanting to patent the computer word, "Window" when it's been a standard convention for GUI interfaces since the 1970s.
  
  However, MicroSoft is rather silly in their definition since they claim that even an EXE with ports allowing access threading is a DLL, when it's really just an EXE that's multithreaded and has ports. It's called a HOST APPLICATION, since it provides a host of functions for all applications currently running.
  
  Oh, and you don't have to understand "software architecture" to write a debugger. A debugger is a really fancy, interactive source code/assembly interpretter. Basically, they go through the source code, line by line, listing all the variable values, memory states, etc. through the course of the interpretations of the code. Hell, there's even AI programming games that have full featured debuggers. Stuart Mark's Omega had one, for example. A lot of emulators have debuggers in them as well, only on a machine code level.
  
  It's also funny that you're claiming I'm muling stuff from other sites when you're the only one on this thread posting URLs here. I'm not the one that's having to run to Google to continue this argument, that'd be you.
  
  

  Exhibit B: An article on DLL entry points. I'm including this because one of the few actual things Rosh has put forward amongst his smokescreen of personal attack, it that DLLs have no entry point.
  
  

  A DLL can optionally specify an entry-point function. If present, the system calls the entry-point function whenever a process or thread loads or unloads the DLL. It can be used to perform simple initialization and cleanup tasks. For example, it can set up thread local storage when a new thread is created, and clean it up when the thread is terminated.

  
  What they're talking about here is what I've mentioned above. Things like KERNEL.EXE, which is an executable that has ports and is multithreaded. They want to call things like that a DLL, more power to them. However, they're not libraries! That's like claiming RX_HOST for REXX is a library, but it's actually script interpretter and provides functions for REXX scripting. It has ports, allowing the script access to these functions and allows threading so that more than one script at a time has access to these things.
  
  In fact, all multitasking OSes have kernals like this, and they're all executed at the start of the OS launch. They all provide layers of things that all programs have access to, but they're certainly not library files. This is so that all programs have access to the hardware, which is what the OS is there to give you so you don't have to keep writing and reading directly to those devices.
  
  Now, there are also DLLs, like printer drivers, which may have to spawn tasks, like spool applications. Those have an entry point because the spool application requires one to be it's own task. However, that entry point isn't an entry point for the DLL itself, just a spawned process the driver has to be able to do. Then again, the drivers don't have to work this way. You can easily have such a task outside of the driver files themselves that the drivers launch with either command line args or call to the ports in the spool application itself.
  
  If it had a main entry point for the entire DLL, then it'd be an EXE, and not a LIBRARY. It would be a HOST APPLICATION like KERNEL.EXE, SHELL.EXE, etc.
  
  

  Even if we ignore the strictest definition of a dumb client (where no data is stored locally), for a system to have a dumb client, THE CLIENT DOES NOT PERFORM APPLICATION LOGIC. I'll admit, the Quake architecture has a lot thinner client than I would have initially guessed (since this thinness is paid for in bandwidth), but it is not a dumb client. If it were, cheating would be virtually impossible.

  
  That's not true at all. The reason cheating is possible on Quake clients is because those cheats involve things such as smart proxies, which take information from the server and then send things back to the server faster than a player can react to it.
  
  Case in point, "aim bots" are programs which aim, and may fire, for the player. The reason they work is because the server send information on an enemy player's location to the client. The proxy intercepts this and then sends the server a packet saying that the player is now turning to the facing of the enemy, the server then sends the new orientation to the client.
  
  Cheating is possible with dumb clients, but it requires a proxy for the most part. However, the physical rules still apply, such as how much damage a weapon will do, how many hit points a player has, what weapons they have, and so on.
  
  Wallhacks are another form of cheating, but those involve hacked drivers or map files.
  
  

  Which brings me onto your pet DLL. Client-side mods for Quake perform logic within that DLL. They don't just use it to point to graphics. How do yu think people use it to create bots if it is not capable of performing logical functions? If Quake really WAS entirely processed on the server, cheating would be very rare. Clearly, that's not the case.

  
  *cough* PROXIES *cough*
  
  

  Now, I've been very tolerant. I let you start off talking about Counterstrike, then move onto Quake at your convenience. I let you talk about Quake to the exclusion of other FPS (which may have fatter clients and different modding architecture). But don't keep trying to feed everyone this shit. It's nonsense and all you're proving is that you're willing to be dishonest to pretend to make a point and that you have some serious gaps in your knowledge.

  
  Show me where I've talked about Counter Strike, please.
  
  

  Your last couple of posts demonstrated, for instance:
  

  • You don't understand the difference between a mark-up language and a programming language (eg. you can't tell HTML metadata from logical code)
  • You can't tell the difference between a data structure and a program (eg. you think a list can be executed)
  • You don't understand the distinction between "executable" and "Windows executable" (eg. you think something has to run on a Windows O/S to be considered executable)
  • You don't understand the difference between compilation and execution (eg. You thought that just because lib files cannot be executed, DLLS can't either)
  • You don't can't tell a client-server architecture from a host processing architecture (eg. everything you've said on dumb clients)

You're the one that brought up scripts, Fatman. UnrealScript is nothing more than a series of text files, just like a batch file and just like HTML. They require a parser to make them do things.

BTW, do you realise that you're currently arguing for DLLs not to be considered part of the codebase, when Rosh's initial criticism of NWN was that it is not as good for modding as FPS because it doesn't let you modify the codebase? Just thought I'd point it out.

DLLs aren't part of the engine, nor are they executables. They are a codebase.

 

[Rosh]

(snip a whole shitload of Windows kiddie bullshit)

BTW, do you realise that you're currently arguing for DLLs not to be considered part of the codebase, when Rosh's initial criticism of NWN was that it is not as good for modding as FPS because it doesn't let you modify the codebase? Just thought I'd point it out.

That is the biggest load of horseshit I've ever heard, you ignorant, waffling twat.

I'd also like to point it out that you CAN modify the codebase, if you have the source of the main executable. Which many FPS games do have that, in case of the minority of mods I mentioned of "Total Conversions", where they modify the MAIN EXECUTABLE. Half-Life's mods like TFC and CS aren't truly TCs, as aren't the majority of other FPS mods. A good example is the number of DOOM mods out there, where they have used the original codebase and altered it to support more modern computers.

Does NWN give you the source to edit the main executable? NO? KTHXBYESTFU!
Plus, I seriously doubt they have "droppable" DLL support like FPS games, either, and you're still basically stuck to editing within the limitations of what the programmers still have flawed. Check the link in my sig for more, and how they've (BioWare) handled the bug reports to alert other GMs on a user-to-user basis. Hey, there's a reason why VALVe works well with their 3rd party devs.

It was entirely too predictable that you would go running off to MicroSoft's website. Yes, pet your overpriced MS certification, which will be obsolete the next version released. They need the suckered idiots like you.

Of course, then I could also mention the little "dummies" book had absolutely nothing on "thin clients". Also, I could mention that "dumb client", in relation (context, in deference fo Sheriff Fuckwit, since he loves to twists things out of such with the use of hyperbole and tangents) to game clients and servers, has an explicit meaning very similar to that of the original usage. The common usage of "thin client" is basically meaning a front-end to a server. A thin client is basically a user-end client to a service, commonly called "client" in gaming, without any specifics of it's functions. "Thin client", and especially "fat client", couldn't really be used in the structures of certain server setups, since there isn't really any defind point where critical calculations are NOT performed on the client side, and since it's bscially just a front-end, something is needed to define a specialized removal of all game-critical calculations from the client. Therefore, "dumb client", where NO gameplay-related calculations are made on the client's side, is used. It's not really said as such in a commercial capacity or to the users, because only developers of akin games would care about such significance.

Try again, retard, when you have a clue. No, wait. Hang up the browser and stop wasting bandwidth.

 

[Sarvis]

There's two types of file on a computer. There's executables and there's data. DLLs require an executable to load them and run them, that means they aren't executables.

I hate to resurrect such an ancient thread, but someone linked to it and then that statement hurt my brain.

 

[Astromarine]

ouch. ouchouchouchouch.

It can does be nap tiem now pliz?

 

[Ladonna]

Thats ok, it seems reviews (especially for indy's) are becoming more and more scarce around here anyway.

Teudogar and Geneforge 3 are still 'to be written' by the looks of things....

 

[Sarvis]

Thats ok, it seems reviews (especially for indy's) are becoming more and more scarce around here anyway.

Teudogar and Geneforge 3 are still 'to be written' by the looks of things....

Hah! Of course it's easy to explain why: No one at the Codex likes gaming as much as they like bitching. Covering games that might be good like Geneforge 3 doesn't allow for enough bitching.

 

[stargelman]

Haha... oh god, what a pathetic debate they had going there!

 

[Texas Red]

God damnit, yet again somebody expressing their necrophiliac desires through resurrecting dead threads.