[Official] Eclipse.NET

[Synergy]

@JeffSventora:

> Where is that coming from?

From when I double click the Mirage.NET Client.. So.. Idk. ;)
Am I meant to do something before hand to make it work? And yes, I tried running it as Admin. No luck.

[JeffSventora]

If you're trying to run the executables make sure you the XNA game studio 4 runtimes installed as well as the .NET framework 4\. Which version is it, the newest?

[Synergy]

That seems like quite a lot of work to just run the client. Can you give me a link to the XNA Game Studio 4 runtimes?

[JeffSventora]

The .NET framework should always be updated to the latest version.

[http://www.microsoft.com/en-us/download/details.aspx?id=20914](http://www.microsoft.com/en-us/download/details.aspx?id=20914)

Download and install that and you should be fine if you're running an executable, if you're going to try and edit/change the source you need the framework.

[Likestodraw]

Congrats on getting this to be an official project!

[JeffSventora]

Thank you!

[crzyone9584]

once again congrats man. This was the whole reason why i was making Crzy Eclipse. You beat me to it… The more I drink the more idk lol ive been drunk all weekend congrats man.

[JeffSventora]

I appreciate it a lot! How would you like to help me? I'd love an extra hand.

[Synergy]

> The .NET framework should always be updated to the latest version.
>
> [http://www.microsoft…s.aspx?id=20914](http://www.microsoft.com/en-us/download/details.aspx?id=20914)
>
> Download and install that and you should be fine if you're running an executable, if you're going to try and edit/change the source you need the framework.

That got it working. I like the skull. ;D

[crzyone9584]

> I appreciate it a lot! How would you like to help me? I'd love an extra hand.

Sure I'd help. Just let me know what you need done man. Looks like you got the basic networking in. I can work on that if you want to focus on other things.

[JeffSventora]

**UPDATE**

Added the scripting engine. Not 100% functional, but it's almost there. This will allow you to define classes and methods in external script files. The best part is that all of the scripts are compiled at run time so the overhead is VERY minimal.


You can do a lot of things with something as simple as what I have shown above. You can create a "TestClass" instance via server in code, invoke methods, get data member values, set values, and even grab the instance of the object created and pass it to another script. Who knows. I'll be setting up some more functionality for it to make it easier to use but this is just the current state of it.

I would also like to let everyone know that crzyone9584 has agreed to help me develop the engine. I've showed him around the engine and I'm sure he'll help produce quality work. Stay tuned everyone!

**EDITOR**

I forgot to mention, I will be developing a syntax highlighted editor for the scripts.

[Vince]

Nice, but…

Why do u use Windowed mode ?

Console is even better.

[mrmiguu]

I remember trying the whole scripting thing. I remember giving up on it because I couldn't get the engine to read the code properly. It could get it to work, but reading it back after saving edits screwed everything up for me. I'm glad you haven't had the issues I did. Looks good.

[JeffSventora]

Thank!

And the console is better, for some people at least. using the Form makes it easier to use. For example, run GIT Bash along side GIT GUI and you tell me which one look easier  lol

Also, I forgot to mention, the scripts will support Visual Basic AND C#.

Thanks MrMiguu, when you see the code you'll be baffled by the simplicity! 

[mrmiguu]

> Console is even better.

It's not as user-friendly. That's assuming his reason for using windowed mode.

[Vince]

> Thank!
>
> And the console is better, for some people at least. using the Form makes it easier to use. For example, run GIT Bash along side GIT GUI and you tell me which one look easier  lol
>
> Also, I forgot to mention, the scripts will support Visual Basic AND C#.

Have an UI is more user friendly, but the UI slow down the performance of your server.

I advise you to use console cause in a server there is just a few commands which is really essential(cf: administration commands).

PS : I use Git Bash  .

[JeffSventora]

It doesn't really hinder performance because I have the UI and the Networking operating on their own threads. But I see where you're coming from. The big thing is that I want it to be as user-friendly as possible. You could EASILY take the existing code and convert it to use a console if you pleased.

[mrmiguu]

> Have an UI is more user friendly, but the UI slow down the performance of your server.

I don't think by much, though. Unless you're aiming for hyperspeed with +100 users, a normal window interface will be more than enough. It can't "slow down" the server if the server isn't using 100% of the CPU (that's assuming that a window inteface even uses CPU; I'm sure it just uses memory).

Edit:

Pretty much what Jsventor said.

[Vince]

> It doesn't really hinder performance because I have the UI and the Networking operating on their own threads. But I see where you're coming from. The big thing is that I want it to be as user-friendly as possible. You could EASILY take the existing code and convert it to use a console if you pleased.

You're the developper, don't wanna change your idea regarding the accessibility of your application.

I just made a suggestion

> I don't think by much, though. Unless you're aiming for hyperspeed with +100 users, a normal window interface will be more than enough. It can't "slow down" the server if the server isn't using 100% of the CPU (that's assuming that a window inteface even uses CPU; I'm sure it just uses memory).
>
> Edit:
>
> Pretty much what Jsventor said.

Not so much yeah, but it will be better.

[Godlord]

> Thank!
>
> And the console is better, for some people at least. using the Form makes it easier to use. For example, run GIT Bash along side GIT GUI and you tell me which one look easier  lol
>
> Also, I forgot to mention, the scripts will support Visual Basic AND C#.
>
> Thanks MrMiguu, when you see the code you'll be baffled by the simplicity! 

I don't even have a clue why that distinction is being made. Git is originally designed and developed to be used in a shell application such as Bash, which by the way, is a lot more extensive than Microsoft Command Prompt. For the Microsoft Windows version, they've decided to ship Bash with various UNIX utilities, as well as a Git GUI. In this case, it's simply better to use the Bash version because it is the most _consistent_. Other platforms simply won't have the Git GUI application, because it has been developed for Microsoft Windows, specifically.

For Microsoft Windows I can understand why you would want a GUI, rather than the command line. The major reason being that Microsoft hasn't been able to design a proper command line utility for the past twenty to thirty years. For most other platforms, a command line really is the better solution in most cases, and here's why that is: a command line only requires you to know the name of the programme(s) you want to use, as well as the arguments you want to pass to them, a GUI requires you to orientate, locate and select. The comparison is rather simplistic in that case: a command line requires a keyboard, that's about it, a GUI requires you to use a mouse, most of the times, unless you know the exact accelerators (and for some applications these are completely inconsistent).

The use of the mouse has several issues, the first being the one I've pointed out already: you have to orientate, locate and then select (usually numerous times before you get your action completed). The second being that a mouse is much more likely to cause RSI (One of my teachers is not allowed to use a mouse at all, and only uses it when it is required. She uses the keyboard for pretty much everything). Finally, most people are more likely to use the keyboard for most of their actions, simply because you don't have to move it.

> It doesn't really hinder performance because I have the UI and the Networking operating on their own threads. But I see where you're coming from. The big thing is that I want it to be as user-friendly as possible. You could EASILY take the existing code and convert it to use a console if you pleased.

This is not how servers are being developed most of the times. Servers are usually written as a service application (Microsoft Windows) or as a daemon application (UNIX et al.), where they can be accessed via the (local) network using command line and/or GUI utilities. Furthermore, it could be accessed via a website, if you really feel like doing that. It may be a good idea to design your server in such a fashion.

There are numerous reasons for using one of the aforementioned models. The first being that most people tend to use a separate computer, solely for the purpose of acting as a server. In which case, you are pretty much enforcing them to hook up a monitor to their server, whenever they have to administer the server, and you are pretty much enforcing them to run a desktop environment. On Microsoft Windows, the latter isn't as much of an issue, since, like I've said earlier, Microsoft hasn't been able to design a proper command line utility for the past twenty to thirty years.

However, on about every UNIX system you are going to encounter, which is pretty much the de facto standard for servers, it is likely that you only have access to it through the use of a terminal (via a serial cable, via ssh, or, if you are fortunate, via an actual display hooked up to the server). A programme like X11, and anything that depends on it, is very unlikely to be installed, which means you won't have any form of graphics, other than an eighty by twenty-five grid of characters, and there are very good reasons to not have X11 installed.

The first being one I've mentioned already: the graphical user-interface would be entirely inaccessible (X11 over the network is insecure and slow, and for Microsoft Windows there is nothing like X11, except for some applications that do offer remote access). Another reason is that just using a 1920x1080 display, will cost you about 15 MiB of RAM, just to generate and render any kind of simplistic screensaver. Then I am just ignoring all the other resources that would have been allocated.

There is a whole lot more to it, than just having a few tests running on your desktop computer.

Yours faithfully

S.J.R. van Schaik.

[Synergy]

I was going to say all that.. But S.J.R beat me to it.. 

[JeffSventora]

When I made the comparison between Git GUI & Bash I was expecting us to take a step back and put ourselves inside the shoes of one of the many 12/13 year olds on the site. I understand completely why a command window would be better. I am not trying to argue why it's better or not. But I would mach rather hear the complaints from 3 people than to hear the complaints of many because they have no idea how transition from a server provided by Eclipse Origins to this one. While designing this program I am putting the consumer in mind, and the fact is that a majority of the consumers won't be Stephans lol.

[chasseurd39Ãtoiles]

I'm very curious for the scripting part Jeff. Did you use Roslyn or CodeDOM for the compilation ?

Also, for the "go simple" part, why did you chose .Net scripting instead of javascript/ruby/any-other-scripting-engine ?

[Godlord]

> When I made the comparison between Git GUI & Bash I was expecting us to take a step back and put ourselves inside the shoes of one of the many 12/13 year olds on the site. I understand completely why a command window would be better. I am not trying to argue why it's better or not. But I would mach rather hear the complaints from 3 people than to hear the complaints of many because they have no idea how transition from a server provided by Eclipse Origins to this one. While designing this program I am putting the consumer in mind, and the fact is that a majority of the consumers won't be Stephans lol.

If you are keeping the consumer in mind, then why did you choose a user interface instead of a web service? Your kind of consumer would certainly fancy the latter.

Yours faithfully

S.J.R. van Schaik.

[Marsh]

Think you guys are worrying about this way to much. The server window is fine. When you get this caught up in every stage of development it will never get to a beta. Yes these things are important but can always be reconfigured later.

Also in the end its all up to Jeff. Though the input is helpful.