Review IWD2 review at GameAxis

[Rosh]

Of course it makes use of the original code. That doesn't get around the fact you still have a different client for every mod and still have a very large download to get there.

YOU DON'T DOWNLOAD A CLIENT, YOU DOWNLOAD A PATCH THAT ALTERS THE EXISTING CLIENT AND ASSOCIATED MATERIALS.

Dodge your way out of that, fool.

No, the server does not do "basically everything." The client does a whole lot of things, centered around processing the data from the server and making it meaningful on the player's machine (and of course returning information to the server). On platforms other than network terminals, the client also does all the interaction with the O/S of the client machine.

The point was, in case you missed it, the server does all the calculations, all the resolutions, it waits for player input, calculates, and then sends what the results are to be displayed into the gameplay calculation-vacant client to be displayed to the user.

In an operational integrity of the game and for the purposed of MMORPG dumb clients, the server does everything in regards to the game, except provide a pretty little display for the sheep on the far end.

"Dumb client" is inaccurate in the way you are using it. Dumb clients would not be possible for a computer game, or any app running on a PC. The best you can hope for is a thin client.

In this application, all server-side calculations are what makes a dumb client for MMORPG gaming, to prevent exploits. MMORPGs use them, RTS games are running into requiring anti-cheat technology because they are not dumb clients.

There is something called UOX. It emulates UO's servers, where the cost-free server admins can do whatever they want in terms of development, and it will still use the official UO client without any client-side patches.

The funny thing is, they can add in new skills and other material quite easily, no patching required on the client's part or anything needing to implement this. All the changes are done to the server and all the player needs to do is change some config settings and they can play.

This is number (2) on my list, above.

No, it isn't.

2) update every server (or build a new server) everytime time a new client is released.

The ONLY case this might even be true is if they drastically changed the protocol or client. But then again, what if the player decides to not update with OSI's regular patching and keeps to the 3rd party server?

Didn't think of that, did you? It puts a nice, gaping hole into your (nonexistent) argument.

 

[Rosh]

The DLL is part of the client software, S_P. So are the scripts to use it. The distinction being that it is software deployed onto the client machine in order to run the game. Being in the compiled exe isn't the distinction, or half the files installed during the game installation would have to be considered not part of the client, despite the fact the game seriously breaks if you delete them.

So:

Downloading a patch with new DLLs = downloading a different client.

Sorry, that doesn't match up. Dodge failed. Parts and pieces additional to a program are not a completely new program in themselves.

FYI, again, most of the size from downloaded mods are from maps, new graphics, and sound files.

The actual code patch is relatively small.

Now don't you look like a moron who doesn't know what they are talking about, again?
Correction. Still.

 

[Saint_Proverbius]

The DLL is part of the client software, S_P. So are the scripts to use it. The distinction being that it is software deployed onto the client machine in order to run the game. Being in the compiled exe isn't the distinction, or half the files installed during the game installation would have to be considered not part of the client, despite the fact the game seriously breaks if you delete them.

Actually, it's the server that typically runs the DLL and scripts since the clients, for the most part, are like Rosh said.. dumb clients. Some have both client and server side DLLs, like Soldier of Fortune, but most don't.

There is no altering of the client itself. You don't edit the client in any way, shape, or form. You merely plop a DLL in a new directory(for the server) as well as the content like maps, models, and skins.

Adding data != Changing client

And scripts are no more part of the client than maps and models are. They're just data.

 

[Rosh]

There is no altering of the client itself. You don't edit the client in any way, shape, or form. You merely plop a DLL in a new directory(for the server) as well as the content like maps, models, and skins.

Except for adding onto FPS games (not changing, still). Most of the work for FPS games are now being done on the server side, and where the real patch is. A lot of FPS mods have client and server in one, for ease, but not all do. Natural Selection is just one that has separate parts, as do dedicated servers.

About the skins, models, and maps, it depends on the game. In UOX, it's server side, and supplemented gradually to the client side, but still requiring no patching of any sort on the client side.

 

[Saint_Proverbius]

I still wouldn't call a DLL a "patch", since you're not altering the code base of the server itself. You're altering an extension of it, something external to it.

A patch typically means something that fixes the bugs in the program itself.

 

[Rosh]

I still wouldn't call a DLL a "patch", since you're not altering the code base of the server itself. You're altering an extension of it, something external to it.

A patch typically means something that fixes the bugs in the program itself.

True, but in that part I was referring to total conversions, where they clone the executable and other things to edit them with a mod patch.

 

[Sheriff_Fatman]

Of course it makes use of the original code. That doesn't get around the fact you still have a different client for every mod and still have a very large download to get there.

YOU DON'T DOWNLOAD A CLIENT, YOU DOWNLOAD A PATCH THAT ALTERS THE EXISTING CLIENT AND ASSOCIATED MATERIALS.

Dodge your way out of that, fool.

You're playing on a new client, created by applying the patch you had to download. Sure, you don't download the whole client, but you still download a large patch.

The point was, in case you missed it, the server does all the calculations, all the resolutions, it waits for player input, calculates, and then sends what the results are to be displayed into the gameplay calculation-vacant client to be displayed to the user.

In an operational integrity of the game and for the purposed of MMORPG dumb clients, the server does everything in regards to the game, except provide a pretty little display for the sheep on the far end.

