Getting the destination of a level link?

[jake13jake]

I've been messing around with testing for level links. I can test for them... the question is, how do you get the level that the link is supposed to be going to? Also--- If I can do this, would there be a way to disable the default link system?

[ApothiX]

Why would you want to disable the default link system? o_o

[Admins]

I would say the link.name is giving you the destination level name, but would need to check that.

[Maniaman]

Originally Posted by ApothiX

Why would you want to disable the default link system? o_o

to make classic less classic!


or to add some new link functionality stuff maybe. *shrug*

[jake13jake]

Originally Posted by Maniaman

to make classic less classic!


or to add some new link functionality stuff maybe. *shrug*

Well, mostly because you can't enter a level link if you're moving backwards. I'm having the same problems with playertouchsme and the damage system. It's definitely easier to modify how level links are detected than it is to mess around with playertouchsme though (which is why I bug Stefan about it whenever he visits).

[Admins]

I have checked the links, you cannot access the destination level right now, will add a variable for that soon.

[jake13jake]

Originally Posted by Stefan

I have checked the links, you cannot access the destination level right now, will add a variable for that soon.

Yea, I didn't think you could. It would also be nice if there was a clientside signs array for servers that don't need it so much for reading serverside vars (this will receive another loud no).

[Projectshifter]

For external levels using a gmap I don't think requires the use of level links, and then for internal levels you can always use an NPC for level links (I've never been fond of using the premade links anyway).

[jake13jake]

Originally Posted by Projectshifter

For external levels using a gmap I don't think requires the use of level links, and then for internal levels you can always use an NPC for level links (I've never been fond of using the premade links anyway).

If everyone could define how the default classes would behave, then I'm sure everyone would use them.

If your server runs on scripted systems, then you have a lot more control over how you can interpret the behavior of default classes. In particular level links and signs.

To interpret letters.png for signs, etc, you would need to be able to access the rgba of a pixel from an image at a specified coordinate. (I've suggested this without response). The lack of clientside access to signs means that you can't unlag them. However, if you could simply detect the sign and interpret letters.png, you could add some transition effects to the loading of the sign while waiting for the string to return from the server (probably .2 sec at most, avg .1).

Links are similar to signs, but they put you in a new level.

The easiest default class to reinterpret would probably be chests. It doesn't matter what the chest contents are as long as you can interpret them and know when the chest switches from closed to open.

The hardest default class to interpret: BADDIES... what a pain in the neck.

[Projectshifter]

Originally Posted by jake13jake

If everyone could define how the default classes would behave, then I'm sure everyone would use them.

If your server runs on scripted systems, then you have a lot more control over how you can interpret the behavior of default classes. In particular level links and signs.

To interpret letters.png for signs, etc, you would need to be able to access the rgba of a pixel from an image at a specified coordinate. (I've suggested this without response). The lack of clientside access to signs means that you can't unlag them. However, if you could simply detect the sign and interpret letters.png, you could add some transition effects to the loading of the sign while waiting for the string to return from the server (probably .2 sec at most, avg .1).

Links are similar to signs, but they put you in a new level.

The easiest default class to reinterpret would probably be chests. It doesn't matter what the chest contents are as long as you can interpret them and know when the chest switches from closed to open.

The hardest default class to interpret: BADDIES... what a pain in the neck.

I know how the system works. It makes a lot more sense to just rescript things on your own. For signs and such you could clientside the message (or if needbe set a string of signs on the client when you enter the level) and then have a clientsided NPC handle the viewing and displaying of the message. I personally don't think using say2 to display signs for newer servers is going to cut it, showtext (or if you really felt compelled to make a system to read from a file like letters.png you) isn't hard manage in conjunction with a scripted form of signs.

[jake13jake]

Originally Posted by Projectshifter

I know how the system works. It makes a lot more sense to just rescript things on your own. For signs and such you could clientside the message (or if needbe set a string of signs on the client when you enter the level) and then have a clientsided NPC handle the viewing and displaying of the message. I personally don't think using say2 to display signs for newer servers is going to cut it, showtext (or if you really felt compelled to make a system to read from a file like letters.png you) isn't hard manage in conjunction with a scripted form of signs.

Classic's systems are supposed to be based on the default systems but to offer more flexibility. I don't like using say2 for mimicking the default signs.

It isn't possible to read from letters.png right now, and that creates a problem in trying to make a new system regarding it. If I were to make a new system regarding it, I would want to make it automatically wrap text and give it the ability to align the text for a line, etc.

The END graphic on Classic can't use letters.png because there's no possible way to grab the background color of letters.png from a pixel. In the meantime, redrawing the pixel a gajillion times would be quite inefficient.

[Admins]

The pixel retrieval functions were added one month ago with v4.04,
http://forums.graalonline.com/forums...ad.php?t=64166

[jake13jake]

Originally Posted by Stefan

The pixel retrieval functions were added one month ago with v4.04,
http://forums.graalonline.com/forums...ad.php?t=64166

oh <3, was that from my earlier suggestion?