JoWie

It happens everywhere, yes. Do note these "virtual particles" do not behave completely the same as real particles. They are more conceptual descriptions (they are not directly observable, except for the effects they can cause). If you treat them the same as particles it will appear as if they violate some fundamental laws. But the basic idea is that each fundamental particle has a field that it belongs to (e.g. photon field aka electromagnetic field, electron field). These fields stretch out in all dimension, with a total energy of 0 (except the higgs field). An excited state in such a field is a particle.Virtual particles are the fluctuations in these fields. The energy of these fields are quantized (quantum!), similar to integers in math, e.g. there's 1 2 and 3, but not 1.2 1.3 1.5 etc. As for the unpredictability thing, I like to think of it like this: Suppose you have a dice that you roll an infinite number of times. There is no pattern to it, nor does it appear to have one most of the time. But at some point you might roll the same number thousands of times in a row. It might appear as if the dice is flawed somehow, but this is just something that might happen in such a random process. As for the universe, we are not seeing all of the permutations that did not lead to the state we are currently in. The chance that you exist is incredibly small, but if this randomness goes on for long enough (infinitively), it will happen again and again. This is similar to the evolution of species, you only see the "winners".

IANAP but, let me confuse you some more: A vacuum is not the same as absolute nothingness. A vacuum just means the average energy is minimal (vacuum energy). In a vacuum particles suddenly exist out of nowhere and are usually annihilated shortly after. Google the Casimir effect. It is even possible that a stable particle forms, although very unlikely. Some go as far to theorize there is even a tiny chance something like a car suddenly forms out of nowhere (and even that this is how the big bang started).

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.

This is probably the same thing that happens on an unpatched wine... Try running continuum as administrator. Also, if it occurs again, you can get rid of continuum.exe in your task manager by temporarily renaming continuum.exe to something different.

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.

Trench Wars was updated using DNS, so I am guessing chaos never set that up. (that is what the ss:// links in the zone descriptions are for)

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

I managed to get continuum working (the clean way). And at the moment I am busy getting the patches through their submission procedure. (this will probably take a few more days). If this succeeds, you would be able to get continuum to work by just installing the wine beta (I am hoping Wine 1.7.22). You can install the beta from a repository: http://www.winehq.org/download/ubuntu If you want that hack to work you need to compile wine yourself, replacing that so file will only work if it exactly matches the correct wine version. The easiest way to compile wine is to set up a virtual machine with a 32 bit linux flavor.

That hack on wine.getcontinuum still works (I just tried it), but you need to compile wine from source yourself. Anyway, what I have figured out so far is that Wine implements SetSecurityInfo and GetSecurityInfo. It ignores the given SECURITY_DESCRIPTOR in CreateProcess though. So that will need to be added first, after that doing the proper check in OpenProcess should fix the issue in a clean way.

My experience with winapi is limited, but from what I understand is. You can create a process using a security descriptor to provide a DACL: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379560%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379561%28v=vs.85%29.aspx What I am guessing is that continuum does this in such a way that PROCESS_VM_WRITE is not allowed, and it checks for it (if not present, you experience the never ending spawning of continuum.exe). If you open a process using PROCESS_VM_WRITE you can use the method WriteProcessMemory to modify the memory of the process. This is a common method for cheats, trainers, etc. This protection is simply to bypass though, by giving your process (the trainer) SeDebugPrivilege ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa446619%28v=vs.85%29.aspx ). Wine does not check the DACL in OpenProcess, so continuums check fails ( http://source.winehq.org/source/dlls/kernel32/process.c?v=wine-1.7.19#L2930 ). From that test case it looks like Wine implements all those security functions: http://source.winehq.org/source/dlls/advapi32/security.c?v=wine-1.7.19 http://source.winehq.org/source/dlls/ntdll/sec.c?v=wine-1.7.19 and they are also stored when creating the process: http://source.winehq.org/source/dlls/kernel32/process.c?v=wine-1.7.19#L1925 So it seems like resolving http://bugs.winehq.org/show_bug.cgi?id=22006 in a proper way would be that hard, most is already in place. I *might* give it a shot. I just worry about getting all the little details right in an identical way to windows, so lots of test cases are needed. Also, cheating in continuum from within Wine would be interesting. Seems much easier to bypass most of the checks.

Has this issue ever been reported to wine? This patch seems like a very dirty hack, it prevents any process from using WriteProcessMemory.

Is it supposed to work unpatched nowadays? If so I can try on kubuntu trusty

You could try patching dcme to your liking too. The source is available somewhere. All you need is visual basic 6 (hahaha)