Over and above graphics rendering, the client also does all the event capturing and processing and handles its end of the communication with the server. One of the things people overlook in over-simplified client-server theoretical models is that the protocol used between server and client to send information can itself limit the functionality of the client. Although you CAN change the server in anyway you like, you can't change it outside the bounds of what can be communicated in the protocol without updating the client.

In other words, the changes you can make to the game are still limited without being able to update the client.

The funny thing is, they can add in new skills and other material quite easily, no patching required on the client's part or anything needing to implement this. All the changes are done to the server and all the player needs to do is change some config settings and they can play.

This is number (2) on my list, above.

No, it isn't.

2) update every server (or build a new server) everytime time a new client is released.

Are seriously trying to say they alter the games codebase without patching the client or updating the server software?

 

[Rosh]

Of course it makes use of the original code. That doesn't get around the fact you still have a different client for every mod and still have a very large download to get there.

YOU DON'T DOWNLOAD A CLIENT, YOU DOWNLOAD A PATCH THAT ALTERS THE EXISTING CLIENT AND ASSOCIATED MATERIALS.

Dodge your way out of that, fool.

You're playing on a new client, created by applying the patch you had to download. Sure, you don't download the whole client, but you still download a large patch.

That's one hell of a stretch, even for you. Also, nice dodge attempt out of the load of shit you were saying earlier about "Also, I don't play CS, but as I understand FPS mods, you have to download a seperate (very large) client to run the games with alternate codebase. "

Again, make up your mind, get a clue, or hop the fuck out of the discussion and stop wasting our time and bandwidth.

Now, since it appears you don't have a single damn clue, I'm going to shred your bullshit to pieces, again.

Here's the command line to load up TFC:
D:\SIERRA\Half-Life\hl.exe -console -game tfc

Notice how it uses the same client?

Now shut the fuck up, moron. (BTW, this is here for your own good, you've made yourself look like an idiot already. it's getting quite pathetic how you'll go to great lengths to prove yourself a clueless, argumentative retard.)

Over and above graphics rendering, the client also does all the event capturing and processing and handles its end of the communication with the server. One of the things people overlook in over-simplified client-server theoretical models is that the protocol used between server and client to send information can itself limit the functionality of the client. Although you CAN change the server in anyway you like, you can't change it outside the bounds of what can be communicated in the protocol without updating the client.

In other words, the changes you can make to the game are still limited without being able to update the client.

Which, in the case of UOX, are quite expansive because the UO client is still a dumb client. In fact, with the interface, it can put in new aspects quite easily and some UOX devs have surpassed that of the official game in some ways by just editing the server-side. No client-side patches needed.

Too bad your above is some of the most vapid crap I've ever heard. It's like saying that MUDs are limited to the capabilities of telnet, though they have scripting that has surpassed that of most commercial graphic MMOPRGs. The protocol is the same regardless upon what client you use, the format is still the same, the clients just offer different flavors. Because they are dumb clients, because...everything of importance to the game's operation is done on the server-side.

2) update every server (or build a new server) everytime time a new client is released.[/b]

Are seriously trying to say they alter the games codebase without patching the client or updating the server software?

No, and you can cut that bullshit right there before you attempt to pursue that mouth-stuffing. Too bad, like the clueless waste of bandwidth you are, you couldn't understand what I was writing about before. Also, I'm suspect you could only half-quote me to twist this further into one of your rather nonsensical dodges and cop-outs.

If they update telnet, does that mean that mean every MUD will have to change their codebase? It's also been pointed out that UOX could change features or some parts on it's side, while still using the dumb client of the UO client, without requiring a patch of said UO client.

For your information, TFC and other mods do change server-sides a lot more than anything on the client side because most of the work is done on the server side. They might put in new features that might require a client-side patch, but that's because HL isn't really a dumb client. You'll find more games coming out now that will put the actual work on the server-side to prevent cheats. Much like how most MMORPG clients are interface-tailored dumb clients that have no affect upon the game itself because all calculations and work is done on the server-side.

Too bad along with your lack of a clue about FPS mods, you seem to be quite ignorant about this.

 

[Sheriff_Fatman]

That's one hell of a stretch, even for you. Also, nice dodge attempt out of the load of shit you were saying earlier about "Also, I don't play CS, but as I understand FPS mods, you have to download a seperate (very large) client to run the games with alternate codebase. "

Yes, I did say that. Yes, in literal terms it was a little inaccurate. I retract it. I'll say instead: Also, I don't play CS, but as I understand FPS mods, you have to download a seperate (very large) addition to the client to run the games with alternate codebase.

You're dwelling on literal wording, because you know the essence of what I said is entirely accurate, as anyone can verify for themselves.

Here's the command line to load up TFC:
D:\SIERRA\Half-Life\hl.exe -console -game tfc

The exe is not the the only component of the client software. There are others, such as DLLs. DLLs are bound to the exe at runtime (hence their name). When you launch the exe, any DLLs it uses are applied to it, to create a new program, which is held in memory while you play. Yes, they are easier to extend, because they are part of a component based architecture, but they do have limitations in terms of changing the codebase for an app. The DLL's interface must not be changed, for example.

Maybe TFC doesn't extend the client-side Halflife DLLs, I don't know. S_P mentioned that some FPS mods only require changes on the server. However, as I have said, that kind of architecture will in itself limit the ability to change the codebase and will also require updates to all live servers wanting to run TFC.

If they update telnet, does that mean that mean every MUD will have to change their codebase? It's also been pointed out that UOX could change features or some parts on it's side, while still using the dumb client of the UO client, without requiring a patch of said UO client.

