[Development] Burning Skies: Profaned Sanctuary

[shadowman123]

Originally Posted by Korvacs

thx alot korvacs for this amazing link it helped alot

[Spirited]

Alright, back on topic: I've been busy with midterms, so I don't have much to show - but this is what I've been working on for the past few days. Account information is now being updated after each login. Account information is updated immediately after the client has been redirected to the world server (in the same packet handler so it can't be taken advantage of). If the ip address of the current user is radically different than the ip address of the previous login, my server will send an email to the account holder warning him/her of the login. Here's a picture of the message I got sent when I changed my ip address radically:



Of course, I might add fields to this later, but you get the general idea. Today, I finished login records and a management window for that. Now, when a player logs into a server, his/her recent information is recorded to a log of all successful logins. Here's a picture of my viewing window:



I'll be doing the same kind of system for trade transactions. Anyways, that's it for now. More development is coming soon. I'll be starting the World Server tomorrow. Cheers.

[Korvacs]

Not to open a whole can of worms again, but having taken a look at your snippet that you posted, alot of your comments are completely redundant and are considered bad-practice by the industry.

Comments are meant to explain why the code does what it does, the rest of the time the code should be self-explanatory therefore a comment isn't necessary and adding one is a bad thing as it makes the code less readable. Commenting things like properties is exactly as I described. Your other comments are also far too long, they should be short and too the point, no more than a couple of words/a single line. If you wish to document the code in detail then this should be a separate document for readability and portability reasons.

Also please make the distinction in your mind between documentation and commenting, if you are writing comments in your code then you are commenting your code. documenting should never be done within the code.

So I'll suggest again that you need to move to a standard for your comments, earlier in the thread you complained that no one has made any suggestions from this forum, well I'm making one now and its probably more valid than anyone else's suggestion to you to this day.

And please don't disregard this post as off-topic as it is far from it.

[Spirited]

I removed redundant comments and changed them to be more meaningful. I'm not changing the actual style at which I program. I'm keeping my style consistent, and nobody from the industry or universities I've shown this to have any problems with the way I comment code. I don't mind suggestions, but I'm done with two pages of different ways to comment code. This subtopic is over. Thank you for your advice.

