Subject: [Nel] RE: Nel miscellanea

From: "Nel List" <[email-masked]>
Date: Thu, 3 Jan 2002 08:53:53 -0800

> I noticed that 3_light.bat contained a very similar command as well.  This
> doesn't help me very much working on a Windows machine and not
> having a bash

You might want to get Cygwin and install it. It runs fine on
Win98 and Win2k, and comes with bash and all the usual shell tools.

Another goodie to get for your Windows box is perl (typically, from
the ActivePerl distribution).

> >because this isn't a perfect world, what keeps a user from just
> recompiling
> >the code with for instance wireframing enabled to give himself an unfair
> >advantage over the other users. This is a real possibility with GPL. My

If the data goes over the wire to the user's machine, it is visible
to an enterprising user (witness ShowEQ). Re-compiling the client
doesn't change this in any real way (as long as all decisions are
made on the server).

> We have unified the export / bulid process for all NeL 3d media.

What I've found lacking the most when looking through the NeL sources
is simply documentation on how to build and use it; especially under
Windows. There's all kinds of miscellaneous DSW files scattered over
the source tree, and nowhere does it say which ones should be built,
in what order, or what the other requisite tools/libraries needed are.

> Yes, the scripts was missing ! Sorry for this. It should be ok now.

Does this mean you don't have an automated daily build? Having a
machine that checks out a clean source into an empty directory, and
turns the crank to build the real product, is a must-have for any
engineering organization. You may find that if your build is too
complicated to get that going, effort you put into fixing that may
improve the issue above, too.

---

From: "Zane" <[email-masked]>
Date: Thu, 3 Jan 2002 09:09:24 -0800

----- Original Message -----
From: "Nel List" <[email-masked]>
Sent: Thursday, January 03, 2002 8:53 AM

> improve the issue above, too.

Yes, that's what it means.  In the past I was updating and recompiling NeL
daily but about 50% of the time it wouldn't compile due to errors checked
into CVS.  Cross-file errors I can understand in a large project with
multiple developers.  Typos or ommisions that cause the code to be
incompilable I can't, it's a major annoyance.

Anyway, I'm lucky to get the code at all. :)

-E.J. Wilburn

---

From: "Cyril 'Hulud' Corvazier" <[email-masked]>
Date: Thu, 3 Jan 2002 19:04:36 +0100

Hi,

> in what order, or what the other requisite tools/libraries needed are.

Yes, you're right. We know that the lack of documentation is a problem.
Be sure that it will be solved in a near future when we will stabilise a 
NeL version. For the moment, we are taken by internal deadline.

> improve the issue above, too.

Please, note that those sources was deprecated. It means, we don't use it anymore.

Can you please put your name in your messages ? It is a must-have for any user of this list.

Cyril Corvazier
---
Lead 3d programmer
Nevrax France

---

From: "Cyril 'Hulud' Corvazier" <[email-masked]>
Date: Thu, 3 Jan 2002 19:06:32 +0100

Hi,

> incompilable I can't, it's a major annoyance.

Yes, sometimes sources on the CVS doesn't compile under linux. It comes
from 2 main reasons:

1) Most of NeL developpement is done under Windows and rarely under linux. 
(Some network guys do it..). Sometimes, you're right, sources checked into
the CVS doesn't compile under linux, but very rarley under windows.
We have automatic rebuild systems at Nevrax, but sometimes errors pass thru.

2) The CVS is updated with a daily snapshot and not a stabilized / tested / 
compiled version.

But be sure that for our internal developement, the CVS is always consisting.

Cyril Corvazier

---

From: Tony Hoyt <[email-masked]>
Date: Thu, 3 Jan 2002 14:09:32 -0500

"Nel List" <[email-masked]> wrote:
> > >the code with for instance wireframing enabled to give himself an
> > >unfair advantage over the other users. This is a real possibility
> > >with GPL. My
> 

  Some possable results of allowing the client to be released to the
general public have been disccused before.  I believe someone here
published a link to a website discussing this very issue, focusing on
two key problems with open source clients.  And this is no matter what
format you end up following, includeing the complete "Only send client
location of things local to the player, and only the bare bones data as
well (Location, moveing, apperence, and health in % for the case of a
RPG style online game)

  1) Radars: These are specialy dangerous for Player vs Player combat.
since it can allow someone to know instantly 1) Who are your enemies
around you, 2) How much health they have, and depending on how clever
the hacker is 3) how strong the player is vs you.  The last bit of data
comes from the fact that some online games offer you some clue as the
level of the people around you, as well as monsters for your
information.  This kind of information can lead to unfair advantages. 
In Dark Age of Camelot, which is said to have taken the minimalist
apporach to sending data to players, even they have recently had
concernes about such "radar" 3rd party applications.   ShowEQ is all
about this, and exploits the fact that the game sends all monsters spawn
information to the client constantly.  Although not Player spawn
information unless local to the player.

 2) Auto-aimers: This doesn't sound like it could be a problem on say
