pandacoder

@'Randoyes': > @pandacoder Thats cause the progress has only been shown and open to the people in the Atlas discord. Aka, testers only. That's what we call "not gonna happen".

*squints* *pulls out binoculars and squints* *pulls out electron microscope and squints vigorously* I see about as much progress as there is a chance for it to live and be closed source. You say we will be able to run it in full screen mode, but will we be able to run it at all? You've posted 0 updates.

@'c0ke': > I'm not going to comment on "make everything public" gate, smh. Seems like you just did.

@'Zynato': > @'GalacticGlum': > > > Will Atlas be open-source? I'd love to play around with it. > > That's still to be decided, and to what extent. Large parts of this are dependent on unannounced features (such as the entire engine being built around plugins, and several other pretty cool things). Overall, I know that making the engine accessible to external development is important, and that's one of my high-level goals. My largest concern with just flat-out open sourcing everything is abandonment: if it's open sourced and I can't continue developing it, who else will take it on for further improvement and put in the money to maintain the development infrastructure? Many, many engines here had the same fate, and I would really hate to see that happen to Atlas. > > @'Zetasis': > > > So any eta on when this might be available? > > As soon as I can get it complete! Don't have any other dates right now. That flies in the face of logic and precedent. Eclipse Origins is alive because it's open source, based on open source engines (Mirage Source). Perhaps not every splinter engine survives, but they don't need to since most of them are specialized customizations. XtremeWorlds is another engine based on Mirage Source, but it's closed source, and also **very** dead. And that's the great thing about open source, you can have an official maintainer, and community maintenance. If the official maintainer ever steps down someone else from the community will naturally step up to the role, or replace the engine with a derivative. With a closed source engine you can only have official maintainers. The only reason to have closed source is to clutch your dependent users by the balls. MonoGame is a perfect example of something started by the community, maintained by the community, and open source.

Would do about what exactly?

Bindings are used to map methods and whatnot from compiled native binaries into whatever language you're using (typically non-natively compiled languages such as Java or C#). C++, C and assembler to my knowledge can all share native dependencies written in any of the three languages, but that's the extent of my native-compiled language knowledge (everything else I use is run in some sort of VM). In the case of this it's making calls from managed C# space into unmanaged space owned by the GLFW3 native binaries, though I'm pretty sure you can write managed C++ (Visual C++) code as well, but you'd still need the bindings to make the language-external libraries accessible from the C# space, which in the example of this binding also has to translate types by telling the marshaller what kind of memory the GLFW3 library has so it can handle it properly. An example of not needing to create bindings is between C# and VB.NET, or Java and Groovy (and I think Scala too) since both groups of languages share VMs. I'm pretty sure you cannot write a .NET binding for a JVM library though. The difference between a wrapper and a binding is that a wrapper provides additional functionality that a binding would not (such as extra methods). Wrappers and bindings can be mixed though, and that's actually what this library actually is (though it's almost entirely a binding). Another example of a wrapper-binding is SFML.NET, which adds stuff that is not purely mapping external library functions to .NET and facilitating any data translation that might be necessary. Each component of SFML (the C++ SFML) is also a wrapper of sorts, and it does no binding. The whole of SFML, and probably even some portions of it are also classed as frameworks.

