numpf

can the forum be set to autolock/close topics that haven't been posted to for X time? Re-*BAD WORD*-s who reincarnate dead threads need to go away. Maybe there are some threads that are appropriate to revive, but I've never seen one. Pinned/stickies/whatever should obviously be exempt. -numpf

This happens to me very rarely without an app that steals focus. When it happens you should see 2 icond in your taskbar, 1 for the chat screen and another for continuum. I am always able to just get right back into cont by pressing the other icon in the taskbar.

I certainly do enjoy shooting down attempt at advice/criticism when they are stupid. I could have said what Dr. Brain did, but my way was more fun. I don't believe in tact, especially when situation isn't such that you can smack me if you get put in your place. If something is stupid it should be identified clearly as such, so that not only can the idea be ignored, but the rest of the ideas from that person can be judged in the context of poor credibility. Especially when it's painfully clear they made a lame attempt to showcase their 'talent'. Furthermore, people who aren't confident (and confidence suggests knowledge, which suggests a good idea) in their ideas might read some of my posts and be more tentative about wasting everyone's time for fear of the ripping you're getting. In closing, stfu -numpf

better option: have priitk spend any time he would spend on this idea on something worthwhile. I believe this post can be paraphrased "look ma I can use photoshop" -numpf

The relevant setting is a per-ship setting, SoccerBallFriction I don't know its units and/or how it's used. Your guess about calculating position is probably wrong. I very much doubt that the client calculates the position from the origin of the ball packet each tick. It's more likely that each tick T it does P(T) = P(T-1) + P(1) and stores P(T) to use as P(T-1) next tick. The reason being that the ball bounces, and the client has to do intersection tests with each possible tile position, and if appropriate, collision response. If you calculated position from the origin, and the ball has low or 0 friction, it might have to do 1000s of tests/responses every tick, which wouldn't be reasonable. Using the above formula, you only have to test/respond to the tiles that you've crossed in the last 10ms rather than, potentially, the last 3min. I don't know about stopped balls having nonzero vel. -numpf

Have you tested this? I did what ek says he does long ago, and the portions of the EXE I extracted came to about 220KB if I remember correctly. Maybe I remember wrong, but your code seems too short to work. I suppose you did some simplification?

If you didn't mentally ask yourself "dynamic or static?" when clicking the link to get to this thread, you are not cool enough to post on it. You may read, but I will murder your family if you post. This is a list of links to major resources for general game programming. The first site I really found outside of MSDN was http://www.gamedev.net There's some good stuff there if you look, but most of gamedev-net articles are outdated or garbage. They link to some nice ones on another site, which has some good stuff. I revisit this one fairly often to check certain things: http://www.gamasutra.com/ The standard list of course is: http://msdn.microsoft.com/ - specifically the link to the library. I don't know how you could develop anything on windows and not use this. http://www.opengl.org/ - most popular portable graphics library. Even if you are writing a "2D" app you should probably use a 3D lib like OGL or Direct3D. If you go to learn OGL, you'll want "The Red Book." I believe it's in the OGL section of gamedev. http://developer.nvidia.com - good 'intermediate' stuff for 3D gfx. http://www.openal.org/ - an audio library modelled after OGL. I can't vouch for it myself but it seems widely-used. http://glfw.sourceforge.net - if you undertake learning OGL, you'll soon learn what GLUT is. This is an alternative. I've only started using it, but it seems better. I've only just come across these in the news archives of gamedev, so I've yet to really evaluate them. The first looks like it has an extensive set of very gentle tutorials: http://www.ultimategameprogramming.com http://www.devmaster.net/ If either of those are garbage lmk and I'll edit them out. Anyone else have some _good_ links for the newbies who are asking all these stupid questions? -numpf

No it's not. You have no idea what you're talking about, so stop. Infantry has some kind of drag, otherwise you wouldn't slow down if you stopped thrusting (or walking, whatever). How it's implemented exactly I don't know, but a max speed is different than drag.

No there isn't. What you're talking about is truncation due to clamping speed to a max. That isn't, and shouldn't be called, drag. A 'natural' max speed is determined by drag vs max acceleration. We have an artificial max speed, which is necessary given the constraints that you don't want drag, and you don't want your physics to "explode." -numpf

This is ridiculous, plenty of games implement a drag coefficient, and so can cont. The major source of inconsistency in cont physics is the unpredictability WHETHER a player is thrusting or not combined with latency. Drag (as long as you dont allow it to vary per-player, which would be stupid) is completely predictable; there's no case (rather, you shouldn't allow there to be a case) where someone is not affected by drag. If you added drag to cont, you'd have to be careful of a few things. First, cont probably internally makes some guesses about whether another player is thrusting based on pkt history. Those guesses would have to be reevaluated in the context of how players would behave if there were drag in a zone. Further, the total acceleration would be drag (always negative), plus thrust. If you start thrusting opposite the direction of your current velocity, the total negative acceleration will be higher than if it were just thrust. Since higher potential acceleration can cause greater inconsistency, zones would have to be aware of it and set 'tasteful' limits. As long as you didn't set the drag coefficient to Ragu's Thick and Hearty, this wouldn't be a problem. -numpf

