I've tried sending their real keys, they get cut off if x character is found. But thanks for the ascii idea, that'll definately work.
| |
Use url_encode() on the key. The params2list() (called automatically for the href_list argument in Topic()) will convert it back to the proper string without any additional code and it takes less characters than a full ascii conversion.
| |
I'll second this idea, since it is a decent one that nobody else has responded favorably to yet.
There are plenty of things that are included that nobody gets any use out of. Therefor, if someone can get use out of something at all I don't see why it shouldn't be considered. Why not whine about the second argument to text2ascii? It is completely not necessary since you can use copytext to get the required character first. Yes, this paragraph is sarcasm. Adding completely new features is always better than adding new ways to do the same old things, no matter how obscure the use may seem. If even only a small handful of people ever use it, I can say it will have been more useful than the while loop. | |
Loduwijk wrote:
There are plenty of things that are included that nobody gets any use out of. Name some. ;-) | |
shell() is hardly ever used.
Neither are the two byond_version vars. Or the Set/GetConfig() procs. Or startup() or system_type | |
Jp wrote:
shell() is hardly ever used. Only because of the safe mode message - it could be very useful in an environment where you know that you're running in Trusted mode (like for games that are only run on one server). Neither are the two byond_version vars. The current private beta has support for variable-volume sounds, which will always be played at full volume on previous BYOND versions. This could be a problem if you want to play really quiet sounds - they'll always come out full volume on those older versions! Checking client.byond_version would allow you to simply not send sounds with low volumes to those older clients, but still play them for newer clients. I guess world.byond_version isn't all that useful because usually the DMB's minimum version number is the restrictive value, but it's good to have for completeness. Or the Set/GetConfig() procs. They have their uses, though they are probably the least-used things in your list. Or startup() This is useful for creating "monitor" worlds that restart crashed games, as well as multi-server games that automatically start up child worlds. or system_type I've used it. It's also handy for singleplayer games - if the game is being hosted through the Unix Dream Seeker then you can use world.system_type to detect that fact, and enable text-specific features for anyone with a null client.address. (client.address==null means that the client is a Dream Seeker host.) | |
Alright, you caught me exaggerating. However, some functions that are seldom (if ever) used were just listed by someone else. And despite whether or not they could be used is different from whether or not they see much use, which is the actual quality in question here.
Just because something can do this or that doesn't mean it will. And if the suggestion for this thread is implemented, apparently it will get used. Therefor it is just as worthwhile to have around as other things that rarely (if ever) get used, no matter what they may or may not be useful for. | |
Just because something can do this or that doesn't mean it will. And if the suggestion for this thread is implemented, apparently it will get used. Therefor it is just as worthwhile to have around as other things that rarely (if ever) get used, no matter what they may or may not be useful for. However it would be better if they would add features which are more commonly useful than waste time making ones which aren't neccessary and have obscure purposes. Getting a key from a ckey can't be done simply since without a database of keys you can't go from ckey to key which would mean to do the conversion there would have to be a database query across the net. Which means you also now have to handle the fact that the user may not be connected to the internet, the delay involved, and decide whether it will be a syncronous or asyncronous call. And if it is asyncronous you need some sort of callback incase the program needs to know when it is done along with the results. So all in all it would be a complete mess to program for a simple asthetic feature :P. Not to mention you can grab the key name from the BYOND site. | |
Do you mean something similar to this as the thing as a whole?