JoWie

it was the most fun when the 10slots, flashbangs and integer overflows were around.

would be cool if you could dynamically switch the mood of the soundscape based on what is going on in the game (e.g. being on a killing spree, close to winning a game, lots of enemies around you)

Just a quick fyi, i tried to enter omega fire a week or two ago and continuum keeps hanging during download. if i recall correctly this could be caused by a lvz file that is too big.

Here are a couple of pointers: Subspace simulates 100 frames a second (a 'tick") and catches up when it is no longer in sync with the clock (as opposed to using delta time in every formula)Every tick you simply use the Euler method to update the position for a step, this is accurate because you are syncing ticks instead of using delta time. So all you do is "newPosition = oldPosition.add(velocity)". If you are using delta time Euler is a bad idea, lookup Runge–Kutta 4 for one of the different methodsAvoid using Date to get the clock, it is very inaccurate and subject to changes to the clock by the user (or something like NTP). Try using Performance.nowIf your tiles are axis aligned and square, the following works for projectiles (0 size):Try storing your projectiles in a grid so that you can look them up by location very fast, instead of looping over every single projectile. If you make sure that " cell size = 2x " you can use bitshifts instead of division to get the cell coordinates.Decide if you want to simulate the collision path for the full position step within a tick (e.g. multiple collisions possible for a single entity within a tick), or only up to the first collision. The latter option is easier but less accurate at high speeds.If you are using synced ticks, you can do simple ray casting between the oldPosition and the newPosition to walk through all the tiles that might get hit. There are many methods for ray casting/tracing. I have used a modified "bresenham line algorithm" before, but I needed that specific one because I wanted to only use integers, so a different one is probably more suitable for you.When you have the tile you want to collide, figure out the tile line it should collide with (a tile has 4 lines). For example by calculating the distances between the center of the line and your oldPositionWhat you have now are two lines segments, find the intersection. You can easily find a good method for this. (for example Graphics Gems III page 199).You now have the specific tile you collided with, the point of intersection, and the tile side. If the projectile is something that bounces, flip the velocity along the proper axis and apply a bounce factorCollision between ships and tiles is a bit harder because they have a size (ships are square in subspace ). One thing you could do is turn the path the ship has taken into a convex polygon and find out the two intersection points between that convex polygon and a tile side.If you are doing multiplayer, look up dead reckon convergence for your ships. This book explains it in short (page 193)If you are doing multiplayer, make sure you understand the limitations of floating points, e.g. stuff like "cos(x) != cos(x)". Every number in javascript is 64 bit floating point (IEEE 754 to be precise).

logitech G19 hah

Try installing continuum into your documents folder instead of program files. To play chaos you need to manually add: 66.36.247.83 port 13500

Here's a guide: sudo apt-add-repository ppa:pipelight/stable sudo apt-get update sudo apt-get install wine-compholio wget http://www.getcontinuum.com/downloads/continuum/Continuum040Setup.exe /opt/wine-compholio/bin/wine Continuum040Setup.exe # click cancel on the dialog boxes that complain about mono (.NET) and gecko, they are not needed for continuum # Install to C:/Continuum/ so that the path easier to type /opt/wine-compholio/bin/wine ~/.wine/drive_c/Continuum/Continuum.exe

Because that might cause your packets to take a different route to the final destination (the subspace zones). Continuum only supports SOCKS proxies though, which are harder to find. I used to rent a small VPS in the USA for this kind of stuff (like bypassing georestrictions) which was set up with dante-server

I just got back from vacation, but I am going on another vacation tomorrow. A bunch of my patches got in, but not yet enough of them to make continuum work. In the mean time you could try wine-compholio which should have the patches you need to run continuum: https://launchpad.net/~ehoover/+archive/ubuntu/compholio

You could also try setting up a proxy because that might give you a different route to the servers. Finding a good proxy server might be hard though.

the engine used can handle that cheat freefreefree

modules controlling bots controlling modules controlling websites

If I recall correctly, a lot of valve games (FPS) lag players on purpose by a fixed amount like you mentioned. One thing some games also do is that the server tries to simulate the point of view for each player. Suppose your lag averages at 150ms, the server will then simulate a state with you as the context at 150ms (using identical code as the client). If you then fire a sniper rifle on an enemy, the server will then know if it was a hit on _your_ screen. (instead of relying on a kill yes/no determination generated by the enemy, such as in continuum). I am using a method that is based on that pdf I linked. The result of this method is a "server authoritative" protocol that does not need any server->client syncing packets as long as you can guarantee that no player ever lags more than a certain amount (for example 1500ms). (I do have some syncing packets in case that restriction is violated, I also employ redundancy to combat minor packetloss (the same move is sent many times (which is okay since a move is only 5 bits))). This means I can predict everything, even deaths of other players. These deaths are also reversible if it turns out to be incorrect (because you receive more packets that cause this conclusion). This took a large amount of work though, more than I first anticipated. I am not sure if I would pick this method if I started over haha. Something I also want to do later on is support P2P to reduce latency by sending your packets to nearby players directly. So, this is where I am at now hooking the remote actors and managing them. As it stands now player 'A' would be able to fire the weapon. I will probably deal with this by expanding the state buffer and comparing past actor states, but I am not sure yet. The solutions i have researched involve lagging the client actor by a given time (similar to trailing state) and having the server process client actors from the past. This would work in this scenario but at a cost to latency performance. But, I am working on it now and experimenting with a few different methods. My overriding concern is latency performance so I am trying to solve this without resorting to past state reconciliation. In general an authoritative server is difficult to implement in a twitch style inertia based game like PUSC or SS. Because the clients 'do not' send position or velocity data it can be difficult to accurately reflect actor states especially when server correcting a client actors position (with no snap back). But aside from a few little issues the model I have in place works well and does prevent cheating. One of the last issues to deal with is the above. It could also be valid to simply not handle such cases, which effectively mimics what such a case would look like in continuum.

So the server keeps a state for each individual actor to verify his actions? Does that state not only contains position & velocity but also things like health, energy, weapon fire delay, ammo, et cetera (which are all rollbacked)? Does it handle inconsistencies that arise because of interaction between players? Suppose the following occurs (where Pt = packet timestamp; At = arrival time) : At=100, Pt=50 : Player A fires a weapon costing 1000 energy (player has 1200 energy at this point) At=120, Pt=40 : Player B fires a weapon that hits Player A and it instantly damages that player for 600 energy. Does the server at this point rollback so that Player A never fired his weapon (because he does not have enough energy)?

Although he has never read it , he means this paper. An Efficient Synchronization Mechanism for Mirrored Game Architectures.pdf