JoWie

Nothing wrong with a thin abstraction layer as long as you can find a really good one.

Good luck. Few points of advice if you want any: + Do not waste time on being 100% compatible with continuum. + Do not use ASSS as an inspiration on threading

Sandboxie is not a VM

https://www.virtualbox.org/ hehe If i recall correctly http://www.sandboxie.com/ works too

I got my preference for the GPL from reading stallmans biography (I know someone who worked on that book). (Although, if I would make a library I would use BSD or LGPL.) If someone uses my work, I want them to share things they do with my work. I actually read the entire agpl3 license a while back. You can argue for both GPL and BSD that they are freer than the other. In GPL I force you to be GPL compatible too, so that is a restriction. But that restriction also creates more freedom. There will be an exception for assets that you create yourself though (graphics, maps, sounds). (I think this is already the case legally, but it is good to be explicit)

That is exactly what it means. Currently the license is AGPL3. Which guarantees that if other people modify it, they must also make their modifications open source (and I could take those modifications and add back it to "my" distribution). See https://www.gnu.org/licenses/agpl It's annoying that the word "free" has multiple meanings in English, gratis and "libre" (freedom). Aphelion is free as in libre. This also means people can enter a zone with custom clients. (this is why the networking protocol is very different from continuum's). An extension of this is that while we will probably provide some default services (such as password authentication, directory, etc). You could replace all those services by your own. This is also reflected in the policies those services will run under. For example the password authentications only performs bans when you abuse the password service itself (denial of service, etc). Bans for cheating, swearing, whatever, will never happen at the password service. At the moment, we have not released anything because we would not want to disappoint.

You asked jabjabjab directly, I am not going to answer for him. Your last post is very offensive, you could try to tone it down a bit. Secondly, browse the forums of phoenix and see how I have tried to contribute. I started working with jabjabjab on this before phoenix was announced. Things are moving this slow because I have a job in which half the time I do the same kind of work as I do for aphelion. I work on aphelion in my spare time. Usually 6 hours a week at most. I am not going to stop working on it because someone else might complete a similar project before me. And as far as I have read (but I could be wrong), phoenix is going not going to be FOSS and it will be dependent on a single person. This is not a bad choice, it's just a choice I do not agree with. My number one principal in this project is that there is no central authority/distributor/developer/ban hammer/etc. This is reflected in the plans for the supporting services (like user authentication) and the copyleft.

Outlaw you sound a bit manic. We are not competing with phoenix; I am not assuming that any existing zone must use aphelion, they can do whatever they want; I want to create a platform out of my own interests, a decentralized platform in which every part is free and remains free (copyleft, such as agpl).

that was in reply to you going on about "plausible", it was not about http://www.subspace.co/topic/25999-subspace-java-client/page__st__340#entry285405 I could have picked something different than aerodynamic. Such as having lots of transparent windows in a spacefight.

And all spaceships should be aerodynamic! Anyways to answer testtube, we are close to being able to fly around with each other. I could achieve that within a day, but that would just be crap code we would throw away a week later.

3. The intention of aphelion (the java client) is to be able to support everything continuum has to offer. However it does this by breaking compatibility. Meaning you need new software, have to convert settings (which could of course be done by a tool). But you will be able to have all the same gameplay. The current state is that the major parts of the multiplayer simulation logic is done. Right now the actual networking is being implemented. The way the networking is going to function has already been planned, so that part is mostly about actually coding it. The simulation and networking differs a lot from continuum, from a technical standpoint. We also already have some stuff like .lvl loading (same format as continuum) with tileset. And a nice random(ish) parallax starfields that is the same on every screen and uses almost no memory. The intention is to release aphelion as open source (under the AGPL 3 license). Right now the issue is getting over a few big obstacles. I have to code some things that I really need to spend a full day on. Later on in the project things will speed up because it will be easier to get more people involved and I will able to make small steps in evenings.

https://www.youtube.com/watch?v=kQFKtI6gn9Y