A Telnet terminal IS a dumb client. A telnet app on a PC emulates a dumb client, but is still a thin client. You are limited to the changes you can make to a Telnet client without requiring an update to the server (not the MUD, the server) by the protocol. None of the changes you make to the client will affect the games' codebase, unless the game running on the client has some dependent software supplementing the capabilities of the Telnet client. If DO change the client (even if you don't change it enough to require an update to the server) and you want all players of your game to benefit from your changes, the new client has to be deployed to every player of the game.

A dumb client would actually be a very undesirable architecture for a modern online game, because it leads to larger packet sizes. Keeping packets as small as possible is one the headaches facing current developers.

It's worth noting, a few things to get this back in perspective, since quizzing me about well-known architectural and programmatic issues is quite abstracted from the point.

1) A Telnet client on a PC is MUCH thinner than an FPS client. It is able to be so, because its capabilities are very limited.
2) FPS modding, being only concerned with emulation of a narrow range of physical phenomena are much more centred around graphics than an RPG mod (eg. no NPC interaction, character progression or inventory elements). Some of the more RPG bias FPS (like Deus Ex) are nearer.
3) Modifying a games codebase is not central to a game aimed at letting players create adventures, as has been said elsewhere. It is you that put it forward as some crucial point.

Can I ask you, again, to stop with the flaming content? The mods might not mind it, but it really doesn't add anything to the discussion except some minor diversions from the rest of what you say in your post. Are you deliberate trying to divert attention from the point? If not, I suggest you stop doing it.

 

[Rosh]

That's one hell of a stretch, even for you. Also, nice dodge attempt out of the load of shit you were saying earlier about "Also, I don't play CS, but as I understand FPS mods, you have to download a seperate (very large) client to run the games with alternate codebase. "

Yes, I did say that. Yes, in literal terms it was a little inaccurate. I retract it. I'll say instead: Also, I don't play CS, but as I understand FPS mods, you have to download a seperate (very large) addition to the client to run the games with alternate codebase.

Which is still wrong. It's using the same codebase, but with something else. it starts with an "r". Do you have the intelligence to figure out what that might be?

As you understand FPS mods, you don't.

You're dwelling on literal wording, because you know the essence of what I said is entirely accurate, as anyone can verify for themselves.

BULLSHIT!

Here's the command line to load up TFC:
D:\SIERRA\Half-Life\hl.exe -console -game tfc

The exe is not the the only component of the client software. There are others, such as DLLs. DLLs are bound to the exe at runtime (hence their name). When you launch the exe, any DLLs it uses are applied to it, to create a new program, which is held in memory while you play. Yes, they are easier to extend, because they are part of a component based architecture, but they do have limitations in terms of changing the codebase for an app. The DLL's interface must not be changed, for example.

A component, but not a separate client as you so inferred repeatedly. Again, you're trying to blur your previous case of Foot in Mouth Disease. Sorry, in your case it's Head up Fat Ass Disease.

Maybe TFC doesn't extend the client-side Halflife DLLs, I don't know. S_P mentioned that some FPS mods only require changes on the server. However, as I have said, that kind of architecture will in itself limit the ability to change the codebase and will also require updates to all live servers wanting to run TFC.

No, it on'y will require an update to any server that wants to support it. Not every one of them. Again, get a clue.

A Telnet terminal IS a dumb client. A telnet app on a PC emulates a dumb client, but is still a thin client. You are limited to the changes you can make to a Telnet client without requiring an update to the server (not the MUD, the server) by the protocol. None of the changes you make to the client will affect the games' codebase, unless the game running on the client has some dependent software supplementing the capabilities of the Telnet client. If DO change the client (even if you don't change it enough to require an update to the server) and you want all players of your game to benefit from your changes, the new client has to be deployed to every player of the game.

I think I pointed this out previously. Must make for good padding on your post, no? It's also a fair cry from the absurd "every server would need to update".

A dumb client would actually be a very undesirable architecture for a modern online game, because it leads to larger packet sizes. Keeping packets as small as possible is one the headaches facing current developers.

But a very required one since you need to keep the client as dumb as possible to prevent exploitation. In fact, a dumb client keeps the packets thin because all it does is relay the basic instruction to the server, and the server spit back out the results. Which in turn are basically thin themselves but expanded upon a bit by the client-side through data interperetations. The real problem with dumb clients is that the server must be able to handle calculating everything since it is designed to.

The problem with larger packets stems from trying to synch the game in and provide support for higher ping times and massive data transfers of more complex games, NOT because of dumb clients.

Nice try again, dipshit.

(snip some enumerated tangent attempt bullshit)

Can I ask you, again, to stop with the flaming content? The mods might not mind it, but it really doesn't add anything to the discussion except some minor diversions from the rest of what you say in your post. Are you deliberate trying to divert attention from the point? If not, I suggest you stop doing it.

Would you stick your hand into a beehive and then bitch about getting stung? No?

Then why are you bitching about what you receive in return for trolling?

 

[Sheriff_Fatman]

The exe is not the the only component of the client software. There are others, such as DLLs. DLLs are bound to the exe at runtime (hence their name). When you launch the exe, any DLLs it uses are applied to it, to create a new program, which is held in memory while you play. Yes, they are easier to extend, because they are part of a component based architecture, but they do have limitations in terms of changing the codebase for an app. The DLL's interface must not be changed, for example.

A component, but not a separate client as you so inferred.

