ArchaicOokami

> Eww…. lidgren > > If you're gonna do networking, im gonna save you the hassle and give you some advice. > > 1.Use Async. Basically when you create Event handlers to handle incoming data in .Net by using the .BeginListen or the .BeginReceive() methods, you're gonna use handlers and the method use is async. > > 2\. Serialize your data. > > 3.Do not make responses so your data doesn't get jumbled. Baiscally what this means is. When you want to make sure your data has completely sent before receiving another packet, DO NOT make the client or server reply to the other saying that the data finished reading. This doubles latency and creates lag, often a mistake with those who are new to TCP Socket Programming. John (GerneralAwesome) Showed me how to fix my mistakes here. > > 4.Use Packet Headers. The first 4 bytes of your incoming data should tell you how big the incoming packet is. THIS is how you split you data to make sure it doesn't get all mixed up in the stream. The next few bytes could be your data type, and every byte after that is the data to handle. > > Keeping these four things in mind while programming a network will make it run efficiently. Thanks for the info.

> I think he's referring to the source being written in both VB and C#, which is understandable for anyone who wants to modify it. But yeah, what you said is also true. Yes The source was written twice because it is open source for anyone to use modify rip etc. > It's not bad code per say, but I do have a few comments on it all. > > > > IO > > > >! The functions for checking for directories and files are already built into the .Net framework, and the GZip methods are almost nearly copy-and-paste code examples from MSDN. > >! I could be wrong, but from what I saw, you wrote out methods for saving and loading data similarly to the way most Eclipse engines do. If that is the case, I will say that it's not always beneficial to have methods as this. Especially so if you're going to frequently change your class's structure. > > > > Buffer > > > >! Most of this is stuff you could do in a few lines with a binary writer and memory stream. You go more in depth, which is cool. But if you want to post this as a utility, then eh. > > > > INI > > > >! Who even uses INI files what with the dynamics of things like XML? > > > > Network > > > >! It looks good, but it's not asynchronous good in that it's not. On the IO, I know those features are built in, if you look at the source u can see what the code in those blocks are, its just a wrapper over a check and perform as a quick to call function(Keeps code looking cleaner, without much of a performance difference) and yes it does handle files like eclipse does using serialization. Of course you dont have to use them, it would be higher performance not to, they are simply there for the lazy as in my network code you have the option to presize it to the max size so you save on REDIM's, but you dont have to(take the slower lazier way out). As for the GZIP, yeah they are copy paste but modified and posted into reusable functions. They arent complete systems, just placeholders for now till i put in the heavy work with my FileStream. ^^^ I should also note, Serialized Objects will make it harder for inexperienced people to break into your files (should u be making a game) and modifying them to hack or stealing them for their own game etc… The Buffer is work meant to be used with the Network. Im aware you can do that work with memstream and binaryformatter etc... It runs in a structure/module method format for keeping as high performance as possible while using a network buffer. The Ini isnt a real ini system, General StreamReader/Writer functions are about the same speed if not faster than XML handeling though it is nice for people upgrading projects from vb6\. This code work was inspired for making upgrades to .net from anyones game engines as easy as possible. (Note I do plan to add XML and SQL handlers in there down the road as well as functions for converting from 1 to another) The Network isnt even finished either. Its usable but it doesnt have as dynamic of control as Id like. It needs IOCP handler(as an option) with handeling incoming packets, and it does run async on the listener thread. Being that most anyone intending on running these programs will be on a computer with at least the ability for 2 threads(at least for hosting servers) I figured itd be okay to keep the listener on that. If you are talking about Async PacketReceiving(like VB6/JCs.Net engine have broken receive packet systems async) yeah, that is just terrible imo. Slow, performance heavy, and makes it easier for someone to spam packets and slow down a loop. ___________________________________________ Do keep in mind, this is a new SDK I wrote, its being written via C# and translated to VB.net, and I do need suggestions on new features, or changes, testers etc. I will keep developing onto this trying to keep features as high performance as possible as long as i have fan base willing to work with me on reporting things.