Update: First version of the physics engine is done and in use for singeplayer. All integers, not even a float as an intermediary. Uses timewarps for consistency and anti-cheating (in most cases without memory allocation). Supports multiple players. I now have a complete plan for networking (for the first version). the packets are also written (using protobuf). Embedded http server is done (all the existing libraries are way to complex, so I wrote my own last weekend). This is only intended for in-game downloads and perhaps a very basic website for a zone. hah Todo: The actual networking communication (the client is already ready to handle multiple players). First version is TCP (WebSocket) using multiple sockets. Later on UDP will be added (or maybe not if it turns out TCP is good enough). Aphelion should use less networking data than continuum for the same task, however continuum has more redundancy. Aphelion would benefit less from UDP. The advantage of websockets is that a zone can run on port 80 so that it is less likely to be firewalled. It also lets you use reverse http proxies such as nginx and varnish so that you can run multiple zones on the same server on the same port. (yay for IPv4).

Heat as in Mass Effect 1 or 2 & 3?

haha, I have not played in a long time. But my annoyance with the later sets was that money became just an added nuisance. Things were mostly about exp. As you built your ship, you followed a set path most of the time. It started feeling like one of those zones that simply give you a better ship as you gain a rank.

Do you have to configure NAT? If so, maybe you could look at UDP hole punching.

Have you tried simulating packetloss?

that was what I was replying to haha. Anyways, you would also have to correct bombs, mines, etc. You would probably end up with a networking model that transers snapshots (with some delta encoding). This is what valve's source engine does, by default the server sends 20 snapshots of the world per second and the client sends 33 input samples per second. The client can modify its snapshot rate on the server depending on its bandwidth. The client runs 100ms in the "past" by default so that it always has 2 snapshots to interpolate between. Local player input causes prediction on the local player to prevent input lag.

Just to clarify what I said about floating points math not always giving the same results on the same machine (I was not talking about randomness): The x87 subset (of x86) has floating point instructions in 32bit, 64bit or 80bit. What might happen is that your 64 bit floating point may get temporarily converted to 80 bits in a cpu register, when this happens you may end up with different results than if it had stayed 64 bits. This depends on how your compiler optimizes things, this is why using "volatile float bla;" in C should rid the problem. The real fun begins when Just In Time compilation is used, in that case the optimization might be trigged during run-time, but it might also not be. In that case you could call a function twice with the same arguments and get different results. SSE2 (which is newer) does not have 80 bits floating point instructions. Bak- actually run into this problem in discretion. The thread is on ssforum somewhere. In aphelion I replaced sin() with an integer approximation because it supports a huge number of rotation points. If you only support a handful of rotation points, you could compute the sin values on your own machine and place them in a lookup table.

Wouldn't rounding at 4 decimal places (in base 10) have different effects on the precision depending on the magnitude of your number? For example, a single precision floating point can represent every natural number between -16777216 and 16777216 inclusive (2^24), but after 16777216 natural numbers start to round: ((float) 16777216) == ((float) 16777215) // false ((float) 16777216) == ((float) 16777217) // true And that is without any decimals. (double precision is able to represent natural numbers up to 2^53 inclusive)

Becareful with floats in such a model. In a lot of cases, floating point math is not consistent across different systems. It might not even be consistent on your own system (like when your instructions are *suddenly* optimized by using CPU registers which may have more bits, ex 80bit float point in register, 64 bit floating point in ram). This can usually be fixed by a keyword (like "strictfp" in java, and "volatile" partly helps in C), compiler flag, or by not using floats for the networking/physics stuff. In Aphelion we use use integers (no temporary casts to float) for the networked server authoritative physics and floats for the graphics/view.

The issue is not that some people know how to cheat, the issue is someone releasing a tool so that anyone can do it without any knowledge. This is the same issue that DRM faces, and also why it keeps failing.

I have not bothered looking at the binaries of continuum, so I am just reposting: Someone suggested part of the reason the source was not released was because of legal reasons? It was even suggested there is not a whole lot of source to release, that continuum is mostly a bunch of assembly hacking upon the old subspace client.

done

short term todo: * finish test cases (and debug) the current physics/simulation stuff. (currently only movement & warping) * convert rest of aphelion code to use the new physics engine * networking for the above (server,multiple players,yay) * weapons http://i559.photobucket.com/albums/ss31/XDreamersMS/Continuum/SubspaceTitleSpin.gif