I am saddened by peoples stupidity

[OoFfa]

@ NUTS

Care to expand a little? I've had a look at the link and can't figure out where to glean some useful info from

Thanks

OoFfa

Edit: Have a look at the hops for my connection to Dash, note where I get all my packet loss. How can I fix this?

[NUTS!]

http://opentnl.sourceforge.net/doxytree/ Just start clicking and reading: heres a littl tid bit.

Torque Network Library Architectural Overview
The Torque Network Library is built in layers, each adding more functionality to the layer below it.
The Platform Layer
At the lowest level, TNL provides a platform independent interface to operating system functions. The platform layer includes functions for querying system time, sleeping the current process and displaying alerts. The platform layer includes wrappers for all of the C standard library functions used in the TNL.
The platform layer also contains the Socket and Address classes, which provide a cross-platform, simplified interface to datagram sockets and network addresses.

The NetBase Layer
The NetBase layer is the foundation upon which most of the classes in TNL are based. At the root of the class hierarchy is the Object base class. Every subclass of Object is associated with an instance of NetClassRep through a set of macros, allowing for instances of that class to be constructed by a class name string or by an automatically assigned class id.
This id-based instantiation allows objects subclassed from NetEvent and NetObject to be serialized into data packets, transmitted, constructed on a remote host and deserialized.

Object also has two helper template classes, SafePtr, which provides safe object pointers that become NULL when the referenced object is deleted, and a reference pointer class, RefPtr, that automatically deletes a referenced object when all the references to it are destructed.

The BitStream and PacketStream classes
The BitStream class presents a stream interface on top of a buffer of bytes. BitStream provides standard read and write functions for the various TNL basic data types, including integers, characters and floating point values. BitStream also allows fields to be written as bit-fields of specific size. An integer that is always between 3 and 9 inclusive can be written using only 3 bits using the writeRangedU32 method, for example.
BitStream huffman encodes string data for additional space savings, and provides methods for compressing 3D points and normals, as routines for writing arbitrary buffers of bits.

The PacketStream subclass of BitStream is simply a thin interface that statically allocates space up to the maximum size of a UDP packet. A routine can declare a stack allocated PacketStream instance, write data into it and send it to a remote address with just a few lines of code.

The NetInterface and NetConnection Layer
The NetInterface class wraps a platform Socket instance and manages the set of NetConnection instances that are communicating through that socket. NetInterface is manages the two-phase connection initiation process, dispatch of protocol packets to NetConnection objects, and provides a generic interface for subclasses to define and process their own unconnected datagram packets.
The NetConnection class implements the connected Notify Protocol layered on UDP. NetConnection manages packet send rates, writes and decodes packet headers, and notifies subclasses when previously sent packets are known to be either received or dropped.

NetInterface instances can be set to use a public/private key pair for creating secure connections. In order to prevent attackers from depleting server CPU resources, the NetItnerface issues a cryptographically difficult "client puzzle" to each host attempting to connect to the server. Client puzzles have the property that they can be made arbitrarily difficult for the client to solve, but whose solutions can be checked by the server in a trivial amount of time. This way, when a server is under attack from many connection attempts, it can increase the difficulty of the puzzle it issues to connecting clients.

The Event Layer - EventConnection, NetEvent and Remote Procedure Calls
The EventConnection class subclasses NetConnection to provide several different types of data transmission policies. EventConnection uses the NetEvent class to encapsulate event data to be sent to remote hosts. Subclasses of NetEvent are responsible for serializing and deserializing themselves into BitStreams, as well as processing event data in the proper sequence.
NetEvent subclasses can use one of three data guarantee policies. They can be declared as GuaranteedOrdered, for ordered, reliable message delivery; Guaranteed, for reliable but possibly out of order delivery, or Unguaranteed, for ordered but not guaranteed messaging. The EventConnection class uses the notify protocol to requeue dropped events for retransmission, and orders the invocations of the events' process methods if ordered processing is requested.

Because declaring an individual NetEvent subclass for each type of message and payload to be sent over the network, with its corresponding pack, unpack and process routines, can be somewhat tedious, TNL provides a Remote Procedure Call (RPC) framework. Using some macro magic, argument list parsing and a little assembly language, methods in EventConnection subclasses can be declared as RPC methods. When called from C++, the methods construct an event containing the argument data passed to the function and send it to the remote host. When the event is unpacked and processed, the body of the RPC method implementation is executed.

See Also RPC in the Torque Network Library for a more complete description of RPC in the Torque Network Library.

Ghosting - GhostConnection and NetObject
The GhostConnection class subclasses EventConnection in order to provide the most-recent and partial object state data update policies. Instances of the NetObject class and its subclasses can be replicated over a connection from one host to another. The GhostConnection class manages the relationship between the original object, and its "ghost" on the client side of the connection.
In order to best utilize the available bandwidth, the GhostConnection attempts to determine which objects are "interesting" to each client - and among those objects, which ones are most important. If an object is interesting to a client it is said to be "in scope" - for example, a visible enemy to a player in a first person shooter would be in scope.

