Um... I'm not normally one of those guys who goes around bashing XML.... but this case... I'd have to say "the problem is XML". Really.
When you consider how much effort Blizzard goes through to keep their packets compact, so that their servers can perform efficiently and the clients can survive on low bandwidth (playable over a modem!) its just sort of laughable to hear someone changing TO XML in their protocol.
If ever there was a time for hand-crafted bit-packed binary encoding, its client/server communication on MMO games.
SilverDirk
@SilverDirk
Best posts made by SilverDirk
Latest posts made by SilverDirk
-
RE: XML endianness problems
-
RE: The end of Google
but a more fun one is
negative e to the power of (pi times i) -
RE: The registration system - part 2
so in short, they were re-inventing reflection with a half-assed interface? and then using this pseudo-reflection throughout the code instead of compiler-verified statements?
-
RE: Querying tree structure in db
So wierd... I was just hopping on TDWTF forums to ask this very question.
The best I had come up with so far was to define the record mostly as you had, and use a WTFish query to pull it in. (thus the idea to ask on TDWTF forums, heh)
create table Linkage (
ParentID integer,
ChildID integer
);
create table DataTable {
ID integer,
// etc
// etc
);
select L0.ParentID as ParentID, {data fields}
from Linkage L0 left join DataTable d on d.ID = L0.ChildID
where L0.ParentID = {Root}
union all
select L1.ParentID as ParentID, {data fields}
from Linkage L0 left join Linkage L1 on L1.ParentID = L0.ChildID left join DataTable d on d.ID = L1.ChildID
where L0.ParentID = {Root}
union all
...
select L5.ParentID as ParentID, {data fields}
from Linkage L0 ......
...
I generate the query in a loop for as many levels of hierarchy as I need. Its ugly, but seems to work ok.
My situation is more complicated because I don't have a tree... I have a directed graph. The logical way to handle it is to query each record individually, add records it links to to a "work list" (implemented as a set keyed on NodeID), then query links of items in the work list until I have as many results as I want or exhaust the nodes of the graph. but it seems inefficient to run a bunch of sequential queries, since I'll get hit with communications turnaround time on each iteration. So I came up with the above WTF to pull accross a batch at a time.
Any suggestions? -
RE: Computer King
[quote user="The Hermit"]
Just remember, one day this guy will be your manager.
-The Hermit
[/quote]
The Hermit speaks prophecy. Note the facts: he likes titles of power and authority. he likes micro-managing unimportant details. He has the desire to be part of computer or robotics-related projects, and enough technical knowledge to slip through an interview.
Once he gets a job, in a computer field no doubt, they will quickly realize that he has no business touching code, and will push him into management.
"The Real WTF" is that he will make more money than you, and decide your yearly raises ;-) It might be in your best interest to start doing his homework.
-
Bet you've never seen THIS in bash
## Calculate the magnitude of a vector
# For numbers which are close to forming a unit vector, the initial guess of
# Mag^2/FIXEDPT is very close, and tends to converge in just 2-4 iterations.
# Note that this only approximates sqrt, since I don't bother to round properly
#
# @param $1: x coordinate
# @param $2: y coordinate
# @param $3: z coordinate
# @return $Result: the approximate magnitude of the vector
#
eval "Magnitude3D() {
local magsq=\$1*\$1+\$2*\$2+\$3*\$3 mag=magsq/$FIXEDPT prevmag=0
while((prevmag-mag>1||mag-prevmag>1));do((prevmag=mag,mag=(mag+magsq/mag)/2));done
let Result=mag
}"And, fyi, bash only has integer variables, so this is all done using fixed-point math. ($FIXEDPT in this particular script is set to 1000). The "eval" bit has the effect of "compiling" the constant of 1000 into the function, so that it doesn't get variable-expanded on each call.