Maps and items limits

[rafex12]

Sorry for my bad English.

So im creating this big game called Dalarian ( Polish game )

And i noticed that item, npcs , and map limit is 255 or 100.

So i was experimenting with the source Constants in the server and client folder ( becouse they have to match each other ), but it doesnt work at all. Can someone please point me to a tutorial on the forums or help me here, how to increase this limit ?

[Zeno]

Which engine are you using?

In EVB and EO you only have to change the constants client- and server-side. Make sure you recompile both client and server.

Can you explain how this does not work? In the server data folder, is there now more files in the maps, items, and npcs folders? If so, does your client display those extra files in the editors?

[Synergy]

The maximum size of the "_byte_" type is 255.

If you want to use something more than this, you'll need to change the code which looks something like this:

```

Items As Byte

```
(someone with the code and VB6 downloaded can give you the exact code)

It'll be under "modConstants" - both server and client side.

You then need to change it to a type which is longer, obviously. So, off the top of my head, either an "_integer_" or "_long_" will work. Someone with more technically knowledge would be able to suggest why one is better than the other.

I don't know if you have to change anything else in the code as well, so it'd be worth doing a search through of the code to find out.

[Zeno]

> The maximum size of the "_byte_" type is 255.

> (someone with the code and VB6 downloaded can give you the exact code)

Those variables are dimmed as long in Eclipse and its derivatives. I've just checked Eclipse VB, Mega, Origins, Final Frontier, Dragon Eclipse, and even Miracle. Good idea, but no.

Just an fyi, you would never want to dim these as integers. Integers can be negative and it's a waste of memory.

With a fresh copy of any of those engines, changing the value in modConstants is all that is required. rafex12, make sure that you are using a compiled version with the changes, or running (f5) from within VB6.

[abhi2011]

All data types can be negative.

But Integers are slow. (stated by Sekaru not me. If it's wrong blame him lol)

@Zeno it would be wiser to use Ctrl+F5 as it compiles every almost every single-line of code and is better to debug.

[Zeno]

> All data types can be negative.
>
> But Integers are slow. (stated by Sekaru not me. If it's wrong blame him lol)
>
> @Zeno it would be wiser to use Ctrl+F5 as it compiles every almost every single-line of code and is better to debug.

Good tip! Thanks.

Although almost all data types can go negative (including long, duh/woops); unsigned types such as bytes can not.

Integers are 16-bit (half the size of longs) and get a bad rep because they need to be padded. Longs are more efficient for their size because they are 32-bit, like 32-bit windows. There's no blanket answer on speed. It depends on the operation. Longs tend to be better, but not always.

[Synergy]

Well, like I said, someone with more technical knowledge would know more.

There should be something modConstants then, as "MAX_ITEMS = 255" or something like that? Again, I haven't got any code so I'm going purely from memory. 

[abhi2011]

That is pretty much correct.

```

MAX_ITEMS as long = 255

```

[DMF]

you adjust the 255 to what ever you like just like maps npc's and such… thats no a new thing with eclipse ppl...

[Matt]

> you adjust the 255 to what ever you like just like maps npc's and such… thats no a new thing with eclipse ppl...

Maybe not, but it's new to him. Try to be more friendly next time, hm? 

[JohnPony]

> All data types can be negative.
>
> But Integers are slow. (stated by Sekaru not me. If it's wrong blame him lol)
>
> @Zeno it would be wiser to use Ctrl+F5 as it compiles every almost every single-line of code and is better to debug.

Actually, you'd be wrong if VB6 had unsigned types beyond the byte type, which is unsigned; you're still wrong.

[abhi2011]

> Actually, you'd be wrong if VB6 had unsigned types beyond the byte type, which is unsigned; you're still wrong.

It was a mistake on my part. I didn't know that bytes were unsigned.