Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - QwazyWabbit

Pages: 1 ... 71 72 73 74 75 76 77 78 79 80 [81] 82
Quake / Re: Possible for simultaneous Dual Rail Kills?
« on: April 08, 2008, 08:52:19 PM »
My head hurts. I don't know which thread is better to post in. A couple of thoughts occur to me.

1. Q2 doesn't need microsecond accuracy for the timing to be deterministic, it only deals with one thread examining the state of each game entity once each server frame. A server frame is 1/10 second, by definition.
2. It doesn't matter how many client frames from each client the server receives in each second, it accumulates the state changes for each client and processes only one state per entity per server frame.
3. Since each frame begins with client index 0 it will naturally have a bias (IMO) to see kills by that client before all others regardless of when the shot was fired and the client message received by the server. (As long as the client messages were both received before the server frame was processed.)
4. Q2 tracks the time of arrival of each client frame only so far as to determine which client frame is the newest when using the client information for entity state and prediction. Once the entity state is set for that frame, the server frame doesn't care.

I would expect the following:
If two client frames both arrived "at the same time" well in advance of a server frame event and they were both shots and both on target, the server would pick up and process both frames, modify states, then process the shots, then client 0 will get credit for the kill more often than client 1, all else being equal.

This assumes a rail particle is instantaneous in a Q2 frame, if it takes more than 1 frame for a rail shot to be processed then it is possible for both particles to be "in flight" at the same time and for each player to take the hit.
(I admit I am hedging here.)

What's really happening in HPW vs. LPB rail games is who is getting the accurate shot off prior to the server tick so the client state is in the server que sooner. The LPB wins more often because his state is there sooner. What's happening is tick, shoot, tick, kill, tick, shoot, tick, aw nutz. If it were tick, shoot, shoot, tick, then client 0 wins.

I have encountered the dead shot phenomenon in LOX code too. Both players shoot and both see their shots but one is effective and the other is not. This appears to be the client index preference at work. You would have to log the entity state details each server frame to see it in a debugger, I don't think I would want to try to set that kind of breakpoint. It would only make my head hurt worse.

It would be interesting to create two clients coupled to the same fire button and aimed at each other and let them shoot monte-carlo style and see who wins.

Tech Junkie Lounge / Re: Open Source Licenses
« on: March 10, 2008, 06:28:50 AM »
Which means that no program written on Linux or GNU or any one of myriad derivatives of Linux can be closed source. No perl programs, no Ruby programs, nothing based on the GNU CRT, nothing compiled with GCC can be closed source for the simple reason it depends on those modules for basic functionality and those modules are all GPL.

It's possible that a quick read of the license might clear this up... <grin>

There's a special exception for components that are normally distributed with an operating system:

  "For an executable work, complete source
  code means all the source code for all modules it contains, plus any
  associated interface definition files, plus the scripts used to
  control compilation and installation of the executable.  However, as a
  special exception, the source code distributed need not include
  anything that is normally distributed (in either source or binary
  form) with the major components (compiler, kernel, and so on) of the
  operating system on which the executable runs, unless that component
  itself accompanies the executable."
  ( )



That only pertains to the requirements of what you must distribute with your code. They are merely saying, if your code runs on GNU Linux and depends on the the C runtime library that comes with GNU Linux, you don't have to include all that since the user has other means to obtain it. However, by your interpretation of the GPL, (and I am not saying it's wrong), a 100% original work that is based in and depends on the GNU C runtime or is compiled in GCC is automatically required to be released under the GPL and therefore cannot be closed source. This also pertains to scripts written in perl or Ruby or whatever, since those projects and foundations are GPL and any work depending on them must also be released under GPL in order to comply with the license. In other words, if you are going to write programs in the GPL Linux environment, all your programs are automatically GPL and you must provide sources upon request, otherwise you are in violation of the GPL.

Tech Junkie Lounge / Re: Open Source Licenses
« on: March 09, 2008, 11:06:18 PM »
Which means that no program written on Linux or GNU or any one of myriad derivatives of Linux can be closed source. No perl programs, no Ruby programs, nothing based on the GNU CRT, nothing compiled with GCC can be closed source for the simple reason it depends on those modules for basic functionality and those modules are all GPL.

Tech Junkie Lounge / Re: Open Source Licenses
« on: March 09, 2008, 09:37:51 AM »

