[quote name='Sirisian' timestamp='1320181677' post='4879386']
Javascript needs to be replaced. I along with others online have mentioned this for a long long time.[/quote]
I'm quite new to JS, but from what I've seen, the language itself is "fine" (plus or minus personal preferences or offbeat requirements).
What needs to be replaced is its integration in browsers, mostly
[list=1]
[*]The overly shitty execution model that allows for "fun" things like just executing stuff by appending it to the document, and
[*]The supremely half-assed brainless DOM API that just does some things wrong (ever tried using an onclick handler on a submit button?) and is generally decoupled from what the DOM is really looking and acting like.
[/list]
Both are not language-, but integration issues.

[quote name='AndreTheGiant' timestamp='1298827695' post='4779720']
Not 100% sure what you mean by SOCKET... and I'm even less sure what an LSA SOCKET is. I gooogled it but wasnt to confident with the results. Can you explain a little bit?[/quote]
A socket in this context is what you plug a cable into. LSA is a type of wire connector that's basically a row of pressure contacts that you put the wires in and push it into position and cut it off with a special tool, so you don't need to strip individual leads. It's standard for that kind of wiring. Works like that:
[url="http://www.youtube.com/watch?v=sHy8mtW9eak"]http://www.youtube.c...h?v=sHy8mtW9eak[/url]

Ethernet cabling in the post-10Mb/s world is a one-cable-per-socket thing. You could technically still run two 100Mbit links over a single Cat6 or Cat7 cable, but that requires luck and forbids gigabit ethernet. Don't use powerline, that stuff is retarded. If you need to hack around a connectivity shortage, use WLAN. If that doesn't work, use a power drill.
IME, most rooms will be fine with two sockets, so you run two cables there. Have 4 or even 6 sockets in rooms used as home office (PC, laptop, network printer(s), …) and where you park your entertainment electronics (networked TV, game consoles, but that stuff will be fine when you run it all over a single switch). If you're using wired phones, reserve a cable for those; the 4- and 6-wire modular plugs on phone cables fit in RJ45 sockets.
On cables: Cat6 is fine and should be completely sufficient too, Cat7 is overkill in home installations that aren't neighbouring an aluminium melter. It's already fairly unwieldy since it has lots of shielding, but since you are building the walls around it, that shouldn't be an issue. You can also run GE over Cat5 links with some luck, and chances with Cat5e are really good. TL;DR: Get Cat6, if you can't fit that into some hole, use Cat5e there.
On sockets: GET LSA SOCKETS! This cannot be stressed enough. I had the joy of installing sockets where the cable contacts were screw terminals. After wiring one or two of those, Cthulhu sounds like a nice guy. Make sure they're Cat6.
On tools: You need an LSA tool with integrated cutter, and an insulation stripper for multi-lead cables. You can theoretically get away without those, but believe me, you want them.

Use caustics sparingly, they are mostly a shallow water effect that gets lost with depth very quickly. A lot of ambience under water is from the very specific light filtering, as well as floating particles and audio.

[quote name='flodywan' timestamp='1294714448' post='4757027']
Doesn't this mean that pacman would have to be the same size as all the other tiles?[/quote]
As the article states, the sprites can be bigger than the "tiles"; however, the only thing that counts for collision is the centre point of the sprites. Animation is smooth.
One approach would be to limit movement so that the centre point of an actor cannot move beyond the centre of a tile if the tile beyond it (along the path of the actor) is a wall.