A component OF the client. Required to play the game. Try deleting your DLLs from your game install directory and see how well it runs.

o, it on'y will require an update to any server that wants to support it. Not every one of them

Well spotted, you are entirely correct. You only need to update the server to actually use your new code. It is entirely feasible to leave it unused.

But a very required one since you need to keep the client as dumb as possible. In fact, a dumb client keeps the packets thin because all it does is relay the basic instruction to the server, and the server spit back out the results. Which in turn are basically thin themselves but expanded upon a bit by the client-side. The real problem with dumb clients is that the server must be able to handle calculating everything since it is designed to.

This is full of inacuracies. You cannot have degrees of dumbness for clients. It's either a dumb client or a thin client - two very different things. As I have stated previously, an FPS runs with a thin client.

Then why are you bitching about what you receive in return for trolling?

I am civilly stating an opinion. How am I trolling? Unless it is trolling to hold an opinion different to yours.

It really seems like you're saying "You know that if you disagree with me I'll flame you, so disagreeing with me is deliberate provoking flames," which is ludicrous.

 

[Vikjunk]

I am civilly stating an opinion. How am I trolling? Unless it is trolling to hold an opinion different to yours.

It really seems like you're saying "You know that if you disagree with me I'll flame you, so disagreeing with me is deliberate provoking flames," which is ludicrous.

Rosh post this earlier on another thread about you:

You're known as a troll because you post stupid, incorrect shit, and then persistently attempt to dodge your way out of it using some of the most cowardly "tactics" that also include mouth-stuffing and lying.

Thank you for coming, but please don't come again...

 

[Saint_Proverbius]

A component OF the client. Required to play the game. Try deleting your DLLs from your game install directory and see how well it runs.

The same thing goes for the data files like maps and textures. Try deleting those and see how well the client runs. The client is the executable, the scripts, DLLs, maps, and everything else is just data.

However, considering that with most Quake based games, you actually CAN delete the gamex86.dll that comes with the mods and still play multiplayer just fine.. Well, that kind of hurts your argument, doesn't it?

This is full of inacuracies. You cannot have degrees of dumbness for clients. It's either a dumb client or a thin client - two very different things. As I have stated previously, an FPS runs with a thin client.

No, most clients are dumb clients with FPS games. The client with Quake engine games, with few exceptions, just does I/O and that's it.

I am civilly stating an opinion. How am I trolling? Unless it is trolling to hold an opinion different to yours.

How FPS games work aren't subject to opinion. They are quantative, not qualitative. You can actually measure how dumb they are by deleting the gamex86.dll, which you brought up.

It really seems like you're saying "You know that if you disagree with me I'll flame you, so disagreeing with me is deliberate provoking flames," which is ludicrous.

Actually, I'd say it has more to do with him knowing what he's talking about and you arguing with him about it even though you admit you lack experience.

 

[Sheriff_Fatman]

I don't know how to explain it to you any clearer if you believe DLLs are just data. They are not.

There are a number of reasons why deleting a particular DLL might not affect all functional areas of a program. There are also situations where you can substitute one version of a DLL for another. That doesn't change their criticality, it just means that by not trying to use the functions they support, you're avoiding encountering the problem caused by its absence.

 

[Saint_Proverbius]

I don't know how to explain it to you any clearer if you believe DLLs are just data. They are not.

There are a number of reasons why deleting a particular DLL might not affect all functional areas of a program. There are also situations where you can substitute one version of a DLL for another. That doesn't change their criticality, it just means that by not trying to use the functions they support, you're avoiding encountering the problem caused by its absence.

The fact you can delete the gameplay DLL means it's a dumb client, dumbass. It's that simple.

This would be a fantastic time for you to admit you're wrong about what an FPS mod is.

 

[Sheriff_Fatman]

The fact you can delete the gameplay DLL means it's a dumb client, dumbass. It's that simple.

This would be a fantastic time for you to admit you're wrong about what an FPS mod is.

Hoho - that's a truly amusing comment from someone who thinks that DLLs are just data like map files. It's even funnier that you think a single DLL in a single FPS can be used to form a general principle.

S_P, you're living proof of what every good developer already knows - any monkey can find their way around an API spec without having to understand what they're doing.

A MUD running on a Telnet terminal, as your toady Rosh pointed out (in what may be a unique instance of him being correct), is a dumb client. When you type your orders, it passes them to the server to interpret and respond to them. For example, seeing your inventory might entail:

1. User types command (say, "Inv")
2. Client passes command to server
3. Server interprets command
4. Server sends response (say, and inventory list as a string)
5. Client displays response string

An FPS is NOT a dumb client. For instance, I currently switch weapons in UT by pressing a number (or scrolling the mousewheel), which works as follows:

1. User presses weapon number
2. Client interprets event
3. Client switches the weapon (logically as well as graphically)
4. Client informs server of changed weapon

If, for instance, I pressed a button for a weapon I did not have, the client would not need to contact the server. It holds that data locally and is capable of using it. This compares to a MUD (where a dumb client is actually used), which has no fucking clue (like you and Rosh) what "inv" means, let alone what the player character is carrying.

Now, so far you have ignored my comments about FPS being a thin client. You probably think it is insignificant and has no real impact on the issue of how we enable people to alter the codebase of an RPG (which is where Rosh introduced this piece of nonsense). You think "dumb" and "thin" are just names, because you do not possess any actual understanding of the architectural issues involved.