If I make my own, 100% original work I can attach any license to it I want, but that's only if i use 100% original work.  Once I inject some GPL source I loose all my personal rights to release it how I want.

As I understand it, the GPL applies to the code published under the GPL. As a component module of your own code, only the GPL portion needs to be made available, for example a JPG library used in your own JPG viewer program with interface code written by you. The GPL would apply to any modifications you make to the original work that was published under the GPL.

On the other hand, if you modify a GPL program but it remains substantially what it was before your modifications, it's a derivative work and must be published under the GPL. Taking GPL code, you must acknowlege the original authors and you cannot copyright the derivative work because using the GPL code means you accepted their terms that you cannot copyright it as your own work except for the portion that is your own and then you must publish your changes under the terms of the GPL.

If your project is substantially your own and closed-source, using unmodified support modules that were GPL, you don't have to publish your closed source but you do have to provide the GPL source of the GPL modules upon request. This might help someone reverse your private code.

Of course, we have to discern between GPL 1, GPL2 and GPL3. I believe GPL3 is one of the knottiest (nuttiest) licenses around.


0x1337c0de / Re: Questions on General Software Design.
« on: March 07, 2008, 08:47:52 PM »
oh and could someone explain bit significance and byte ordering like little endian and so on...

Endianness is a property of the CPU architecture. It can refer to bits or bytes, although it's rare to see it referred to bits these days. In the days of minicomputers like the PDP-8 bit 15 was the least-significant bit (the one on the right) and had the value 2^0 and bit 0 had the value 2^15 and was on the left. (Left and right were the on the register panel and the toggle switches below it.) The PDP-8 was actually a 12-bit machine (bits 0 thru 11) but had extensions on the memory address to add 3 more bits to the most significant end of the address. The PDP-8A control panel had switches on the front panel for toggling in the programs. This front panel was later emulated on the MITS Altair 8800 that had a Intel 8080 microprocessor in it. In the case of the microprocessors, bit 0 was on the right, value 2^0 and bit 8 or bit 15 were on the left for registers or addresses. The endianness of the bit values were the same but when referring to the bit number the endianness was reversed. I don't think the PDP-8 had any bit-address mode instructions but if you referred to bit 7 in PDP-8's it's value was 2^8 or 256 vs. 2^7 or 128 in 8080's or any microprocessors that came later.

Little endian bit index order and enumerating them from right to left makes more sense because the bit address (offset) corresponds to the power of 2 it represents. Offset 0 is 2^0, offset n is 2^n.

Offset refers to the position of a byte in a file or memory block. The first byte has offset zero, or is the zeroth byte in the block, then offset 1, 2, 3 , etc. until offset n-1, n for any n items in a list. An offset refers to the order of the items in a list, the list could contain bytes, words, or double-words or could even be structures of bytes. Programmers always call offset of the first item in a list as offset zero. Some older computer languages allow counting to begin at 1 instead of 0.

Endianness in byte order refers to the way the bytes are stored in memory or even transmitted serially. If ABCD represents 4 bytes, then on little-endian machines they are stored in memory as DCBA where:

Offset    Byte
   0           D
   1           C
   2           B
   3           A

On big-endian machines they are stored as:

Offset    Byte
   0           A
   1           B
   2           C
   3           D

This is great when sending bytes serially since you can walk right down the list and they will be transmitted exactly as they are stored in memory as bytes and they will "read" left to right in this fashion. This is why big-endian was chosen as network byte order in the early days of the Internet. (The first networked computers were big-endian.)

This doesn't apply to byte strings however. Strings are always stored in memory from lowest to highest address first character to last character regardless of the endianness of the computer. It's only when you start talking about multi-byte values that it gets interesting.

Take the 16-bit example. If AB and CD represent the bytes of two 16 bit integers, the little endian machine will store them as:

Offset    Byte
   0           B
   1           A
   2           D
   3           C

The big-endian will store them as:

Offset    Byte
   0           A
   1           B
   2           C
   3           D

Storing or transmitting them from a big endian machine to a little endian machine must take this into account and they must know the nature of the data they are trying to transmit.

Trouble Shooting / Re: r1q2 and downloading maps
« on: March 02, 2008, 06:00:43 PM »
By my count, there are 48 original maps in Q2. The first group of 45 is in pak0.pak with the others in pak1 and pak3 as listed in comments below.