MMORPG's but it can be if it means players can auto-target the weakest
player in a Player vs Player conflict and constantly attack them.
Auto-targeting is still a problem here, no matter where it came from.

   2a) Derived from this we get, Auto-Clickers or in other words,
applications that automaticly perform repedative actions or  a macro of
complex actins.  Perhaps, again in a RPG setting,  a healer could then
put all his healing action onto a long string of intelligent macros that
will watch some players health levels, and then auto-send a heal command
at say 40% loss.  That's a combination of auto-targeting and
auto-commands.  Reverse this for Combat mages,  Auto-targeting for spell
attacks.. You get the idea.

  2b) The final and worse form of this, Bots.  Auto-hunters that can run
around, and hunt for players hour after hour without the player actually
being there or only occasionaly monitoring.  Quite unfair from my stand
point.

  Now that's enough examples at the moment.  As you can say, and as the
article said before (I wish I had the link) This problem is quite
serious even if the source is not released.  Packet sniffing and reverse
engineering will always result in the hackers discovering everything
they need to know to make there tools work.

  Possable solutions. These just came to me.  These will only work in a
closed source solution.

  1) Re-arrange the order of data in the packets every build or whenever
you can.  This forces the hackers to re-sniff and learn all your packets
again each time you come out with a new version of the client.

  2) Update/change your encription: Again, they will discover what you
are using, and just changeing one of the keys won't be enough.  I don't
know a whole lot about encription but hopefully there's something that
can be done to perlong the chance that the hackers will be successfull. 
Please note that even this method is not invulnerable to de-compileing
the application.

  3) Change the ports you use for communication: Again a delaying tactic
at best.  It's not a great solution but, it's better then nothing.   You
can get really fancy with this, and make the port the client connects to
the server for game data the result of a function based off of data sent
from the 'connection' port and user data.  That idea may only work with
tcp/ip though.

  There are a thousand tactics you can use.  But all of them are simply
slowing measure to prevent hacking.  Hackers are only successful nine
times out of ten because the client never changes for long periods of
time, and when it does change, changes only very minorly so.  This
makeing it easy for a  hacker with enough time on his hands, (Or on the
hands of a small team of them) to decode the packets, and then engineer
a soultion to decode the packets for there own use.  ShowEQ is the best
result of such a product (http://www.sourceforge.com/projects/seq)  The
most trouble they ever have, is when the packets change size slightly,
or the encription changes.   Other then that, it knows everything about
anything that goes on.

  Tony

> _______________________________________________
> Nel mailing list
> [email-masked]
> /mailman/listinfo.cgi/nel

---

From: Dim Segebart <[email-masked]>
Date: Thu, 3 Jan 2002 21:40:31 +0100

IMHO,  cheating  is bad only then ones try to increase his stat's points: Health,
Power, Mana, etc. But this kind of cheating prevents by server-side decision making (I
hope)
Other  kind  of  tools like radars, wire framing, auto targeting, etc., etc. are
not  cheats  but features ;) Just provide enough of such tools as default set to the end user
and    he   will   be   happy   to  use  it, moreover telling the user which
helper   means  are  activated  by  his opponent will help him to adjust
his  behavior according to the current situation. The main point is - if two
opponents  has wire framing, auto targeting and healing switched on it's no more
cheating, but additional weapon which everyone can use without additional cost.
If you will provide API for creating bots, what will be the reason to create hunting
bot if your opponent will launch hunting-bots bot or just defence bot?
So,  prevent your game from Games Stat cheating, open it for hacking and extending and
game   balance   will  be  achieved by users themselves. It's just like  USA vs
Soviets  -  you  and  your  counterpart has enough of atom bombs to destroy each
other  but you are in the state of balance so you play everyday Game according to the
"normal" rules.

Thursday, January 03, 2002, 8:09:32 PM, you wrote:

>> doesn't change this in any real way (as long as all decisions are

TH>   Some possable results of allowing the client to be released to the
TH> general public have been disccused before.  I believe someone here
TH> published a link to a website discussing this very issue, focusing on
TH> two key problems with open source clients.  And this is no matter what
TH> format you end up following, includeing the complete "Only send client
TH> location of things local to the player, and only the bare bones data as
TH> well (Location, moveing, apperence, and health in % for the case of a
TH> RPG style online game)