Each GhostConnection object maintains a NetObject instance called the scope object - responsible for determining which objects are in scope for that client. Before the GhostConnection writes ghost update information into each packet, it calls the scope object's performScopeQuery method which must determine which objects are "in scope" for that client.

Each scoped object that needs to be updated is then prioritized based on the return value from the NetObject::getUpdatePriority() function, which by default returns a constant value. This function can be overridden by NetObject subclasses to take into account such factors as the object's distance from the camera, its velocity perpendicular to the view vector, its orientation relative to the view direction and more.

Rather than always sending the full state of the object each time it is updated across the network, the TNL supports only sending portions of the object's state that have changed. To facilitate this, each NetObject can specify up to 32 independent states that can be modified individually. For example, a player object might have a movement state, detailing its position and velocity, a damage state, detailing its damage level and hit locations, and an animation state, signifying what animation, if any, the player is performing.

A NetObject can notify the network system when one of its states has changed, allowing the GhostConnections that are ghosting that object to replicate the changed state to the clients for which that object is in scope.

Encryption and TNL
The TNL has hooks in various places to use encryption when requested. To enable encrypted connections, the NetInterface must be assigned an instance of AsymmetricKey as a public/private key pair using NetInterface::setPrivateKey. The NetInterface::setRequiresKeyExchange method may then be called to instruct the NetInterface that all incoming connection requests must include a key exchange.
Asymmetric keys can be constructed with varying levels of security. The TNL uses Elliptic Curve public key crytpography, with key sizes ranging from 20 to 32 bytes. AsymmetricKey instances can be constructed either with a new, random key of a specified size, or can be created from an existing ByteBuffer.

Once a secure connection handshake is completed, TNL uses the AES symmetric cipher to encode connected packets. The BitStream::hashAndEncrypt and BitStream::decryptAndCheckHash methods use an instance of SymmetricCipher to encrypt and decrypt packets using a shared session key.

In order to have properly secure communications, the cryptographically strong pseudo-random number generator (PRNG) in TNL must be initialized with good (high entropy) random data.

Useful Classes
TNL uses a number of utility classes throughout. Some of these include:
Vector - The Vector template class is a lightweight version of the STL Vector container.

DataChunker - The DataChunker class performs small, very low overhead memory allocation out of a pool. Individual allocations cannot be freed, however the entire pool can be freed at once.

ClassChunker - The ClassChunker template class uses the DataChunker to manage allocation and deallocation of instances of the specific class. ClassChunker maintains a free list for quick allocation and deallocation.

StringTableEntry - StringTableEntry wraps a ref-counted element in the StringTable, with simple conversion operations to C strings. StringTableEntry instances can be sent in the parameter lists of RPC methods or using the EventConnection::packStringTableEntry method.

ByteBuffer - The ByteBuffer class wraps a buffer of arbitray binary data. ByteBuffer serves as a base class for BitStream, as well as the cryptographic primitives.

Debugging and Error Handling
Correcting bugs in a networked simulation can sometimes be an incredibly difficult task. TNL provides some handy features to make debugging somewhat less challenging:
Asserts - The TNLAssert and TNLAssertV macros specify a condition that, if false, will cause the application to display an error dialog and halt in the debugger where the assert was hit. Asserts are very useful for sanity-checking arguments to functions, and making sure network data is being properly read from and written to packets.

Logging - TNL has a set of simple but effective facilities for logging status information. The TNLLogMessage and TNLLogMessageV macros allow the user to specify logging tokens with particular log messages. Logging of messages associated with a given token can be enabled or disabled using the TNLLogEnable macro. Also, the TNLLogBlock macro can be used to log multiple logprintf statements in a single test. Rather than log to a file or other destination, TNL applications must declare at least one instance of a sublclass of TNLLogConsumer. Every TNLLogConsumer instance receives all the logging messages that are currently enabled.

Debugging object writes into packets - One of the most common errors programmers experience when using TNL is failing to properly match the NetEvent::pack and NetEvent::unpack or NetObject::packUpdate and NetObject::unpackUpdate routines. By default, if TNL_DEBUG is defined, the EventConnection and GhostConnection classes will write extra size information into the packet before each object's data are written. The ConnectionParameters::mDebugObjectSizes flag can be modified directly to further control this behavior.

This is fasinating as well:http://www.garagegames.com/docs/tge/general/ch06s11.php

[vashstampede]

i am with nuts on this one.

there are tweaks ppls are using
to gain advantage.

it happens to me all the time, and
it usually the same person/s, it didnt
matter if my ping was low or high,
it didnt matter if there was one player
or ten, when this person/s would show
up in the server, the same lag would
appear, and when the person/s left
the same distinct lag would disappear.

on top of that the lag was variable to
the degree of how i was playing.

it mainley effects shooting and personal
tank physics.