It is NOT irrelevant. Consider, in Rosh's "Ooh but NWN doesn't even let you alter the codebase" issue, if I wanted to actually change functionality of an FPS there's a good chance I would need to update the client (yes I know you don't understand, but keep reading and try to learn). Sure, I can swap weapon graphics and change their rate of fire, etc, without too much trouble (even though I DO still have to put software on the client), but what if I wanted to actually change the codebase to implement new functionality? Not just changing grpahics and parameters of the BANG>Damage functionality that already exists, but changing the way the game works.

For example, say (for some mad reason) I wanted UT players to be able to access their inventory in the RPG way, by popping up a box they could drag items into and around in. To do this, I have to change the client logic. Maybe, if I'm lucky, there's a DLL I can extend. Chances are, with the more radical changes, I'll actually have to change the client executable, which means patching.

So - dumbass - stop saying an FPS is a dumb client.

You may be able to fool users who have no understanding of development with your aggressive arguing, and by dragging your friends in to give bogus corroberations. You may even be able to fool code monkeys like yourself, who gain all their knowledge of development from online tutorials and IDE code help. Don't try to feed your shit to me, though.

Frankly, I'm depressed that you are one of the key figures in the fight against RPG banality. You're quite obviously much more interested in your own ego than realities of issues. You'd much rather railroad someone who disagrees with you off a forum, than try to work to achieve an understanding of their viewpoint. By doing this, you are dooming any players you represent to being marginalised and impotent.

I've not to take an aggressive line on Deathy's board until now, despite the constant provocation from you and your toady, but since you don't make the same attempts, I feel okay about writing this. I won't be writing anything else, though, on this forum (wow - I think I heard the cheers from here!). Until there is some real moderation, and it becomes something other than a vehicle for your personal opinion (which basically means until you no longer have mod status in the forums, and someone has balls enough to moderate YOUR input), I can't see that there will ever be any real discussion.

 

[Saint_Proverbius]

Hoho - that's a truly amusing comment from someone who thinks that DLLs are just data like map files. It's even funnier that you think a single DLL in a single FPS can be used to form a general principle.

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. Therefore, they are DATA. Likewise, batch files aren't exes, nor are scripts, since they must be interpretted. However, if you disagree, by all means, go and try to load up Quake 3's gamex86.dll without loading the Quake 3 executable.

S_P, you're living proof of what every good developer already knows - any monkey can find their way around an API spec without having to understand what they're doing.

And you're a blathering idiot. Again, go delete the gamex86.dll for any Quake 2 or Quake 3 mod, and go play online. It works perfectly.

Since the DLL doesn't exist on your computer to tell things what to do, yet the mod still works online.. IT MUST BE A DUMB CLIENT. There's no ifs, ands, or buts about it.

An FPS is NOT a dumb client. For instance, I currently switch weapons in UT by pressing a number (or scrolling the mousewheel), which works as follows:

1. User presses weapon number
2. Client interprets event
3. Client switches the weapon (logically as well as graphically)
4. Client informs server of changed weapon

If, for instance, I pressed a button for a weapon I did not have, the client would not need to contact the server. It holds that data locally and is capable of using it. This compares to a MUD (where a dumb client is actually used), which has no fucking clue (like you and Rosh) what "inv" means, let alone what the player character is carrying.

UT *might* work that way, but the vast majority of the Quake engine games most certainly do not. However, the vast majority of UT functions are handled by the server. Why? Because of cheating. That's why the server handles everything with Quake engine games, with the exception of Soldier of Fortune. Servers, for example, determine if you hit, they determine the damage you do, and so on. When you press that up arrow, the server determines that you will move and how fast you move. All those things are most certainly handled by the server itself because otherwise, it would allow cheating. Just hack the client side DLL/Scripts, and you would rule the day.

Also, under Quake engine games, it's the server that determines the weapon animations, with the exception, once again, of Soldier of Fortune.

Again, if you can play multiplayer without the gameplay DLL, it's a dumb client.

 

[Rosh]

(another dose of clueless and 90% irrelevent and tangential bullshit)

Heh...toady? Again, you prove yourself a clueless twit.
In fact, it was more like Prov visiting the original DAC boards almost 3 years ago. You'd like to believe that this is some grand mastermind scheme against you, but you're just feeling the results of your trolling. Cope with it, or go.

Why don't you just say Vikjunk and everyone else who is pointing out your argumentative idiocy is a toady, too? Sorry, kid, but you've already wet your bed, don't complain about the piss others are adding onto your pillow.

In addition, it's good to show that through your lengthy, clueless, and quite incorrect blathering, you still prove you have NO clue that you are talking about, SF. Just admit it. Or do you have a problem admitting that you were blowing a load of hot air out of your ass and you were caught? Come on, have the guts to say it. Don't be a coward. "I posted incorrect claims about FPS mods and then bullshitted more about it, repeatedly."

Quake and many others, the server handles everything except for the visual interperetation of the servers "string" back to the client. The calculations are on the server side. The client passes the commands to the server and the server handles the real work, much like your example of telnet and MUDs.

Again, you're blurring the issue in this. Or, rather, attempting to blur the topic. You're generalizing FPS clients with the example of the Quake client (and others), with irrelevent bullshit about UT. Fact is, more FPS clients in their multiplayer side are becoming dumb and just passing commands and results back and forth, taking any control out of the client's side due to cheating.

