Eclipse Origins v2 Beta

[unknown]

Everyone always says sending byte arrays is more efficient.. Does anyone actually know why? Whatever you send is going to get converted to binary anyways.. A byte representation of a string is going to be the same size as it's string equivalent when converted to binary unless you do something to it (like compress it)…

So am I missing something? Can anyone explain why this is faster?

[dugor]

In vb6, string comparisons are god awfully slow. I remember doing a speed test, writing data using byte arrays vs strings, and byte arrays just blew it out of the water. Sending it down the wire might be the about the same, but putting those packets together and taking them apart is where the real speed increase happens.

[unknown]

Huh interesting… I guess that makes sense

[Triple_X]

I have a problem. How can I modify the maximum exp for each level?

[StorN]

Frankly, you do not understand why this engine is so "excited": /
But … no fact is a lot of goodies. But the lack of trade system, am system and many many other things in this example, scripting, which is essential for me: /

[Kimimaru]

Also, when you're using String packets, you use a variable to separate the data, and at the end, you use another variable to declare the end of the packet. When using byte arrays, none of that exists; you just get straight to the data, and it stops handling everything when there is no data left.

```
Dim Buffer as clsBuffer

Set Buffer = New clsBuffer

Buffer.WriteLong "packet"
Buffer.WriteLong Index
Call SendDataTo(Index, Buffer.ToArray())
Set Buffer = Nothing
```
That's sending a basic packet with Index as the only data besides the packet name on Eclipse Origins. There are no variables used to separate the data here. On other Eclipse versions, the same thing would be sent like this:

```
Call SendDataTo(Index, "packet" & SEP_CHAR & Index & END_CHAR)
```
It is much simpler, but it has a variable separating the data as well as another variable that serves to indicate the end of the packet. Because of this, more bytes are packed into the packet, making handling them slower.

[Robin]

@StorN:

> Frankly, you do not understand why this engine is so "excited": /
> But … no fact is a lot of goodies. But the lack of trade system, am system and many many other things in this example, scripting, which is essential for me: /

What? It has the best trade system around.

Scripting is about as essential as you being in this thread.

[StorN]

.. player handel ??? not

[Harris6310]

Previous versions of Eclipse: Toyota Prius - Slow, full of crap that you don't need and any noob can use it.

Eclipse Origins: Aston Martin 6B9 - Fast, Efficient, No-Nonsense and you need to know a bit to use it.

That's Eclipse summed up for you.

[cody4camp]

It fails to surprise me that people are wanting a scripting engine for EO. People, people, I call to you; Please learn vb6 and make your own scripting engine, perhaps modScripting.bas?

[Spainion]

VB6 pretty much is sadScript, there shouldn't be any problems.

[Dark Crusade]

@Robin:

> Scripting is about as essential as you being in this thread.

Good call XD

[Robin]

This isn't the place to discuss your .NET questions.

[EclipseCommunity]

@Harris:

> Previous versions of Eclipse: Toyota Prius - Slow, full of crap that you don't need and any noob can use it.
>
> Eclipse Origins: Aston Martin 6B9 - Fast, Efficient, No-Nonsense and you need to know a bit to use it.
>
> That's Eclipse summed up for you.

Don't you mean DB9?  And what an insult to this engine…

[Godlord]

@Vegeta:

> I'm trying to convert your Engine to VB.net and I have a question, What is the sole point of the clsbuffer class you have? Is it for byte buffer compression to save bandwidth? because if it is then I can use the System.IO.Compression.Gzip library to replace zlib.
>
> Thanks In Regards,
> StormShellX

It's used to build bytecode packets. Compression isn't normally used, but can be used.

@unknown:

> Everyone always says sending byte arrays is more efficient.. Does anyone actually know why? Whatever you send is going to get converted to binary anyways.. A byte representation of a string is going to be the same size as it's string equivalent when converted to binary unless you do something to it (like compress it)…
>
> So am I missing something? Can anyone explain why this is faster?

VB6 uses malfunctioning UTF-16 strings, so that's already a reason why bytecode would be smaller. But, the actual fact is that you transfer more numeric data than actual literal data and numeric data should always be sent in its own binary format and not as a literal.

@dugor:

> In vb6, string comparisons are god awfully slow. I remember doing a speed test, writing data using byte arrays vs strings, and byte arrays just blew it out of the water. Sending it down the wire might be the about the same, but putting those packets together and taking them apart is where the real speed increase happens.

String comparisons are slow in a lot of programming languages, especially when you compare it to string hashing, but both methods aren't used in my own compiler's lexical analysis (Hint: every byte in a stream gets only tested once).

@Robin:

> This isn't the place to discuss your .NET questions.

A lot of the replies in this thread aren't really useful anyway.

Regards,
  Stephan.

[unknown]

@Stephan:

> VB6 uses malfunctioning UTF-16 strings, so that's already a reason why bytecode would be smaller. But, the actual fact is that you transfer more numeric data than actual literal data and numeric data should always be sent in its own binary format and not as a literal.

Yeah I understand when transferring numeric data you don't want to send the numeric data as a string. In Odyssey, there are different methods for converting numbers to chars and appending them to the resulting packet. If you just use a packet.converttobytearray() method on a string in VB.NET or some other language you're still going to have this problem..

[tiggilyboo]

The speed of the networking in EO could be a bit faster, look through robins sizing of the packets, and use preallocations for at LEAST the sending of packets (Robin does not use pre-allocations.), later think about the size of incoming and have that even pre-allocated. All of EO packets are still over-sized, and can be put down to at least 1/3 of its current size.

For example, there are less that 255 packets enumerated. Instead of using a long or integer header, use a byte. Also, make sure to check through all of the Long data types being sent and received, its quite phenomenal how many have been over sized.

I asked him about it, and he's said he's not worried about it, due to lack of interest or effort.

It may be a tiny bit faster, even if its worth worrying about…

[jcsnider]

I do not know if this has been brought to your attention, Robin… but not all computers have a sounds card, or maybe even drivers for their sounds card... in sub init sound, if you do not have a sound card you will get an automation error. My suggestion is to just add on error resume next, so for those who have sound, it works, for those who dont, well, they wouldnt have sounds anyway :D

[shadowwulf]

omg… for the life of me i cant remember where i saw how to set character's initial spawn location...

[Robin]

Bottom of modConstants serverside.

[shadowwulf]

just found it. XD
I'm going to redo that little bit. Make it random selection of spots pertaining to selected race.

EDIT
Also found a bit of a bug…
Sometimes the number of tilesets detected stops at 9 but I have 32.
I never change anything with the tilesets, but it sometimes only loads 9, i reboot the client only, and they all show up.

[reZed]

How do I turn the life bar over the enemies? I want see life of my enemi.

[Robin]

Program it in.

[reZed]

But I do not see it :sad:
[](http://xmages.net/show.php/1544918_jpg.html)

[Robin]

@reZed:

> But I do not see it :sad:

Because it doesn't exist. You need to program it yourself.