shooting this person is exactly how nuts
describs it, dead aim but nothing is happening
to the other tank and no arouds are firing
and it appears the other tank is slightly blinking
but it does not effect thier tank.

in poor condition i know how my tank should
react, but when this person/s enters my tank
physics are all outa wack, hum bot seems to
keep up with me, dont get the usual height
on the jump pads, and dont go the usual distance
on the arrow key, and my magnet does not
pick up the ball.

and on top of all that i have a 1.5-2 sec delay
on all functions of the game.

also the count down clock ends when there is
still about 4-3sec left.

but when this person/s are not in the game all is
fine.

these ppl who are using the tweaks to show to others
they have skill is laughable.

[Blind Cide]

Cadc has a short memory. He was outed shortly before the demise of PTT1 as a proxy server user. He sheepishly excused that fact by explaining that his father won't let him on the internet without it.

Proxy servers restrict incoming packets to his computer but let his outgoing bullets go unhindered. I think of Cadc's situation as textbook "induced lag". Really I could care less why he has it, and I certainly can't do anything about it. But you can be sure that my immediate departure from servers that he joins is intentional.

I have to laugh at attempts to defend Cadc's skill. My mind is full of flashbacks of Cadc headed in an impossible straight line to the goal while bombarded by a server full of opponents and the resulting centerprint "Cadc scored a goal!". When you spend time in a server with that happening for more than half the goals its clearly a rediculous waste of time.

Just to be fair here, Cadc isn't the only player that can suck the fun out of a game. I'm not complaining, I'm just clarifying some not-so-positive aspects of TT. It doesn't surprise me that Cadc seems to be oblivious to his situation, he can't see it on his screen.

[gray]

Ya, the lag was our 4th player that first game. I think it comes round for all of us once in a while, more so if your not in a hotspot. I'm looking at a nice suburb close to Chicago, I'll have to test the connections before I decide.

[fishtank]

I really have no idea. The game seems to run smooth on my end, I'd hate to be one of those people blissfully running around ruining other's fun. I've taken measures to try and reduce my lag, as I really enjoy playing this game and want to optimize my experience. I've upgraded my video card, among other things. I know my comp is outdated, but it should be good enough to play TT. Unfortunatley, the new comp I was hoping to get is sitting nearby in the form of a new Dyson vacuum cleaner.

[Cadc]

He sheepishly excused that fact by explaining that his father won't let him on the internet without it.

Excuse?

I may be oblivious to what goes on in everyone else's screen, but you are completely oblivious of what goes on in my life, so I'd consider getting your facts streight if you are going to make a bold statement like that my dear friend

My mind is full of flashbacks of Cadc headed in an impossible straight line to the goal while bombarded by a server full of opponents and the resulting centerprint "Cadc scored a goal!

So, you think I'm the only one who can? try spending some time arround Tally Ho, and Jangles

[NUTS!]

Wow people really do not read. The point is that somewhere between the server or in there personal set up there is most likely a problem. If you read the stuff about TNL is was made/optimized to run on 56.6 modems. Irregardless of were one lives or there ping the game/server should adjust to it. The vast majority of the information for the game actually resides on your own computer. Which is why I have "whined" so much about poeple shutting off everything, except TT of course. I remember when Rx used to have his server up and there was a bad router for awhile between he and I. I loved it, I could live forever. Plus I could/can get the same effect if I run other applications, like voice, music, etc in the background. I know I may sound like a snob but like everyone else I paid my $20 and have invested a lot into the game. I do not complain about the lag to have people stop playing but to see if some how some way they can fix it. Whether its running a traceroute, opening up there ports, turning down there settings (maybe its dragging there own computer). My ultimate goal is to have people have a great expierence, play more often and get more people to play. Instead of what we are seeing now, people leaving because of the lag. THere could ultimately be many factors that contribute to it. I know in the past GG/Bravetree stated that it may be the all the new packs and stuff that we have incorperated into TT may be a fact. Who knows maybe since constuctor is now free I can take some polycounts down on some of the stuff and see if that helps.

I know this thread was started with bad intentions hopefully we can turn around for something usefull.

[Cadc]

I know in the past GG/Bravetree stated that it may be the all the new packs and stuff that we have incorperated into TT may be a fact. Who knows maybe since constuctor is now free I can take some polycounts down on some of the stuff and see if that helps.

For once, I think you've made a very valid point Nuts, my entire TT directory is now 9 Megs, That's quite a bit of info to manage while playing. I don't think TT has any cache support, so the game info's gotta be reloaded every time it's opened.

[Three]

My skills at this game fall in line with a very, very mediocre demo, yet I have played while yakkin' on skype a few times, and the lag is quite noticeable. During one of Dazzle's glorious drunk skype serenades, I was the man in a room full of vets at roos. Those of you that have played even in an adjacent server to me know that this is not the norm, and could've only happened through lag. Truth be told, Threeroy was Mr. Threeroy that night. And fish, no worries, you're silky smooth yo.