If English is your first language and that sentence isn't sarcasm, you're one of said kids. Also, I believe my post was on-topic, even if it included little jabs. Who decided to let you mod this forum? -numpf

There are already settings for both of your suggestions. Misc:MaxPlaying - max players that can be in ships Misc:MaxPlayers - max players, ships + spectators You must play in a -*BAD WORD*-ty zone like TW or EG, because those are the only zones I know that purposefully set the total limit close to the ships limit. If you don't like the fact that the total limit is close to the player limit in your zone, be prepared to be ignored if you suggest changing it. They have a reason for having it set the way they do. The reason they do this is to forcefully spread out players and have as many active arenas as possible. This, in a way, makes the zone more accessible and helps add to its population. Anyway, you said "more smarter" so I'm going to ignore you from now on. -numpf

umm yes? I've used rogerwilco then teamspeak just fine with cont. Whiles there could be some minor features added with integration, I just dont see the need for it. If you see a _need_, you need to explain why and make a case for it, otherwise stfu. -numpf

current max packet size is set because it's safely under the lowest MTU for a modem. You can detect MTU size over a route (and since routes can change MTU can change), but the best you can hope for is under 1.5KB, as that's Ethernet's MTU. I wouldn't start going beyond 520 until lots of statistics were gathered on typical MTU changes between players and the server. -numpf

Of course the max packet size is 520 bytes, and the average cluster you could make would likely be significantly less than that. And Priitk plans to change the pos pkt to remove unused bits. -numpf

they've fleshed it out in much more detail. Holding a packet at the server for 100ms would introduce ridiculous latency. 10-20ms is about the limit. It's unlikely compression would yield much reduction in the average cluster once priitk cuts out the unused bits in pos pkts.

all the code for greens is in prize.* in backup.zip - I don't see any code for doors in merv.

I think he means for an arbitrary number of freqs, not all 10K.

This is again a case where you should probably ignore SS if you want to do something similar in a separate app. If I remember right, part of the problem with green sync is that it uses dynamic numbers... something like, you interpret the green seed based on the number of players in the arena. This creates a problem for entering players, because when they enter they are updated with the green seed when they enter, which is at a different time than other players. Similarly, I think it depends on how many or what greens currently exist. That's a problem because clients might destroy different greens. On your screen player X flew over green Y, but on mine he didn't. Your client destroys green Y and mine doesn't. If we sync based on whether green Y exists, our green sync is off. Sync like this comes down to very carefully choosing what random factors you use. They have to be random AND all the clients have to agree upon that random result.

cont uses a different encryption, which until duplicated (difficult), no client can login and be treated as a cont client. Priitk has _added_ a few packets to the protocol, and I believe added a checksum to every packet, but there's been no serious restructuring of the packets themselves that I know of, because modifying subgame to allow for that would probably be more work than writing a server. His modifications to subgame so far have been mainly additions... what we're talking about would be a massive restructuring, which is very different. Just makes more sense to wait for ASSS.

Yes, they have communicated quite a bit about saving bits and restructuring individual packets and the protocol at large. Priitk has an actual interest in this because he pays for hosting and believes he could save lots of money with some appropriate changes. Unfortunately it has to wait for ASSS to be tested and implemented. I'm not entirely sure where they are with testing. Once ASSS is adopted though I'm sure that's one of, if not the, first thing they'll look at changing. Packetloss and latency are measured by the server. I believe grel tracks packets much more comprehensively than subgame does, and with ASSS you'll be able to get much more information than ?lag shows you now. edit: Actually the client does most of this. There are some things the server could do to better report it though. -numpf

http://www.ntp.org/do-*BAD WORD*-entation.html and its links have extensive do-*BAD WORD*-entation on how the protocol is implemented, and all the painful details of clock sync, down to resonator aging. Ignore SS.

if I were going to write a client I wouldn't find your paper useful due almost entirely to your writing style. Anyone who wants authoritative and comprehensive information on how to sync should start here: http://www.ntp.org/ and should never ever look at SS code. are you just ignoring the problem of placing a physical event based on a wildly different origin time? -numpf

alright, I see what you buried in your "paper." 1.34 calculates a possibly flawed timestamp, to calculate the transit time which it clamps (during which the possible flaw is factored out), which it uses to (re)calculate the timestamp for physics. My bad, I can't imagine why I didn't think of that. However, if that's true, you wanna explain to me why transit time is clamped to 15 if it's over 4000? You don't see a problem with that? Whatever the case kids, if you're going to do net sync in your own app, don't use SS as a model. -numpf

holy -*BAD WORD*-ing -*BAD WORD*- you are totally -*BAD WORD*-ing braindead. You can disprove me in one of only two ways: a) prove 0x00010001 == 0x00000001 prove the trace of ek's sample through your code does not yield the results I listed. Judging by your responses in this thread so far, you're firing up a new set of sophistimicated Latin acronyms for your proof of (a) in your new "paper." -numpf