dataserver appears to be broken

I can't get any answer from llGetNumberOfNotecardLines, llGetNotecardLine. This simple script don't work:

default {
    state_entry() {
        gName = llGetInventoryName(INVENTORY_NOTECARD, 0);
        llSay(0, "Reading notecard " +gName);
        gQueryID = llGetNumberOfNotecardLines(gName);
    }


    dataserver(key queryid, string data) {
        llSay(0, "This notecard has " + data + " lines.");
        integer    lines = (integer)data;
    }
}

[18:45] Object: Reading notecard TEST NOTECARD
[18:45] Object: This notecard has


lines.

If the notecard is fresh item made with "Create New Note" command in inventory window, then it's handled in odd manner by data server (like some sort of 'shortcut' to generic empty notecard that cannot be succesfully queried nor read)

The card becomes 'real' notecard only after you open it to edit and hit "Save" to record its content. If you want the card to be empty then enter any character as content of the card (to enable "Save" button), then delete the character and save such card.

And yes it's clumsy and convoluted but oh well. Can't beat them, join them ^^;;

Hi Joannah.

My notecard is not empty, and had been read this way before version 1.3. I've tried with different notecards, different objects, logged out/in suspecting a network error. The result is always the same: dataserver returns two blank lines for every llGetNumberOfNotecardLines or llGetNotecardLine request.

UPDATE: the notecards exhibiting the problem were written with 8 bit ASCII. Since version 1.3, all 8 bits characters have been replaced with a '?'. Those cards are not compatible with the dataserver.

There's no assets in it, like landmarks, textures, etc., right? Those will kill it too.

No Tyken, there is no asset in it. I've read about that one also

It's really a character encoding problem. Every notecard containing non 7-bit ASCII blows the dataserver. Example: 2006-07-24 16:15:29 note card from the ICT Library:

About Scripting
SL ICT Library: Free Script dispensers (pertaining to education)
? <- here

and of course, all foreign language notecards having being written before release 1.3. We have tons of notecards to rewrite now.

Oh, that's rich....

So, basically, if your notecard has high-order characters (> 127), it won't even count the lines anymore, let alone read?

Uhh, why did they do that?????

Erm llGetNotecardLines returns immediately and does not trigger the dataserver event...

***what can I say? I wasn't awake LOL *** duh me for spreading disinformation *smacks his own hands *

There is no llGetNotecardLines, but if you meant llGetNumberOfNotecardLines:



...methinks you are at odds with the Wiki.

Yep. The dataserver handler spits two (or three) empty lines instead of number and string. I'm torture-testing a notecard to e-mail gateway, and every note crashing it contains a "?" in place of éàèùç or «». Of course i can fix the gateway easily, but the notecards are lost. You have to copy/paste them in-world. Huge pain for the education business.

Because someone goofed I think.....

Are you saying they finally added unicode support to notecards?
Well I'll be a monkeys uncle.

It's not a screw-up that extended ascii characters bork it. The original notecard format that LL uses, they mark embedded assets with extended ascii characters. The first asset is 0x80, the second 0x81... etc.

They just need to properly write the code so that it actually checks to see what assets are included in the notecard instead of just fudging it.

Isnt that contradictory Strife?
It would have been nice to have actually been informed about it.

*rereads*
Yeah it does sound like a paradox.

LL just got lazy when implementing UTF8 in notecards. If you want them to fix it best to bug report it. If I see a linden I'll point it out.

The line which reads:

        gQueryID = llGetNumberOfNotecardLines(gName); 

is incorrect in the assumption that it will trigger a dataserver event. The function returns the number of lines not a QueryID, so no dataserver event will be triggered.

        integer lines = llGetNumberOfNotecardLines(gName); 
        llSay(0, "This notecard has " + (string)lines + " lines.");

The dataserver is not needed to get the number of lines, only the contents.

You are wrong.
Read: http://lslwiki.com/lslwiki/wakka.php?wakka=llGetNumberOfNotecardLines

Wow, and even after someone else was corrected for the same misinformation in the same thread.

My bad.

I want more than the bug fixed, I want the capability to access linked cards, that is getting the UUID of the embedded link through dataserver, then accessing the asset the link points to. In a word, I want a Second World Wide Web.

Linked cards are the most powerful information vector we have in SL. They have all the capabilities of the hypertext, plus more. We can link objects. Think about rezing an object from Internet Explorer to your 1st life floor. Wow! But information management requires automatic data processing, and we have quite nothing on this side.

Heh. With the way LL works, you better be thankful if the bug gets fixed at all, let alone extended funcionality.

What you're asking for can pretty much be done as it is right now by copy/pasting the Asset UUID in as text.

That's right, llGetNotecardLine(UUID, line) can read the notecard, even if the notecard is not in the object's directory. llGetNotecardLine("Anti-Griefing", n) won't work, but llGetNotecardLine("4fbc1b72-e6cb-bebe-065c-09d4c9156a6d", n) will. That makes sense, because names resolve to UUID, and the directory is a name to UUID mapping.

Good thing but... how to display Notecard "4fbc1b72... to the user? The client can do it. But an object can't. llGiveInventory("4fbc1b72...) won't work. It can only give objects residing in it's directory. The missing link, here, is llMakeDirectoryEntry(name, key).