@ Marsh Not really, the top few commands are, but handeling saving and loading an object doesnt serialize the object, which youd want for converting to byte arrays to be used in network or streams. @ Thomas Slusny This library has the availability for a vb.net coder(no c# experience) to both learn how to convert some stuff to C#, as well as should they want to modify how the functions work or rip the functions directly to their app they have the ability. The C# of course will be slightly more optimized but the VB edition again is mainly for the modifier.

-Snip-

Sorry, this double posted from lag, can a moderator or whatever please delete this thread?

> I hope you get some help with this and the community can bring a 2015 engine I have a library built with some flawless systems in C#, as well as im pretty advanced in .net and with sfml myself. I can assist if he asks me for it. By the way, Matt… 2.2 should only need minor fixes(changing the namespace for some calls cause they moved the functions to System) The literal coding shouldnt have changed at all, even though theyve modified some of the old functions to not use their own methods but make calls to OpenTK to produce the same results but better. Also, if you want to make the SFML libs to be 32 or 64 bit so they never need set separately, i have fixed the libraries using the latest of everything and recompiled them all into 4.0 libraries instead of 4.5 or 2.0(as the old libs were). The reason 4.0 is because untill 5.0 comes out, there will still be a decent amount of people wanting backward support to XP... once 5.0 is released though, its crossplatform, and everything i meen EVERYTHING possible on XP can be achieved on linux(and more for free) with the same exact reqs so... thered be no excuse to use XP at that point nor would people be held back for .net :D

if i remember correctly that shouldn't be a problem as long as the map editor had a scroll bar on the bottom of the tile sheet(which i think that engine did but i havent used in it a while so i dont know for sure… im on linux so its a bit of trouble to try and check)

Your better off with tcp. Theres alot of data that you wanna make sure is sent and received on both sides and trying to work around failsafes and ensuring the data is received udp can be a pain and more work in the end. As well with udp your relying location of servers rather than direct connection which can be a big problem if people arent close. ALSO theres the security holes that come with UDP. Either you rely on a player being honest in sending their index to identify them, or your relying on them sending an ID assigned by the server which can be kinda random, or the IP of the user. In any of these cases that arent IP, you are risking someone else catching a players id and spoofing them which can result in hacked player accounts… or you are basicly having the client trust their ip wont be stolen or attacked by another user that can capture the floating packet.

You have to create a render surface on your menu, as well as try changing the target from frmmain to your menu as well ;)

EO uses byte data, which yeah can be grabbed but doesnt do much good to play with, and the use of the enums meens that if they try to get packet id's they are only numbers. Reordering the enum data in a closed source app(where no one else has ever seen your order) can ensure no body knows the exact packets ids. As far as trade hack and many other issues though, its not because of the network and they dont exactly need packet sniffers and hex editors to do the job. Eclipse Origins was built in a mannor that relys on the clients data to be sent honestly sometimes, which meens editing active data (which is data inside the actual app not the packets themselves) using something like cheat engine does have its ways of modifying some things which the client formats and sends on its own after tampering. About the relying on client to be honest, this is in such cases where the client can take a little of the work doing some math and checks(such as if theres a block in the way or not… i believe thats fixed but its an example) and then lets the client handle okay we cant move, or we can... and then the client after the check decides whether appropriate to send the packet. the server, trusts the client that it did its check and came up with the space is free then skips rechecking itself and then just moving the player. again thats an example of how it would work but as far as that specific exploit, i do believe since origins came around that security was fixed. As for the tradehack, thats not exactly news, in fact its only because of security server sided like many things, where it either doesnt have a hack check(data being impossible values or a player not having the proper developer status to perform certain actions) as well as some unfinished code that ended up not performing updates on all participating players ends of what 1 player sends to the server allowing trickery... the tradehack there were a couple of fix tutorials so people couldnt scam and such like many things. Bugs even for the oldest editions of the engine sadly people still manage to find after all this time. Again, making sure your server has the proper checks though is what makes or breaks the hackers ability to modify your game.

Im cleaning up a copy of JC's engine, simplifying alot, and swapping out his systems for the strongest I know how to make(Which is significantly better i promise you.) Im also bug fixing whatever bugs my team finds… so If you are willing to wait about a weekor 2 I should have a stable base cleaned up and running FASTER than a vb6 app(This in reference to someone in the community actually a few, whom claim any upgraded project or any product you make in .net going to be slower than a vb6 app minus the ability for multithreading however.)

The answers simple it doesn't fully protect your images enough to sacrifice the time in which it takes to decrypt the image each time you need it. Also I know you might say why not load all the images into memory then if that's a issue with loading them each time. Well the issue is some people have a ton of tiles which can't be all loaded into memory as memory is not just used for your application. its used for many applications and they share all the memory in your PC up till there is none left which some will switch over to using your hard drive as temporary memory called Vitual memory which is incredibly slow as a Hard dirve has no means of speed when it comes to randomly accessing the memory needed. Also to answer another question Ahead of time the reason encypting a image is not worth it is due to the fact that their are programs out their that ANYONE can use to pull images from memory and recreate them. These are called a type of hacking tool but they are found online pretty easily. Though googles been trying hard to remove anything illegal they can find. Also GPX is just a file type name in itself. It doesn't really stand for anything and can be anything. For example i can make my map file be a .png rather than a .dat . these naming conventions are just used to help point out what they are for and how to use them in a conventional manner. This is a message provided by Genusis Time Lord!

Nonono the simple solution is open the .vbp in notepad and look for the reference of mscomtl. It will be posted as 2.1.0, change it to 2.0.0 and itll load. The 2.1.0 wont register on your computer unless you have certain updates on a win7 and up OS and getting those same updates will break other features of vb6.

> Learn the basics, I find that WinForm app development is good for learning how C# works at its core. Make something simple like a tabbed web browser (so lame I know but it works). Then pick up on some XNA, there are PLENTY of tutorials online… I mean **PLENTY**. Dont use XNA. Its a poorly made WRAPPER for Direct X, Microsoft is the makers and dropped it because THEY felt it was garbage and a waist of time… so what does that tell you?

Ive made one in a matter of 10 minutes as an attribute like stable and older engines had… if ur interested in one like them and still need on I will make one foru if u just PM me