static char *stockmaps[48] = {
   "base1", "base2", "base3", "biggun", "boss1",
      "boss2", "bunk1", "city1", "city2", "city3",
      "command", "cool1", "fact1", "fact2", "fact3",
      "hangar1", "hangar2", "jail1", "jail2", "jail3",
      "jail4", "jail5", "lab", "mine1", "mine2",
      "mine3", "mine4", "mintro", "power1", "power2",
      "security", "space", "strike", "train", "ware1",
      "ware2", "waste1", "waste2", "waste3", "q2dm1",
      "q2dm2", "q2dm3", "q2dm4", "q2dm5", "q2dm6",
      "q2dm7", "q2dm8", // pak1.pak
      "match1" //pak3.pak

There was a demo version of Q2 circulating at one time. I am not sure if it was official or not. I know several users showed up intermittently on servers and they didn't have certain maps. I remember one user was missing "mintro" in her demo, not sure how many other maps might have been missing as well.

/dev/random / Re: Separated At Birth
« on: February 17, 2008, 11:10:14 PM »
hmmmm.... hirsute and no ears. Highly suspicious.

Who's been banging on the windows with a hammer anyway?

Girls go crazy 'bout a sharp dressed man.

Tech Junkie Lounge / Re: Tech Junkie Quotes
« on: February 17, 2008, 01:00:25 AM »

  Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan

Hard not to love it when it rings so true.

Write code as if an idiot will be debugging it a year from now.
A year from now that idiot will be you. -- QwazyWabbit

Curse the smartass that wrote this impenetrable piece of code last year. ;)


Tech Junkie Lounge / Re: Vint Cerf
« on: February 04, 2008, 10:14:06 AM »
I liked perl, it's very much like a high-level C and it's great for smallish programs that one person can manage. Unfortunately I kind of burned out on it doing web backends for a friend who promised to pay for some urgently needed stuff and learning Perl against a deadline or under delivery pressure is not fun. Left a bad taste when the pro quo fizzled. I deal with it. :) I do small stuff for myself from time to time. Another feature of perl's pedigree is the cult of anti-cultists who surround it in the newsgroups. Submit code to the comp.lang.perl group at your own peril. They will call it cargo cult, lame, rip it to shreds even when it came from something previously posted as good stuff. Perl at the time I was learning it was still evolving, if it was written yesterday it's obsolete cargo-cult today. Yesterday's detainting is today's vulnerable code.

Ruby sounds like fun. I will have to find some time to look at it more closely.

Java is becoming the code du jour. It's in my Blackberry and seems to do the job nicely. I need to browse for some open source stuff for the BB, maybe a nice RPN calculator like my HP48. :) hmmmmm color graphics....  :bigshades:

Tech Junkie Lounge / Re: Vint Cerf
« on: February 03, 2008, 09:06:00 PM »
No system made by man is perfect. There will always be a flaw that can be exploited. -end philosophic platitude-

Seriously, programming languages are evolving and getting better at being good tools and not providing implicit attack points.

C was conceived before there was a substantial Internet. A program could trust its own data. The only danger to a UNIX box was it's users. UNIX as it was implemented had all kinds of flaws that if you placed a naked unix box on the net today, it would perish as fast as any Windows box. There is nothing wrong with the C language itself, it has all the constructs needed in most programs. There were some compromises made back when the ANSI standard was being set and the "standard library" was being defined that led to some pretty stupid decisions and implementations in the library that made it hard to not make mistakes or that automatically created some opportunities for exploitation. Those decisions were made by the commitee seeking compatibility and breaking the least amount of existing code, they weren't very security concious at that time. At the same time nothing prevents a programmer from designing his own library focused on security and ease of use and correctness. Perl, PHP and Python were written in C, IIRC, and fundamentally use the standard C library at their core.

As for sendmail, it's almost as ancient as UNIX itself. It's old and complex and if it still has vulnerabilities it's probably because it's hard to maintain. I have never looked at it's code but I would imagine it has some places that could stand some good security review.

Language selection is based on requirements or personal preference. I can almost write a C program faster than I can in Perl. That's because I know C a little better. My Perl programs tend to be a little C'ish and I will sometimes make some idomatic mistakes.

