Thank you Stormbinder!

[Gandalf Parker]

Boy, Arryn, you really know how to push my buttons How do you do that? Certainly, no apology necessary. I'm sorry if I've spoken out of context. Back to my cell before anyone notices I've escaped! (See why they don't let me post much??)

Jumping in when someone mentions Shrapnel comparatively, or one of your developers? Heck I thought that WAS in your job description.
You mean we cant threaten people with "shhhhh before Annette hears you"?
(hopefully everyone knows Im just giving my boss a hard time. Ive never heard anything but nice about the way you handle customer requests)

[Esben Mose Hansen]

That would be very possible. The give/take would be the processing requirements being higher at the host end but for a pbem game that isnt supposed to matter. The solo players might hate it but they are low on the considerations anyway. Might even possible to have a level of checking avialable so that solo or hot-seat players dont have to wait for it.

Thank you! I'm sorry for being so persistent, but being a mathematician AND a software engineer, the *can't be done" Messages annoyed me too much to ignore. There are many unsolvable problems, but this isn't one of them.

Another nice advantage is that if everything is stored by commands instead of interface/results, it might open the door for scripting which would open the door for programmed bots which would open the door for player-programmed AIs. But lets not go there today.

I almost wrote something to that effect, but tried for a simple, clear message instead. Yes, the interface to libdom2 could be published, and players could come up with all sorts of stuff

I definately see the "web based game server" thinking showing there. In many ways that duplicates requests Ive made. Seperating host from client, and especially the IPserver, would go far toward good management for hosts.

I did understand the response I got about them not wanting to update multiple programs. Just the game and demo have floated quite a ways apart from each other.

Yes, duplicate code is evil, as the demo demonstrates. And redoing dom2 in the mold I've sketched above now would be a major undertaking. I was just a) trying to illustrate my point and b) secretly hoping IW reads this and gets that detail right for dom3

And in reply to Arryn,. and as I have written (but not in this thread, alas), IW has done an amazing job. I'm very impressed, and doubly thankful for them providing a linux Version, without which I would have missed this game entirely. Expensive as the game was, it is definitely well worth it. I hope IW does make a bit of a profit of it...

[Arryn]

Boy, Arryn, you really know how to push my buttons How do you do that?

I've been known to have that effect on people, at times.

I'm sure the boys at IW would concur with you re: my dubious 'talent' for such things.

OTOH, it's so much easier to misconstrue something written on the 'Net than when the exact same words are spoken in person. Nature of the medium and lack of visual/audio cues (body language, tone, etc.).

What this small event shows is just how responsive you folks at Shrapnel are. That's a good thing. (Consider that a compliment, in case I'm not being obvious enough.)

[Annette]

It's been a tough week...how 'bout a group hug?

BTW...I know I should be using quotes but am the absolute Last to figure out these new forums!

[Arryn]

It's been a tough week...how 'bout a group hug?

{hug}

BTW...I know I should be using quotes but am the absolute Last to figure out these new forums!

The new quote system isn't as friendly as the old one. I especially dislike having to manually insert BOLD tags for the quoted text. Sigh.

[Stormbinder]

That would be very possible. The give/take would be the processing requirements being higher at the host end but for a pbem game that isnt supposed to matter. The solo players might hate it but they are low on the considerations anyway. Might even possible to have a level of checking avialable so that solo or hot-seat players dont have to wait for it.

Actually I think all security checks, especially time-intesive ones, should only be applied to MP games, that's the whole point of them. If player wants to "cheat" in SP game, by giving himslef some advantage, it's his own business. After all the AI is unlikely to complain about it on the board....

I definately see the "web based game server" thinking showing there. In many ways that duplicates requests Ive made. Seperating host from client, and especially the IPserver, would go far toward good management for hosts.

I did understand the response I got about them not wanting to update multiple programs. Just the game and demo have floated quite a ways apart from each other.

IMHO security concerns should not be a problem with demo since nobody play it in MP mode anyway, at least seriosly. Personally I don't see and real need to update demo with improved security, if it would take some serious additional efforts, since it is not an issue there.

[alexti]

Dom 2 has been created in the "spare" time of a few folks whose day jobs are something other than being programmers, game architects, graphics designers, network engineers, et cetera. It's actually remarkable that they've been able to do as well as they have given their relative lack of in-depth knowledge of professional computer game design (as compared to almost all other game dev shops) or even the inner workings of the coding tools they're using.

Very well said. I would also add that even though Dom2 stands out due to its gameplay and the "historical/fantasy perspective", the programming job is quite amazing, especially when you consider that it was done by one part-time guy. Just look at it, he had to take care of data processing, GUI, 2D and 3D rendering, networking, encryption, cross-platform code etc. You will not often find programmers with all these skills in the industry. And with all of it, Dom2 is a very stable program, by industry standards.

Concerning making the program resistant to hex-editing of the turn file. Making the server execute all the commands provided by the client and performing all validations on the server is certainly an excellent plan, but when looking into it closer, it involves more work than it appears.

Just a couple of examples:
- We are reading turn file from the clien, the command instructs to rename commander "Kora" to "Sjhslsdsfewoias...hskdf" (... stands for 9000 of various characters). Ok, no problem for the server, one can not cheat by renaming commanders. Oops, extra 8000 bytes in the name has overwritten the players resources structures setting the gem counts to 2000 each...

- The client instructs to casts Well of Misery with 2147483647 extra gems, let's check if he has enough gems:
Code:

---

int remainingGems = currentGems - baseSpellCost - extraGems;

if (remainingGems < 0)

  cheatReport();

else

  currentGems = remainingGems;

---

Code:

---

remainingGems = 0 - 80 - 2147483647 = 2147483569 (!)

---

Ok, how many tartarians can we summon for that?

So while it is possible to make the server fail-proof against this kind of cheats, it will take quite a lot of effort and careful programming.