|
|
|
Changed the summary to reflect strife's comment.
Actually, it IS hard to encapsulate the information so that the returned truncated name can be identified. I assume that you're suggesting that one should take their list of avatar names, truncate them down to 24, and then keep a list of those truncated names and the corresponding untruncated name. Then, when the dialog button-press triggers a listen event, the button text would be matched up with the list of truncated names to figure out who the actual avatar in question is.
This is actually pretty difficult to do for someone who isn't well-versed in LSL, and I don't think it's fair to expect them to have to figure this out. The solution of using numbers instead of names is one I use often, but it doesn't make for a particularly pretty interface. I'd much rather see the system not be so actively hostile to developers. I would not consider this a feature request due to it's direct impact on the ability to play the game. In the short time
that I have been playing the game (2 weeks) I have already experienced two times where this issue prevented me from participating in "standard" game activities: 1. I tried to enter a contest using a contest board and after I entered it no one could vote. At a very minimum the llDialog should recognize that a button string is > 24 characters and ignore that particular add request I am a Java programmer by trade and I know that for things like buttons the display field is not necessarily the value used Charlotte, that's exactly how it works: if you use a 23-character long button label, not all of the label will appear on the actual dialog button, but the script is still sent the entire 23 characters worth of the label. So that means that 24 truly is an arbitrary limit.
I think this should be a feature request, though, for two reasons: 1. The bugs you're experiencing aren't actually in the llDialog function itself, or in the underlying SL system, but in the scripts that are using llDialog. It's a pain that they're running into the arbitrary 24-character limit, but that limit itself is not what's causing the scripts to malfunction. It's that the scripts weren't written to take the limit into account. 2. The criterion I like to use for determining whether something is a bug or a feature is whether the system is working as designed. A bug is a case where the system doesn't work as designed, and a feature request is where you want the design to change. It's definitely the case that the 24-character limit was purposeful and part of the design... it's just a pain in the butt. Leaving this as a feature request need not necessarily mean it's low-priority, though. The beauty of it is that it makes it easier to use. It lets them see the full text of the option. There is some stuff you can do with button reordering that makes it more spiffy.
Like this: [code]list buttons; Dialog( key avatar, string message, list _buttons, integer chat_channel ) llDialog(avatar, message, _buttons, chat_channel); string ParseResponse(string raw) Lex,
Thank you for the explanation and I see what you mean. Yes perhaps this is a feature Charlotte Just to add to the discussion, I wonder if 010000100111001001100001011011 Omlet has had issues with this and his name. It might be hard to encapsulate that name from something similar.
I use to go by BlindWanderer everywhere but it was too long and in conversation it would be shortened (which I found mildly annoying). It's what prompted me to choose a new one and eventually settling on Strife, a name that doesn't get shortened in conversation. Food for thought I guess when choosing a name.
I have a feeling that what we need to do is not enlarge the button text limit, but tell script writers not to put avator names on a button. I don't support the idea to make the font smaller automatically, because it will make the screen hard to read (if not impossible) on some cases.
I agree with Alissa on this, furthermore I will add that I have not respect for scripters who are too lazy to work around documented shortcomings and pass them along to user without comment. What about if there are two people with the same first name? It's bad design, it's bad scripting, you don't need to be particularly adept to spot this one a long way off.
Alissa: this issue isn't requesting that more text be visible on a button. It's just requesting that the button label length used internally by SL be a little longer. The entire button label (even past what's shown in the UI) is passed back to the script when the button is pressed.
Strife: it's still a pain to code around this bug, and it's a nasty little gotcha if a new scripter hasn't carefully read the LSL docs like you and I have. It's also especially annoying if two people share the same name up to the first 24 characters. Rare, but I'm sure it's happened. I know the solution of numbering menu entries and putting numbers on the button would get around this, but I still maintain that that's an ugly way to present a dialog. It's a case of letting the implementation of the system drive the user interface, which is a cardinal sin of user interface usability. Furthermore, it's not always feasible to store a mapping either of numbers to menu entries or of truncated names to full names. I've had situations with multi-level menu systems that would be used by multiple people, and it's just a severe pain in the butt to keep track of each person's menu items, especially if the menu of names presented to each person might be different, as in the case that it's from the result of a llSensor(). One final bit of food for thought: for languages in which the unicode representation for each character is 2 or 3 bytes, it's conceivable that 24 bytes is not enough even to fill an entire button! The problem will be worse in decades to come when 5 & 6 byte Unicode ranges (in a UTF-8 sense) get allocated (there are already 4 byte UTF-8 characters).
Lex: The dialogs buttons are too small to display the full text already, the only way around the existing bad interface design is to prefix the entries and to list the full text options. I wrote a module several years ago that handles the multiuser issue, it's about time I rewrite it. Yes, the buttons could be labeled, and the dialog text above could which button matches to which person, though the inability for the dialog to be resized much (and thus has to be scrolled) is annoying.
Honestly, I think it is better for the scripter to design an interface onto a HUD. Then it can be designed to fit whatever is necessary. But to get back to the issue, why is the data limited to 24 characters anyways? Agents and scripts can say up to 1024, and isn't a dialog pretty much acting as if the user "says" the button text? Anthony: Bandwidth, they don't want to split it over multiple packets. 12 * 24 + 512 = 800
This would be very useful because right now there is no way to force an agent to say a string larger than 24 characters. the security using llDialog is great (only the user cans ee the options, only the user can respond and the user doesnt even know what channel they are using), but what good is it if you cant even fit a name in there.
There is no security with using llDialog, the chat is still said on a channel that any script can listen on.
When you take into account that there are 4,294,967,294 channels and your only using 1, of which the user has no way of knowing, and even if they make a scanning listener script, it'll have to go through that massive amount 65 channels at a time... they had better have alot of free time on their hands, I would say is it "Secure enough" especially when you can have it change the channel its using every time the event is called.
|
||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Max String Length Should Be Greather Than 24 Bytes For llDialog Buttons
I fit on dialog buttons and in most overhead compartments.
It's much better to list the options in the text body and then prefix the button texts with numbers that correspond. Then when you read it back in, you just match up the numbers to the names. It does require you to cache the options.
I'm changing this from a bug to a feature suggestion because it's not a bug, it's an intended limit built into the design.