The situation on Mac seems to be a bit of a charlie foxtrot, since it traditionally used colons as separators. If you are just targeting OSX, use slashes (it's U**x based). Make sure you do not use slashes or colons inside path elements, since things get interesting then.

Quote:Original post by SteveDeFacto After watching iron man I really wanted a hologram and my best idea would be to fill a room with a non toxic gas and use multiple microwave beams that intersect to create the exact frequency which causes the gas to glow at one point in 3D space. I don't know much about chemicals to know which gas would work if any. Anyone know of a gas that would do this? Using microwaves, i.e., frequencies in the (low) single-digit gigahertz range, is not a good idea. It's hard to impossible to focus them precisely, and getting the intersection of multiple emitters right so you get an energy peak in a well-defined location is even harder. Add to that the fact that the microwave absorption of most gases (at least at room temperature and normal pressure levels) sucks, and you don't exactly get a winner technology. Just for reference, there has been some research into targeted signal jamming that aims to destroy a signal at a receiver by destructive interference. The setups for that require very strictly controlled environments, i.e., RF-anechoic chambers, and very precise hardware that sits squarely in the 6-digit Euro price region for ~20dBm EIRP transmissions in the 2.4GHz ISM band. Even with that, the results are mixed. And that's for a controlled result in a very small region that's roughly a sphere with 12cm radius.

Quote:Original post by pablo24 Anyway this seems like evil stuff, are you trying to hook into another program? Judging from the offset, it's a Quake 3 engine game, possibly MOHAA. I don't think he'll run into issues with updated binaries there ;-)

Quote:Original post by Antheus It is also a fact that many routers are crap. Of two brand name mid-range home routers I've had, one dropped 60% of UDP traffic for no reason, the other's firewall would flip out if a burst of traffic arrived and blocked the IP. This latter behavior is very annoying since some ISP use internal buffering and on first request return cached request buffered, so it looks like 10 packets arrived in <1us. In neither case was bandwidth the problem. The consumer commodity hardware just goes out of fashion so fast it simply doesn't make economic sense to actually deliver robust solutions. Or maybe it would make it, but it would reduce the bonus of CEOs due to lower volume. You seriously need to change your router brand. Most consumer routers today do not have issues with high packet rates, it's only a minority that does, and those can relatively often be fixed with firmware updates. Sure, most routers are crap, no question about that, but if it can't deal with something on the order of a few 100's of packets per second, it's a broken rarity by today's standards. If a connection craps out at some 10's of PPS like the OP described, then that's really not descriptive of the marketplace, but somewhere all the way down the long tail. About the ISP buffering issue, that's a sign of your ISP's backbone choking on high load, driving some switches to saturation; it does not mean that there is request-based buffering somewhere in the system, since that would again require high-layer awareness in the infrastructure, possibly all the way up to the application layer. In that case, you need to change ISPs in the hope of finding someone with better infrastructure or peering. A bit of jitter up to the point of reordering is unavoidable due to the way the Internet works, but if it's the norm on your connection, it's a sign to go shopping.

Quote:Original post by Antheus Blizzard, EA and such can use anything they want - ISPs will make sure it gets through. They might even give it priority boost. Router manufacturers will build priority rules into their firmware or not filter it. Windows will add exception rule to its firewall. You don't get such royal treatment. UDP was vector of attack for much of malware and botnets, so ISPs often filter it, so do routers. That is hogwash. Any semi-realtime applications uses UDP, in fact only a minority of games and applications use TCP for data that needs to be streamed fast and steady, and can take a bit of loss and reordering. Applications like VoIP (Skype, Mumble, Teamspeak, Ventrilo, etc.) all happily push a huge number of UDP packets per time unit (Mumble and TS3 hit around 100 packets per second in the lowest-delay modes, and then some more packets over the administrative TCP connections), and only a small minority of connections have issues with that; most of the time, it's plain broken routers choking on the high packet rate. DNS and NTP use UDP as well, as it cuts down on connection setup and maintenance for short-lived peer associations. And here's a small secret: most of the infrastructure running the internet is completely oblivious to layers 4 and above. They just stop caring at the IP layer, because they don't need to know more, and processing higher layers is just too slow and expensive. There is no conspiracy to kill UDP, since it would be too expensive to do it, and also an idea that's so dumb that not even major ISPs will think about it. One of the big issues today are trigger-happy pseudo-firewall features on consumer routers or in personal "security" applications that go by fancy names such as "heuristic <insert bullshit here>" or "stateful packet inspection", which will more or less randomly declare data streams malicious and drop them. As for the rest, I urge you to read up on at least the major TCP features and quirks.

IMO you would only lose flexibility when not having items as widgets. If they are widgets, you have unified calls for drawing, drag&drop, input handling, etc.; just make sure that the concept of a "widget" doesn't become a CPU-intensive monstrosity. List views are usually handled something like this: Determine visible items from viewport and backing model (gives a list of visible items with data relevant to positioning, item sizes, etc.) Draw all visible items to the list view's "content" viewport (determined by styling elements such as borders, scroll controls, etc.) Draw view styling elements (done last to ensure overlay effects work properly) A similar thing goes for input handling. If the user clicks inside the list view, and doesn't hit a control element, the list determines visibility and positioning of the contents, and hands off handling to the child widget.

That kind of hot failover sounds hard to get right, to say the least. I'd imagine such a setup would work kinda like coherent cache, with the hot standby permanently replicating the primary server's state (possibly through OS kernel-level replication facilities), so that the load balancer effectively just redirects the MAC layer when the primary fails. The connection would still go through the balancer, and the layer 3 endpoint doesn't change in that case, since you're switching to a perfect clone for all it's worth.

Quote:Original post by hplus0603 Quote:Not on the TCP layer. There actually exists hardware that will do this for you. Some front-end load balancers will implement reverse NAT, and re-write an incoming stream to go to some destination server. That doesn't take the translator out of the image though, it is needed for the whole duration of the connection. You can't make a TCP connection change endpoints at runtime like a cheap Stargate, since that would require modifying connection state in the network stack of both endpoint systems. AFAIK that functionality is implemented in SCTP, at least by adding the redirect target as an alternative endpoint and then removing the original server.

The IV generation from a PSK is documented in the 802.11 standard including all algorithms, so looking at that seems like a good idea. I've been digging through that for some time, and apart from some brain-twisting formulations, it's not a bad read.

Quote:Original post by Shimajda Is there any way that first server could redirect connection from clinet to another server by himself? (i mean client will have to connect only to the first server, and that server will take care of redirecting to another) Not on the TCP layer. A connection is uniquely identified by (local address/port; remote address/port), and that information can not be changed dynamically. Your redirection requires an application-level redirect like an HTTP 302 response.