If someone adds a menu or inventory capability to a client, it's still just passing commands to the server, where the server does the interperetation in relation to the game. Therefore your whole "if someone adds to the interface it's not a dumb client" bullshit is quite irrelevent except if someone did alter it to handle some things on the client side. Which would be fairly stupid since that could generate exploits and cheats, so it is why nobody with a clue does that.

"put foo into bar" command line, but just in a graphical interface, where the server would handle putting the items into the right places, rather than do it on the client-side (whcih would be pretty stupid for a multiplayer game, but since you were the one who mentioned it...). The server still does all the work.

Nice try, but you've been debunked again, dipshit.

I've not to take an aggressive line on Deathy's board until now, despite the constant provocation from you and your toady, but since you don't make the same attempts, I feel okay about writing this. I won't be writing anything else, though, on this forum (wow - I think I heard the cheers from here!). Until there is some real moderation, and it becomes something other than a vehicle for your personal opinion (which basically means until you no longer have mod status in the forums, and someone has balls enough to moderate YOUR input), I can't see that there will ever be any real discussion.

Will you just shut the hell up already, clueless troll? At least for your own sake.

There's nothing more pathetic than a troll's whining. Perhaps a troll that posts incorrect drivel and keeps trying to obfuscate from the fact they don't know what the hell they are talking about. Please, do whine some more to Deathy. I'm sure we all could use the entertaiment value of the fabrications much like you've made in nearly every thread you've baited, lied, and posted incorrect bullshit in and have been called at it.

Whining elsewhere is even more comical. "Waaaah! They don't like to play nice and put up with my clueless tripe! I hate them! They suck!"

Then again, you keep mouth-stuffing and misrepresenting me, in such places like here. You truly are a sleazy shit who needs to lie and invent things for their own purpose, aren't you?

 

[Sheriff_Fatman]

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. Therefore, they are DATA.

Hoho - another little gem. DLLs are executable, you tit. If you knew anything about software, for instance understanding the word "program", you would understand this.

Likewise, batch files aren't exes, nor are scripts, since they must be interpretted.

Not that your comment about scripts (which are also programs) is correct anyway, but DLLs are compiled to native code.

However, if you disagree, by all means, go and try to load up Quake 3's gamex86.dll without loading the Quake 3 executable.

Even a rudimentary look at the Quake modding world is enough to expose this for the nonsense it is. The quake architecture consists of an executable and a gameplay dll. The exe supports - amongst other things - multiplayer mode. The gameplay dll is required if you want to make a mod that modifies certain (client side) things. Check Code3Arena if you don't understand it.

Pay particular attention to point 3, on that page, which includes this interesting little fact:

If it's a "server side only mod" then all you need to do is connect to the server (you don't need to download anything). Bang, you're playing! Most mods however require a client download... you'll need to download some stuff and extract it to your quake3\mod_name directory.

Isn't it funny? I have a self-confessed limited knowledge of of FPS mods. Rosh introduced the subject like he's some kind of expert and you come in laying down the law like you know what you're talking about. Yet, my original statement, from which you and Rosh have created 2 pages of pointless (and innaccurate) argument, was correct

The further you have gone with this, the more of your own ignorance and lack of understanding you have exposed. At least Rosh had the sense to realise this a while back and has since then avoided actually saying anything outside of insults. Maybe you should follow his example, so you can limited yourself showing general, rather than specific, ignorance.

The thing is, I don't mind you being wrong. I never mind people being wrong, since nobody knows everything. What bothers me is that you railroad users who know what they're talking about off the site, and continue to put bullshit information forward as the truth.

This little episode has been a real eye-opener for me. Until now, I was inclined to give credit to a fair amount of your opinion without checking up on it. The way you've tried to cover up your own lack of knowledge here, and convince other users (who may not know any better) of inaccurate facts, makes me wonder just how much of what you say is similarly inaccurate.

 

[Rosh]

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. Therefore, they are DATA.

Hoho - another little gem. DLLs are executable, you tit. If you knew anything about software, for instance understanding the word "program", you would understand this.

Ah, the wonderful dodging world of Sheriff Fatman. In one way, DLLs are executables, but in an extremely archaic and for current structure intents and purposes, a misplaced way.

DLLs are technically NOT executable, because they are there for the purpose of being used by other programs as a reference library. Quite literally, a library of functions to look up and use, to manage resources and as resources themselves in some cases. An ADD-ON, not an executable in itself. A DLL does not have an entry-point to run, and therefore it cannot (at least by anyone with good knowledge of programming) be called an executable, since it can't really execute by itself in an OS environment.

Not that your comment about scripts (which are also programs) is correct anyway, but DLLs are compiled to native code.

But they are not executables. Nice try, but your bullshit has been called.

Even a rudimentary look at the Quake modding world is enough to expose this for the nonsense it is. The quake architecture consists of an executable and a gameplay dll. The exe supports - amongst other things - multiplayer mode. The gameplay dll is required if you want to make a mod that modifies certain (client side) things. Check Code3Arena if you don't understand it.

Also, it's amusing that you posted that, when the issue is of dumb clients. You need the gameplay dll to modify certain (client side) things. No shit.

That means...the client is a dumb client UNTIL it's made NOT dumb. But who in their right mind would do that in a multiplayer game anymore? You know, Prov pointed out that Soldier of Fortune did that (which caused all kinds of cheating problems), but you were likely too too busy putting a spin on your earlier bullshit to notice that. Therefore, you CAN delete the gameplay dll in q3 and it will still operate as a dumb client.

