panda

Cool, will take a look at them. If we write any code to integrate any of this stuff into the base engine we'll include proper attribution -- I'll make sure we ping you to find out the attribution details if and when we do this. Edit: Thank you for putting this out there so that people can have a chance to learn from approaches to programming besides that of the dev team. Even if things don't make it into the engine at least people can learn from them.

The exception is rather self explanatory: your packet class doesn't have a parameterless constructor. You either need to provide one, or you need to follow Ceras' documentation for using custom constructors. All of the non-abstract packets in Intersect provide parameterless constructors so we have not done anything like this.

You delete or modify the line of code that causes the rubber banding in the server's packet handler for movement. Caveat is that this will probably allow speed hacking (if you outright delete it, or modify it incorrectly). Less resources probably increases rubber banding, but there could be a lot of other factors.

Username/character names were already up to 24 characters, and names have to match FieldChecking.PATTERN_USERNAME. Change that pattern (or the method that calls it) to allow other characters or longer names.

It will always be free. It is already open source, and future contributions will go into that open source repository.

You need to do what the client does (send data) like Joyce said. In Beta 7 (tentative release is end of June) I plan to rework the netcode so that we can check the server status via unconnected Lidgren messages. No response would be offline.

1a. You can simply use the exact commit that the patch is for rather than constantly updating. If you are going to constantly update, you need to either wait for patch authors to update their patches, or learn how to resolve merge conflicts yourself. Patches being incompatible with each other? That's going to happen no matter what. Plugins can be incompatible with each other too. If you are referring to git not allowing you to patch, that's because the documented commands and options on Intersect's documentation website only cover the absolute basics, meant for people who had never interacted with this stuff before. If one is actually ready to resolve a merge conflict though (requires an extra argument on git am), they would look for git's documentation for the command and find what they're looking for immediately. 1b. Version control software is complicated, but it also does a lot of the work that you would otherwise have to do in order to accomplish the same tasks. It's something to learn. Having to resolve merge conflicts is frustrating, sure, but it's also inevitable if I want to be collaborative. Having to clean up after cats is frustrating, but it's inevitable if I have cats. Having used version control for years and having not used version control for years, I can say with certainty that I prefer the aid of git to trying to manage my code like I'm writing an Untitled-Final-Paper-Final-Draft-v3-DEFINITELYTHELASTDRAFT (2).doc. 2. Plugins and extensions... not an easy system to write! Most of the code isn't well documented, you're right. But most of the documentation that would be added will still not say "here is where you make your changes for X feature that you want", that's something that needs to come from experience, which is the result of investing time. A lot of it. You're not forced to use the patch system. You could make modifications by yourself instead of getting low-cost if not free help from other users. 3. Monogame is actually not extraordinarily limited. It just doesn't plop down what you want in front of you without research. It's got a lot of barebones functionality, it is a framework after all. JC writing some rendering code using VBOs is proof that it really isn't limited to just "blit this sprite here". Since JC replied in the middle of me writing this I'll respond to his post now. Like I pointed out, VBOs have been used, shaders too and more can be added. In case anyone was thinking "SFML" and "advanced functionality" in that order without "does not provide" in between them is sadly mistaken. SFML is horribly limited and very non-performant at the scale that something like Intersect needs. The "this is not advanced" is literally in the first letter of "SFML" which stands for Simple. What SFML allows is for you to interface directly with OpenGL in order to do all of the VBO and shader magic needed for performant code for intensive drawing capabilities that it doesn't really give you the ability to do itself. With Monogame you don't have the ability to use OpenGL directly, but it does give you access to VBOs and shaders so it's not like it's hanging you out to dry. But both of those things are complicated features and by their nature are difficult to use. Having used both of them in OpenGL myself, I would argue that anyone arguing that VCS is too complicated is in for a reckoning if they thought "advanced functionality" was anything less than "complicated". 4. Personally, I think the code base needed to be improved further before going open source. Realistically speaking though, there were 3 developers with access before. All of us have jobs. All of us have lives. Our jobs and our lives come before working for free on a code base that you are not being forced to use. Many of the forum members were close to rioting because the source took 3 years to release after I joined, and I joined to speed it up. Ironically, my joining probably slowed the source release down by a lot, but then the claim that it was rushed (because the code was a mess) would have been much more true. 5. There are rules. Users are supposed to abide by those rules. Don't complain that people are doing their jobs if you don't like the rules, you should get public support for amending a rule instead. 6. If we were in the business of selling licenses for the code, the license would be more restrictive not less. Notably: Instead of being allowed to compile the client and share it without source code, and being allowed to share the server/editor with their source code provided as well, you would only be allowed to publicly share a compiled client and you would not be allowed to share the source, period, or that would undermine selling licenses. 7. There are 0 engines with advanced features that are truly non-programming engines. You might think "how about Unity or Unreal?", well: they're both programming engines. You can drag and drop all you want, but at the end of the day for any real customization or advanced functionality someone has to write code. Whether you buy it pre-written, write it yourself, or pay someone else to write it custom for you, someone wrote code. Even doing advanced things in Game Maker required at least basic scripting (or spending eons in the visual code editor). 8. You don't have to. 9. No documentation on a code base this large is going to tell you what you want to know before you even know what it is you want, at least not when it's written by 3-4 people over the course of 5 years in their free time. This would have made a fine end to what is ostensibly a negative rant. The engine does need a lot of work, you're right. And thank you for all of your contributions towards improving the engine.

And I'm pretty sure this has always been the case, it was never on by default. @Beefy Kasplant Slightly worse... there wasn't an option to turn it off at all before Beta 3, and in Beta 3 the option was added and it was off by default: https://github.com/AscensionGameDev/Intersect-Engine/commit/bd7b3304e745566a7d81a693850b5279df24be69 That said, the Z-Dimension option has been off by default since its introduction in March of 2017, and it doesn't even show up in the configuration unless it's explicitly put there, specifically to hide a feature that's so costly for performance.

@EduKrowlley This PR will automatically generate keys on build: https://github.com/AscensionGameDev/Intersect-Engine/pull/204 This is based on the development branch, and so if you are already basing off that you can use it by rebasing on top of the PR's branch, or wait until JC has a chance to sit down and review the PR and merge it into development. Intersect.Utilities is effectively dead, and I won't be modifying that to manually accomplish a job that the build scripts can handle automatically. It's configured such that for Release builds, keys will only be generated if the private key does not exist (public key is technically a subset of the information in the private key, so it can and will be regenerated from the private key, but not the other way around). For non-Release builds, keys will be generated each time Intersect.Network is rebuilt. Keys are stored in build/<lowercase configuration name>/keys (e.g. "build/debug/keys" or "build/release/keys"). I highly recommend each time you update the version with a breaking change in a release build that you also delete the keys so the new client/server pair has a fresh set of keys. Release build does not wipe the keys each build in case you release some bug fixes that only requires a modification to one of the executables.

Would be way better if this was in a fork or something so we could easily see the diff on github.

Yes, it is. But like JC already said, we can't stop it from being detected as a false positive.

The "Run" property added to EntityPositionPacket and EntityMovePacket, and the "Running" property added to Entity are all being used as booleans. Why are they just not a boolean?

There's no level downgrade system in the engine. Look at the TNL and related variables and functions in the Player class to get an idea of where this might need to be implemented.

Launch argument solves a different issue though?

According to your hastebin... Unless you portforwarded manually, you need this on.

Remove them from MonoRenderer.

Unfortunately you did not provide us enough information to help resolve this for you. What code is the CS0152 error referring to? Please provide a complete screenshot of that code and the surrounding code.