Back to development: I started the World Server a few days ago. The socket system is done (meaning I've fully implemented the DH Key Exchange and CAST Cipher). I'm receiving data now. I've started managing Character Creation. I haven't made the character class yet, so I can't load anything. It's coming along. I've also started a new scripting engine that I plan on using a lot in the World Server (part of my new design). I'm not going to tell everyone everything about the design, but I will show you all a small picture of what the scripting engine can do. What I wrote is nothing complicated, and I don't intend on keeping it. It's a small example.



I can access my own libraries loaded by the server using this engine. You can probably guess what I'll be using it for (since I can compile the scripts into actions that can be invoked at any time). More development is coming soon (as usual). Cheers.

[I don't have a username]

Not to break your glass, but compiling at runtime is nothing special.

[Spirited]

Originally Posted by I don't have a username

Not to break your glass, but compiling at runtime is nothing special.

I implemented it to use it, not show off. It's part of my new design which will hopefully allow me to support a more dynamic gameplay environment.

[Spirited]

Hey everyone,

For the past few days, I've been working on converting NetDragon's "data maps" (.dmaps) into the Burning Skies compressed map format (.map). My format removes information about the map's graphics and sound data, and only leaves the coordinate tile data. I've created a window in my GUI that manages map information:



As you can see from the picture above, I can also print maps. Printing maps can be helpful for checking things like if scene data loaded properly. As you can see from my example below, I can also check elevation values to ensure that the characters can't jump over certain things (like walls). In the picture below, you can see my program printing the maps in color (according to their elevation).



If I want to check a coordinate value on a map, I can do that as well by using the Map Information tab (as seen below). It allows me to see a picture of the map and check tile rules that the server is enforcing.



That's it for now. More development is coming soon.
Cheers,
Spirited Fang.

[a7xfan06]

Looks great man, pretty impressed. Keep up the good work.

[I don't have a username]

You know why it's bad that you're using a GUI for this? Especially when it's Windows Forms, because it uses GDI+ which is VERY SLOW and it might slow down your performance over a longer period.

[Spirited]

Originally Posted by I don't have a username

You know why it's bad that you're using a GUI for this? Especially when it's Windows Forms, because it uses GDI+ which is VERY SLOW and it might slow down your performance over a longer period.

I appreciate the research you've done into that, but as long as it doesn't actively draw, it won't do much at all. Besides, the advantages of having a GUI overweight the costs.

[JohnHeatz]

Originally Posted by Fаng

Besides, the advantages of having a GUI overweight the costs.

When it comes to software, GUI isn't as important as performance, you can see this when you go over a place in which systems are still coded in Cobol and alike, so I sincerely and respectfully hope that this statement I have quoted is not serious at all, no programmer will think like this, ever

[I don't have a username]

Originally Posted by Fаng

I appreciate the research you've done into that, but as long as it doesn't actively draw, it won't do much at all. Besides, the advantages of having a GUI overweight the costs.

But you are drawing actively, because your console is not a console. It's drawing to your form which invalidates the whole form means every time you write something to it then your form and your "console" is redrawn. That's repeated every time your write something to your console and overtime it's going eat up your memory. It's not a lot, but it's enough considering it's a server then you should value performance over GUI.

[Spirited]

For the same reasons why WoW's servers, NetDragon's servers, Minecraft's servers, and mostly ever other game service has a GUI, I have a mother ******* GUI. I already kindly turned down your suggestion, and I will restate my opinion: the advantages of having a GUI outweigh the costs.*

[Korvacs]

Minecrafts gui was an after thought though, and hinders it substantially, and Netdragon's code shouldnt really be used as an example of good practice, and i doubt anyone here has ever seen the official WoW servers in person so theres no telling what the front end is like.

Anyways if you are going to have a gui for a server it should be threaded correctly so that it has no influence on the performance of the server itself, I would go as far as to say that your better off writing a management application which will communicate with the server or use shared memory in order to make changes rather than have it built into the application itself.

[I don't have a username]

When you invoke your form you could invoke the controls in a new thread, so it won't block your current threads or whatever you're doing till the invoke is finished.

What I mean is something like this.

	/// <summary>
	/// Delegate usd to handle safe invoke events.
	/// </summary>
	public delegate void SafeEvent();
	
	/// <summary>
	/// A class to handle safe invokes on Windows Form Applications. It can be used to handle invokes on cross-threading problems as well it won't slow any threads down. It runs over its own thread.
	/// </summary>
	public class SafeInvoker
	{
		private static ConcurrentDictionary<int, SafeInvokeEvent> safeEvents;
		private static SafeRandom safeRandom;
		
		/// <summary>
		/// Event invoked by the safe invoker.
		/// </summary>
		private class SafeInvokeEvent
		{
			public bool Invoked = false;
			public SafeEvent Event;
			public Control Ctrl;
		}
		
		static SafeInvoker()
		{
			safeEvents = new System.Collections.Concurrent.ConcurrentDictionary<int, SafeInvokeEvent>();
			safeRandom = new SafeRandom();
			new Thread(new ThreadStart(Safe_Thread)).Start();
		}
		
		/// <summary>
		/// Invoking a control/form with an event.
		/// </summary>
		/// <param name="ctrl">The control/form to invoke.</param>
		/// <param name="safeEvent">The event to invoke.</param>
		public static void Invoke(Control ctrl, SafeEvent safeEvent)
		{
			SafeInvokeEvent siEvent = new SafeInvokeEvent();
			siEvent.Event = safeEvent;
			if (ctrl != null)
				siEvent.Ctrl = ctrl;
			int id = safeRandom.Next();
			while (!safeEvents.TryAdd(id, siEvent))
				id = safeRandom.Next();
		}
		
		private static void Safe_Thread()
		{
			while (true)
			{
				foreach (KeyValuePair<int, SafeInvokeEvent> sEvent in safeEvents)
				{
					if (!sEvent.Value.Invoked)
					{
						if (sEvent.Value.Ctrl != null)
						{
							if (sEvent.Value.Ctrl.InvokeRequired)
								sEvent.Value.Ctrl.Invoke(new MethodInvoker(() =>
								                                           {
								                                           	sEvent.Value.Event.Invoke();
								                                           }));
							else
								sEvent.Value.Event.Invoke();
						}
						else
							sEvent.Value.Event.Invoke();
					}
					sEvent.Value.Invoked = true;
					
					SafeInvokeEvent rEvent;
					safeEvents.TryRemove(sEvent.Key, out rEvent);
				}
				Thread.Sleep(50);
			}
		}
	}

Example: (this = form in this case)

			                            		SafeInvoker.Invoke(this,
			                            		                   () =>
			                            		                   {
			                            		                   	label1.Text = rnd.Next().ToString();
			                            		                   	label2.Text = rnd.Next().ToString();
			                            		                   	label3.Text = rnd.Next().ToString();
			                            		                   	
			                            		                   	richTextBox1.Text += rnd.Next().ToString();
			                            		                   	richTextBox1.Text += "\n";
			                            		                   });