Java is a good tool but the programs tend to be slow for the same functionality in a compiled language like Perl or C. The trouble I have with JVM, MFC, and the managed code libraries like the .NET framework is that you are dependent on a library you know almost nothing about, can't fix, can't maintain, can't snoop, and can't do without. You become a library junky. Dependent on a junky library. How many JVM versions are there? What did they fix and why? (See buffer overflows.) Sun has made JVM deployment mistakes all over the place and it's a PITA.

A good programmer writes his own libraries or at least organizes his functions in such a way that he can re-use them to build better programs. If you don't like malloc()/free() you can write your own. :) Good luck. Java takes that right away from you. They don't call it garbage collection for nothing. I remember coding in BASIC on the TRS-80 I in 1977 and watching my program stall suddenly while the BASIC interpreter collected garbage. We have not gone that far, really.

Anyone read the coding standards manual for the JSF recently? FYI, flight systems code is in C++. :)

Quake / Re: Railgun meets real life.
« on: February 02, 2008, 10:51:14 AM »
Looks good! Time to buy some Encabulator stock and get in on the ground floor of some amazing technobabble. :)

Quake / Re: Railgun meets real life.
« on: February 01, 2008, 07:07:35 PM »
Here's the straight skinny on the RG from the lab, without the brain-dead filtration by the newsies.

It's been in development quite a while. Getting it down to a deployable weapon from a research tool is the key.

In this test 2520 Meters/sec. muzzle velocity = Mach 7.6  or 8267 feet/sec.

10.6 MJ is only 2.94 kilowatt-hours but the peak power and power density in the weapon leads to intense temperatures in the bore. You have to have mass in the weapon to dissipate the heat and to survive the kickback. (Not a good handheld weapon.) Newton's laws still apply. (F = ma = d(mv)/dt)

The mass of the projectile was 3.520 kg according to the video. You need to know the length of the rifle to know the acceleration but it looks about 3 meters long. 3/2520 = 0.00119 secs or 1.19 milliseconds to go from 0 to muzzle velocity.
3.52 kg x 2520 m/s / 0.00119 s = 7454117.6 kg-m/s^2 (Newtons) or about 1.676 million pounds. Quite a kick.

You might have a nice K.E. weapon as a "needler" from SciFi novels. Something low mass like a 10mg needle at those speeds would do some damage. You might be able to create a rifle with a backpack power supply but then you would need another soldier to carry all the other gear they both would need. Great if you are sniper team. :)

From the paper, reading between the lines, it looks like the big techno hurdles are pulse generator design and material science on the projectiles and the bore. The intense heat and friction makes for some awesome erosion, I would imagine. Another factor would be moving all the air in front of the projectile out of the muzzle. That's why it's got such a huge muzzle flare. That's all just ionized gasses from the displaced air.

Quake / Re: Anticheat for linux
« on: January 19, 2008, 05:14:28 PM »
Dang. I was looking forward to a nice flame war and religious debate and he agrees with me in the first round.

I am just going to have to go back to lurk mode and buy a tee shirt.

Quake / Re: Anticheat for linux
« on: January 19, 2008, 12:15:23 PM »
Quote from: X&#039;tyfe on January 19, 2008, 07:22:43 AM
Quote from: X'tyfe on January 19, 2008, 07:22:43 AM
i would like to point out that CHEATS AND HACKS DO NOT EXIST FOR LINUX
that is all :)

Patently false assertion.
Model spikes and hacks will work with Linux just as well as in a Windows client. These are what AC was intended to detect.
Brightskins work in Linux as well as Windows. They are not OS dependent.
Gloom depends on certain client variables remaining in specified limits. These can be tweaked in Linux as easily as in Windows. There is no method to verify the variables are within those limits except for a mechanism like AC.
Anyone with bot sources can build an aimbot for the Linux clients.
Anyone with Linux skills is more likely to have access to cheat sources and be skilled enough to use them, perhaps more skilled than some Windows users who just load the stuff and need to be spoon fed the tools.

Using a Linux client does not automatically confer "Purity of Code".


1215 / Re: Creation of a tastyspleen LoX server?
« on: January 05, 2008, 12:05:25 AM »
Don't know what these CVAR's do QwazyWabbit

Pages: 1 ... 71 72 73 74 75 76 77 78 79 80 [81] 82