Damn, I've never seen someone who was so self-defeating as yourself. Of course, you're going to try and spin your way out of that one, as usual.

Pay particular attention to point 3, on that page, which includes this interesting little fact:

If it's a "server side only mod" then all you need to do is connect to the server (you don't need to download anything). Bang, you're playing! Most mods however require a client download... you'll need to download some stuff and extract it to your quake3\mod_name directory.

Isn't it funny? I have a self-confessed limited knowledge of of FPS mods.

Hey, read that again, dipshit. It also debunks your crap from a few posts ago. It also proves a bit that the Quake server does the work, in the point you quoted. Congratulations. The point where modifications are needed on the client-side are additions, mostly on the graphics side, but not complete clients on their own.

Of course, most Quake modders are amateur programmers, and I'd hazard their profession title to be an inflated one. Quite likely, they work at the district office for McDonald's.

You haven't proven a damn thing at all in regards to Quake 3 aside your ability to use a search engine.

Also: C:\quake3\quake3.exe +set fs_game mod_name

Uses the same client, still. But with different resource-pointers. Care for another weak attempt, or are you going to pull some bullshit about UT out of your ass?

Rosh introduced the subject like he's some kind of expert and you come in laying down the law like you know what you're talking about.

No, you were the one who posted some bullshit and keep dodging. Then, you manage to pull out things to out of your ass in some desperate attempt to have a point and dig out your earlier brain farts. There's a problem, you keep doing it, and with some of the worst examples possible.

Yet, my original statement, from which you and Rosh have created 2 pages of pointless (and innaccurate) argument, was correct

You're hinging this all upon a term mis-used by someone named "SumFuka", possibly used by them for simplicity of their readers. GameSpy readers aren't too particularly bright to begin with. Or are you going to start taking Apple commercials as truth now? After all, they are those completely knowledgeable about their products, so they must be right! (Sarcasm was used in the last sentence, in case you couldn't tell.) There's many things in their articles I'd call wrong for others to easily digest, and at most I'd consider themselves to be a C programmer in the "Sam's Teach Yourself Books" way.

Oh, the comedy.

Note: Even Talps got some bullshit about Diablo II that turned out to be wrong published at infoceptor.com. GameSpy are content whores. Get the picture now?

(snip yet another pedantic load of whining bullshit)

Weren't you leaving?

 

[Sheriff_Fatman]

:ROFL: So many words, yet so little said ...

An executable, flunkyboy, can be executed. Get it? No bullshit interpretations are required. Data cannot be executed.

A DLL does not have an entry-point to run, and therefore it cannot (at least by anyone with good knowledge of programming) be called an executable, since it can't really execute by itself in an OS environment.

It's interface is its entry point, dumbass. Stop looking on your Start menu for it and go learn a little bit about real development.

That means...the client is a dumb client UNTIL it's made NOT dumb

:ROFL:

The point where modifications are needed on the client-side are additions, mostly on the graphics side, but not complete clients on their own.

I only have to make modifications on the client-side if I want to include something that's not there already? Nice reasoning.

:ROFL:

You know, I don't suppose I should be surprised so much shit comes out of your mouth when you have it pressed so firmly to Saint_Proverbius' anus.

 

[Saint_Proverbius]

Hoho - another little gem. DLLs are executable, you tit. If you knew anything about software, for instance understanding the word "program", you would understand this.

No, they're not. You can't run one on it's own. It has to be called by an executable. That'd be like saying C library files(*.LIB) are executables because they contain the source functions for the C language. They're compiled in to machine code as well, but they're not going to do anything until the linker slams all that lovely machine code segments in to an executable.

Not that your comment about scripts (which are also programs) is correct anyway, but DLLs are compiled to native code.

HTML is code as well, but it wouldn't do anything without a browser, which is an executable, to parse it for you. The same thing with batch files. They require that Windows/DOS fire up a batch file parser for them to work, because they're nothing more than a text file.

It's kind of like saying that because you have written a grocery list, you automatically have those groceries. The reality of the situation is that you have a list of instructions that tell you what to do at the store. You have to physically parse that list in order to achieve successful grocery getting. The list by itself won't feed you, but it gives you or someone else the instructions on what you need to feed you in the desired manner.

Even a rudimentary look at the Quake modding world is enough to expose this for the nonsense it is. The quake architecture consists of an executable and a gameplay dll. The exe supports - amongst other things - multiplayer mode. The gameplay dll is required if you want to make a mod that modifies certain (client side) things. Check Code3Arena if you don't understand it.

No, the reason you have to point Quake to the mod directory is because that's where the assets are, the maps, skins, etc. That way, when you fire up Quake 3, it has those cool mod proved skins for the interface. However, this certainly isn't a requirement for playing the mod, since connecting via the console will still work.

Pay particular attention to point 3, on that page, which includes this interesting little fact:

If it's a "server side only mod" then all you need to do is connect to the server (you don't need to download anything). Bang, you're playing! Most mods however require a client download... you'll need to download some stuff and extract it to your quake3\mod_name directory.

These are because of maps and skins, doofus. You need those to play a mod, you know.

You have limited knowledge, I actually co-authored a Quake 2 mod. Who has more knowledge on the subject?

That means...the client is a dumb client UNTIL it's made NOT dumb. But who in their right mind would do that in a multiplayer game anymore? You know, Prov pointed out that Soldier of Fortune did that (which caused all kinds of cheating problems), but you were likely too too busy putting a spin on your earlier bullshit to notice that. Therefore, you CAN delete the gameplay dll in q3 and it will still operate as a dumb client.

