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