TH>   1) Radars: These are specialy dangerous for Player vs Player combat.
TH> since it can allow someone to know instantly 1) Who are your enemies
TH> around you, 2) How much health they have, and depending on how clever
TH> the hacker is 3) how strong the player is vs you.  The last bit of data
TH> comes from the fact that some online games offer you some clue as the
TH> level of the people around you, as well as monsters for your
TH> information.  This kind of information can lead to unfair advantages. 
TH> In Dark Age of Camelot, which is said to have taken the minimalist
TH> apporach to sending data to players, even they have recently had
TH> concernes about such "radar" 3rd party applications.   ShowEQ is all
TH> about this, and exploits the fact that the game sends all monsters spawn
TH> information to the client constantly.  Although not Player spawn
TH> information unless local to the player.

TH>  2) Auto-aimers: This doesn't sound like it could be a problem on say
TH> MMORPG's but it can be if it means players can auto-target the weakest
TH> player in a Player vs Player conflict and constantly attack them.
TH> Auto-targeting is still a problem here, no matter where it came from.

TH>    2a) Derived from this we get, Auto-Clickers or in other words,
TH> applications that automaticly perform repedative actions or  a macro of
TH> complex actins.  Perhaps, again in a RPG setting,  a healer could then
TH> put all his healing action onto a long string of intelligent macros that
TH> will watch some players health levels, and then auto-send a heal command
TH> at say 40% loss.  That's a combination of auto-targeting and
TH> auto-commands.  Reverse this for Combat mages,  Auto-targeting for spell
TH> attacks.. You get the idea.

TH>   2b) The final and worse form of this, Bots.  Auto-hunters that can run
TH> around, and hunt for players hour after hour without the player actually
TH> being there or only occasionaly monitoring.  Quite unfair from my stand
TH> point.

TH>   Now that's enough examples at the moment.  As you can say, and as the
TH> article said before (I wish I had the link) This problem is quite
TH> serious even if the source is not released.  Packet sniffing and reverse
TH> engineering will always result in the hackers discovering everything
TH> they need to know to make there tools work.

TH>   Possable solutions. These just came to me.  These will only work in a
TH> closed source solution.

TH>   1) Re-arrange the order of data in the packets every build or whenever
TH> you can.  This forces the hackers to re-sniff and learn all your packets
TH> again each time you come out with a new version of the client.

TH>   2) Update/change your encription: Again, they will discover what you
TH> are using, and just changeing one of the keys won't be enough.  I don't
TH> know a whole lot about encription but hopefully there's something that
TH> can be done to perlong the chance that the hackers will be successfull. 
TH> Please note that even this method is not invulnerable to de-compileing
TH> the application.

TH>   3) Change the ports you use for communication: Again a delaying tactic
TH> at best.  It's not a great solution but, it's better then nothing.   You
TH> can get really fancy with this, and make the port the client connects to
TH> the server for game data the result of a function based off of data sent
TH> from the 'connection' port and user data.  That idea may only work with
TH> tcp/ip though.

TH>   There are a thousand tactics you can use.  But all of them are simply
TH> slowing measure to prevent hacking.  Hackers are only successful nine
TH> times out of ten because the client never changes for long periods of
TH> time, and when it does change, changes only very minorly so.  This
TH> makeing it easy for a  hacker with enough time on his hands, (Or on the
TH> hands of a small team of them) to decode the packets, and then engineer
TH> a soultion to decode the packets for there own use.  ShowEQ is the best
TH> result of such a product (http://www.sourceforge.com/projects/seq)  The
TH> most trouble they ever have, is when the packets change size slightly,
TH> or the encription changes.   Other then that, it knows everything about
TH> anything that goes on.

TH>   Tony

>> improve the issue above, too.
TH> _______________________________________________
TH> Nel mailing list
TH> [email-masked]
TH> /mailman/listinfo.cgi/nel

-- 
Dim Segebart                         mailto:[email-masked]

---

From: Lars Weber <[email-masked]>
Date: 04 Jan 2002 11:42:57 +0100

Dim Segebart <[email-masked]> wrote:

> IMHO, cheating is bad only then ones try to increase his stat's points:
> Health, Power, Mana, etc. But this kind of cheating prevents by
> server-side decision making (I hope) Other kind of tools like radars,
> wire framing, auto targeting, etc., etc. are not cheats but features ;)
[...]

Problem is: there are quite a few people (including me) that would rather
like to see nice landscapes instead of boring wireframe graphics[0] :-)

(And I wouldn't want to use things like auto-aim/unlimited health/what-
have-you, either -- there actually exist people that cannot understand
that... to me it's completely the other way around!)

Regards,
Lars

[0] Not to say anything bad about games using wireframe graphics!  But
when there are actually nice landscapes available... the one screenshot
I've seen of Ryzom(sp?) really looked awesome!

-- 
[ Lars Weber ]-------< [email-masked] >-----[ GPG-ID: 1383B42E ]
+++ fingerprint: 44B1 1D23 DD53 E6B2 4AAB 4C36 0323 9141 1383 B42E +++
[ Using GNU ]----< www.gnu.org | www.debian.org >---[ Running Debian ]