Actually, not true at all. It's always dumb. In Quake 3, you'll notice that when a single player session starts, one of the first things it pops up on the console is, "Starting Server". That's because a single player session is where it not only loads a client session, but also a server session on your machine at localhost. That's how the architecture of the Quake engine is. The client side is always dumb.

The only way to make the client "NOT DUMB" is to modify the architecture of the Quake engine itself, and that requires the source code to the engine. Soldier of Fortune has a client and a server side gameplay DLL, but that's only because Raven has the complete source code to Quake 2. They modified the engine itself to allow that. You can't make a mod for Quake 2 or Quake 3 with a client side DLL because the architecture of the engine itself doesn't allow two instances of the server, and the server is what wants the DLL.

 

[Rosh]

:ROFL: So many words, yet so little said ...

An executable, flunkyboy, can be executed. Get it? No bullshit interpretations are required. Data cannot be executed.

A DLL cannot be executed. That's because it is DATA. A DATA addition to refer to other resources, used by a real executable. Where it has it's "interperetations" is through the "interface" that you mentioned below, which provide it with an entry point.

A DLL does not have an entry-point to run, and therefore it cannot (at least by anyone with good knowledge of programming) be called an executable, since it can't really execute by itself in an OS environment.

It's interface is its entry point, dumbass. Stop looking on your Start menu for it and go learn a little bit about real development.

By your "logic", a swf file is an executable, since it has both data and instructions. It's entry point would be the browser plugin, or the Flash editing/viewing program. However, it's not an executable in itself by any stretch of the imagination.

A DLL on it's own, is NOT an executable. It can't run on it's own because it has no entry point. It is a reference.

That is why considering a DLL to be an executable is both flawed and a deprecated meaning, save for some development where they piss all over standards (which might explain why most of their stuff runs like shit), Microsoft.

That means...the client is a dumb client UNTIL it's made NOT dumb

:ROFL:

Just so you know, Prov explained a little about how the Quake game works, which I was hoping I'd get you to hang yourself with. That you made it so simple was a boon in itself.

You might want to take a look before you completely make yourself look like an idiot (too late), and I'm afraid this will get more of your bullshit shoveled around in reply with your usual brand of clueless pontification.

The point where modifications are needed on the client-side are additions, mostly on the graphics side, but not complete clients on their own.

I only have to make modifications on the client-side if I want to include something that's not there already? Nice reasoning.

Learn to read, dumbshit.

You know, I don't suppose I should be surprised so much shit comes out of your mouth when you have it pressed so firmly to Saint_Proverbius' anus.

Now it is obvious you're trolling. In case you didn't get it earlier, we are separate people. However, you might like to note that like with Vikjunk and others, you've amassed quite a number that don't like your games. Sure, the "toady" bit might be amusing to toss around to make it look like you're picked on by a gang, but I think you've amassed the gang by yourself.

 

[Sol Invictus]

And now, to further rebuke Fatman, I present as follows:

Your tutorial defeats your own point because the tutorial you gave us reference to basically goes to say that the game uses a dumb client unless there's other more client-side features involved, like a scoring system or a built in interface/menu, like Loki's CTF for Q2.

In that game, you didn't need the dll to play the game online, but you needed it for those features.

However, the server code made a note to check your directory to see if it had that .dll, so you could use the features.

The reason the server didn't handle all of the features by itself is because the voting system had a graphical interface, sounds, and other stuff which was too much of a bandwidth hog for the server to handle.

Most mods in Quake 2 however, were purely server-based, like LaserMine CTF, which had specially coded 'laser trip' grenades and a voting system as well.. on the server, and you didn't have to download anything at all.

Update: I meant to say that the stuff appearing on your screen was client based, handled by the DLL because the dumb client didn't contain that in Half Life. New games like RTCW, Q3 and UT2003 all handle the voting process and HUD and stuff on the server and not on the client, at all. Hell, even Quake and Quake 2 did that, though Quake used scripts as opposed to DLL.

in some games, the client might not have had the ability to display certain types of graphics on screen, until a patch or something came out to offer DLL support for the client to do that. Still a dumb client, nonetheless, because all the DLL did was interpret the data and nothing more. You can't make changes to the DLL to implement features unsupported by the server. Basically, you can't 'reverse engineer' the server from a client connection.

Cheating ruined Half Life.

 

[Saint_Proverbius]

By your "logic", a swf file is an executable, since it has both data and instructions. It's entry point would be the browser plugin, or the Flash editing/viewing program. However, it's not an executable in itself by any stretch of the imagination.

A DLL on it's own, is NOT an executable. It can't run on it's own because it has no entry point. It is a reference.

That is why considering a DLL to be an executable is both flawed and a deprecated meaning, save for some development where they piss all over standards (which might explain why most of their stuff runs like shit), Microsoft.

Hell, by his "logic", a Quake(all versions) *.BSP file is an executable because it contains instructions for the client as to where vertices are, it contains compiled light data which is what qrad does, and programmed entities that tell the client how/when/why doors work, and so on.

One of the biggest features of Team Fortress for Quake was that it expanded the entity functions of brushes in such a manner that they were more easily programmed to facilitate the ability of TF maps to determine the game type, objectives, and so on. How you programmed these entities, such as a flag, determined the rules of CTF for that map.

You could literally code doors to open when a player touches the flag, or crosses in to an area, and so on.