tl;dr: To address the points you brought up/questions you asked: 1\. It is a windowing/context management library for GL on the desktop, mobile devices use GLES and don't need this. 2\. I wrote bindings because it's stupidly difficult to do (even with GLFW3 [in C++], C++ and C# experience) and it's a wheel that is a horrendous waste of time to have to reinvent. 3\. To my knowledge this is exclusive from WinForms and cannot be used with it. Pretty sure that also applies to WPF. More in depth: It's a desktop windowing system with some OpenGL and Vulkan context management support - things that aren't necessary on a mobile device (which to my knowledge have no Vulkan support yet, and use OpenGL ES which is a subset of the OpenGL API). The reason behind making the binding is because even writing these bindings have been a chore. GLFW3 is a C++ library and lives in unmanaged space. It's taken a lot of research, time and trial and error to even get the binding as usable as it is (still not 100% since none of the Vulkan stuff is really supported beyond the "isVulkanSupported()" binding. Given that I originally used GLFW 2 and 3 for C++ applications, and know both C++ and C# I'm capable, even without full knowledge of C#'s Marshalling system, to be able to research enough to make the correct guesses needed to make it functional, this isn't something I would expect 99% of the people here to be able to do. It's just leg work that doesn't need to be redone, and I also dislike the other (less complete, and from testing of my own code which I wrote after examining the structure of the other) binding's structure, and think it should be true primarily to the GLFW API, and not to the C# style guidelines because it would make it much harder to use all of the documentation and examples on the internet that are almost exclusively in C or C++ when you need to translate everything to C# "style" code (case differences for example). This project actually is just a very small part of my original overarching plan, which was to go and rip OpenTK to shreds and make it conform to the actual C/C++ API to allow, like with this, code to be reused without much change from C++ to C#. Unfortunately though, I'm really lazy and don't do much in the line of game programming anymore, but if I were to I would just write everything in C++ because I can and there's no need for me to creating the unbelievably massive binding for the entirety of the OpenGL API. Eventually I might get to that part of the project, but it's extremely low on the list of my priorities, and OpenTK still works, even if it adheres to C# style guidelines rather than the API it binds. As far as I know, it is completely distinct from WinForms, since WinForms is window management and GLFW is window management. While this is a guess, I'm 99.9% confident this is the case.

Pushed another commit fixing string encoding issues, now UTF-8 is supported like it should have been from the get-go. Github: [Commit c2ec20c: Fixed string encoding issues, normalized code style](https://github.com/lodico/glfw-net/commit/c2ec20ce4a3e6dac9ea816ee793575ff8b30f1b2)

Pretty sure it's also C++, at least the desktop version and server.

Honestly TMW has been putting us to shame for years, but besides me I think only a handful of people in the Mirage-descended communities knew about its existence.

glfw-net is now in beta development for glfw-net 3.2\. This update is to bring it up to spec with GLFW 3.2 and is also marking x86 as obsolete, as unless someone else fixes the issues I was having with it (AccessViolationExceptions on cursors and gamma ramp) it will not be supported, and I have actively removed the x86 build configuration from the solution. GitHub: [glfw-net 3.2 update development branch](https://github.com/lodico/glfw-net/tree/update32) I will be testing/correcting the Vulkan API externs I added to the source starting sometime this week when I receive my GTX 1070, as my current GTX 560 Ti was not given Vulkan drivers by nVidia (rendering me incapable of testing it).

I think he means that if the Eclipse community doesn't have a working mobile engine already it never will.

Such preview very amaze.

> I love Brittany Venti

@'Chief': > It seems odd to me that you would use only some new ES features, like classes, yet omit others, like let and const. You've also got a pretty high cyclometric complexity in some of your methods; I'd have broken those up into a few functions, personally. > > All that being said, you did say that you're not a JS developer, so I'll give you the benefit of the doubt. Eh, cyclo isn't JS specific though. I'll give him the benefit of the doubt with GLES though, mostly because I don't know GLES.

I'm too lazy to take a picture of mine, but it's a '15 CR-V. This is the closest to a picture you guys will be getting, sorry my legs aren't sorry. 

You linked to this: http://imgur.com/rJDnwOG which isn't the image, it's a webpage. You need to get the URL of the image on the page, which in this case is: http://i.imgur.com/rJDnwOG.png

_tl;dr Passwords are hashed, not encrypted (much better than if they were encrypted), if your password is longer than 10 characters, is at least single-case alphanumeric, and you aren't being singled out for password looting by Yuko, you're more than likely safe._ So to clear things up so people are a little less panicky: the breach, assuming she still has the data, and that she's willing to invest the time and money into cracking passwords, if you have a password that is 12 characters or longer and not easily guessable you're more than likely fine. First of all to correct one dangerous (if you ever enter cyber-security) misconception, the passwords are **NOT** encrypted. Encryption is **_almost_ useless** because it can be **decrypted**. They aren't plaintext though, so don't panic and run yourself into a wall in fear. While it is pretty weak (to attacks that would only help her gain access to your account, not your password and is a more or less unrelated and irrelevant topic), the passwords are hashed with MD5 and salted. The procedure stock MyBB uses to secure your password is by using MD5 to hash what is more than likely a user-unique salt, which is then prepended to your password and then that new string is hashed again and this is put into the database. The reason these hashes, even when using MD5, are relatively secure are because it's not possible to extract the original text from the hash using a key – which you could do if it was just encrypted. What is done is that MyBB stores the hash in the database and when you attempt to log in, it will go and compute the salted hash based on the password you provide it and compare it to the hash stored in the database. If they match, you are allowed to proceed. The salt prevents her from using a rainbow table (pre-generated hash lists for massive amounts of strings) because the introduction of the salt (which she has since it has to be stored in the database) makes it so she would need a rainbow table for each user, so up to 50,000 users. Since rainbow tables can be massive (in the gigabytes), 50,000 unique rainbow tables would be an absurd size, this is plunging directly into the territory of hundreds of terabytes to store this information -- which she does not have and would need to generate, which means the method of password "procurement" would just be brute force generation of any and all possible passwords. Now onto the good news. If you're password isn't an easily guessable piece of crap (i.e. "password") you are probably in luck, especially if your password is 12 characters or longer, and especially if they are alphanumeric, mixed case or contains symbols. While I doubt she has it or could write good enough code to automate this, and assuming she has and uses this, the Titan X is one of the fastest hashers in the world, running around 17 billion hashes per second. I figure using one of the "worst case" scenarios is better when discussing level of risk. Now onto more hard numbers and math. **Bad passwords first.** If you have a numeric password it has a complexity of 10 (10 digits) per character, so for a 10 character password, it would have a complexity of 10 billion (complexity 10 ^ 10 characters). It would take less than 1 second for her to crack your specific password alone, assuming she knew it was 10 digits or less and only numbers. An entirely lowercase password (e.g. "password") has a complexity of 26 per character, so for a 10 character password it would have a complexity of 141 trillion – 2.3 hours or less to crack. Lowercase + numbers is 36/char, so at 10 characters it would take up to 2.5 days. **Better passwords now.** Mixed case is 52/char, at 10 characters it would take up to 99 days. Mixed case alphanumeric is 62/char, at 10 characters it would take anywhere up to 1.6 years. Now if you have a mixed case alphanumeric password with symbols (which MyBB allows) she'd probably need to have a character set of around 70-80 characters, so around 70-80/char, yielding a brute force time between 5.3 and 20.1 years for one password. As a recommendation, if your password is less than 10 characters, change it (to something longer, please). If your password is weaker than lowercase + numbers, change it to be at least that. If you think she would target you and try to get into your account, change it. If you don't apply to any of the preceding groups you're probably fine, but obviously changing your password is never a bad idea, but this "breach" isn't something to be overly panicked about. For reference a lowercase + numbers password at 12 characters would take 8.9 years to crack in the best case (for you) scenario, and if it's 16 characters you're probably safe with a best case (again for you) time to crack your and only YOUR password if she targeted you, of 14.9 MILLION years. If your password is mixed-case alphanumeric and your password is 10 characters or more it will take at least 1.6 years to crack it with a single Titan X, assuming she even has one and wrote the code to automate this. You probably needn't bother changing your password. **Ending tidbits** Being realistic, I doubt she has or could properly create any set-up to efficiently crack the passwords (especially not all 50,000 of them). A Titan X which I based all of these numbers on, for reference, is 4 times slower than the fastest GPUs for hashing, but in practice will not hit the hash rate of 17gH/s. All of my numbers have been with that 17gH/s number, so in reality the time estimates will be much higher, perhaps even several magnitudes slower than what I mentioned above.

I'll throw my two cents in: BitRocket is a torrent client for OSX. I do not recommend changing the name, least not to something that's taken _and_ linked (directly) to torrenting.

@'Marsh': > There is nothing wrong with that coding style at all. It is actually fairly common. I specifically did not use the word "wrong", only "interesting" and "consistent", and I have not seen it used in any well-supported open-source Java projects. @'Marsh': > There is nothing wrong with that coding style at all. It is actually fairly common. > > Also changing everything to public seems like a bad idea… Things are private for a reason. I specifically said the class itself, the constructors and the methods, which from looking at the code I can see no good reason for any of them being package-private. @'PeRV': > @'pandacoder': > > > […] you should change […] > > I am familiar with Java coders and their obsession with the "public" keyword. When you stop using it as much and understand what kind of scope no access modifier gives you, not only does your code look less intimidating, but also: > > @'Marsh': > > > […] things are private for a reason. > > The class is used throughout your project. No package importing necessary since it defaults to package-private (default package). There's a reason why Java's default access modifier is not public, but nobody ever stops to ask why. I'd say it's because libraries made using no access modifier are lighter-weight and more casual on a per-project basis. It's like when your professor assigns a project where you use her helper class. You don't import a JAR necessarily. The simplest way is to just drop in their helper class' class file. If it has a package namespace, then you're going to import it. If not, you just start slinging away. The informalities are easier but less "corporate." > > @'pandacoder': > > > […] change your formatting so methods aren't starting on the same line as the end-bracket for the method before it in the code. > > I only do this for methods that are overloading each other. I could spread them out or put proper spacing in there, so I'll do that actually. They're still going to be back-to-back because it's part of this style guideline I follow, but I'll add more appropriate spacing because they'll be easier to read and plus it's also part of that same guideline. - Having been programming in Java both educationally and a hobby for the last roughly 6 years, and professionally during the last 3 years for various different purposes, I am acutely aware as to what the access modifiers do in Java, and use package-private instead of public where it makes sense or makes an actual difference in the data. - That class is not being used throughout your project unless your entire project is in a single package, and that would be poor design. - Unless added to a package the class cannot be used outside the default package, which goes back to the single package idea (poor design, except this time it's somewhat worse since its the default package). - I noticed that it was for only overloading methods (although by definition those read methods are not overloaded, so technically you did this for overloaded concepts), so I didn't say it was wrong, just interesting as I have never seen that done before, and at least for me makes it a little bit more difficult to read (I'm not advocating for copious amounts of whitespace, but putting the methods even on the next line rather than the same like as the closing bracket makes it more readable, but to be honest if the class works flawlessly there's really no reason for anyone to ever need to read it, but this puts slightly more pressure on you and makes documentation not possible in a neat manner). - Making specific things private, protected or package-private in the interest of security and only making what is needed to be public public is good practice. That being said, this class is a utility class, and unless the fields were made public I do not see a security issue resulting that stems from the code rather than the JVM itself. - I can think of many reasons as to why one might need to access this class from outside of the package, for example sub-classes of an abstract I/O class that were moved into a sub-package (sub-packages are treated as entirely separate packages and are excluded from package-private) in a neatly laid-out project. Another more important reason is so that dependencies are obviously separate from other code, which helps to avoid naming collisions as well as maintain clarity as to what came from what. This point I could actually concede, however, if the class was actually documented to make it obvious that it is not part of the project it was included in. - Ultimately if you only want this to be usable within a single package, then really there is no reason to adhere to any library code standards, and you can disregard everything else I said (although I do recommend adding documentation even if you don't want to change visibility, and in the class's documentation you should specifically mention your rationale for the package-private visibility). @'Genusis': > Also to add the fact that making code private that should be rather than making everything public adds extra protection for your program. The public everything idea is one reason why Java is red flagged as a huge security hole. It is also a reason why Google when making android wanted to private functions to prevent known security holes from occurring. My advice is to do what PeRV did Panda and learn how to use modifiers how they should be and the reasons behind them if your going to program in any Language. @Genusis: While I am by no means an expert in any language, access modifiers are one of the points I put more emphasis on than almost everything else, specifically because when I write code that is meant to be used by others I have absolutely no faith that the other programmer will not do something they were not intended to do, so I use things like private and package-private liberally, where-as I use things like protected and public rather sparingly. Public, more than any other modifier, is meant for things that are immutable, or meant to be mutable without posing any inherent risk. Changing what I said to be public in this class would not pose any risks.

In the interest of learning, you should change the class to public, all of the constructors to public and all of the methods there to public. Should also change your formatting so methods aren't starting on the same line as the end-bracket for the method before it in the code. That being said, despite your code style being… interesting... it is consistent, and consistency is good. Keep up the good work.

It seems as though the forum restructuring has resulted in some misunderstandings regarding what goes where. The one caveat to the programming board is that any questions relating specifically to an official, or formerly official Eclipse engine do not belong in it, they belong in the appropriate Eclipse Engine forum, which is more than likely the [Eclipse - Questions and Answers](http://freemmorpgmaker.com/forum-124.html) forum. I have moved any of the misplaced threads into the [Eclipse - Questions and Answers](http://freemmorpgmaker.com/forum-124.html) forum. As a note, nobody is actually in trouble. I would greatly appreciate any effort to ensure new threads that don't belong in the programming board aren't made again so I don't need to move them. Thank you everyone. If you have any questions, please ask them here.

@'Growlith1223': > If you're not going over the max value of a contructor then there's no reason to use the larger constructor, giving way too much space for a number that you planned to never go higher to begin with is just plain lazy and dumb, as i said before, you want to use higher numbers, then use a Single then and be happy with the worst of both worlds! Again it has nothing to do with what /you/ plan on doing, it's about what /other/ people who can't edit the source plan on doing. It's to prevent a needless recurrence of this thread, because I guarantee you if anyone runs into the issue a few months or years down the line the first thing they won't do is look for this thread.

@'Genusis': > if you have lets say 200 users and use to use a byte but instead switch it to a long you now are using 800bytes of data. compared to 200 if you use a integer you only use 400bytes of data. This goes for many things within ANY Language. It wasn't solely meant for just mirage source based engines. Besides if your learning to program you should learn to do it in a proper way regardless of the source or outcome. This way whenever you decide to switch languages or go farther you already have these concepts in mind. I quite frankly do not think anyone is really learning off of this source base anymore, and the only person who would get any benefit would be the person who changes it: 1 person. When a single byte on a hard disk costs roughly US$0.00000000005, it's honestly irrelevant. The benefits still out-weight the costs, as likely the person who changes it will have read this (and if they didn't it's a moot point) will have therefore seen your explanation, and would have learned the concept you are attempting to impart, but when this is going into practical use it's no longer about education.

@'Genusis': > So go with a integer. yes there will be a slightly decrease in speed but its worth the size. Given how ancient the code base is, and therefore an ever decreasing number of knowledgeable maintainers, there's absolutely no reason to go for saving space at this point, it's a matter of ease of future use. I don't know how much this doubling would be, but I don't see it adding more than 16 bytes per user. Assuming it adds 16 bytes per user you would need millions of characters before it makes any noticeable difference. That being said changing this for the users/characters also means it should be changed for things like items, and whatever else. Assuming an average worst case scenario of added data of per se 32 bytes per object, you would need roughly 32,000 objects (characters, items, etc.) before it changes your data consumption by even _1 megabyte_. At this point in time, that's infinitesimal, and well above the average requirements for any of these games. In slightly-shorter-words: There is absolutely no reason to use anything other than longs if you are enlarging integer data types, as the gain in ease of maintenance or usage for future users or maintainers far, far outweighs the pidly cost in data size. Nobody here is making a game that will have millions of objects (I'd be surprised if any hit that 32,000 mark I mentioned earlier) that will be affected by this change, so the increase in data consumption will be utterly meaningless and _thus a moot point_. **_tl;dr: Take the 32-bit processor speed and software usability gains by using longs instead of integers, and don't look back._**