Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008370opensim[REGION] Scripting Enginepublic2018-09-13 03:562018-10-23 14:14
Assigned ToUbitUmarov 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformPCOSWindowsOS Version10
Product Version 
Target VersionFixed in Version 
Summary0008370: [PATCH] llName2Key not implemented
DescriptionSee [^]
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Attached Filespatch file icon 0001-Mandarinka-concept-of-llName2Key.patch [^] (2,801 bytes) 2018-09-16 14:08 [Show Content]
patch file icon llName2KeyBB.patch [^] (3,484 bytes) 2018-09-20 00:33 [Show Content]
patch file icon 0001-llName2Key.-Thanks-to-mewtwo0641-and-watcher64.patch [^] (3,058 bytes) 2018-09-21 22:23 [Show Content]

- Relationships

-  Notes
mewtwo0641 (reporter)
2018-09-16 08:59

I made an implementation of llName2Key. I'm not sure if it's the best way to do it (I'm very tired at the moment lol) but it seems to work fine as per the SL Wiki.
BillBlight (developer)
2018-09-16 10:06

I can see where this might be needed for "completeness" but at the same time, we already have the appropriate OSSL for these ..
Mandarinka Tasty (reporter)
2018-09-16 14:13
edited on: 2018-09-16 14:14

Hello ) I've thought that mewtwo's construction can be drastically simplified.
In my opinion, there is no need to use technique, that comes from osAvatarName2Key and dealing with syntax of string name.

Mewtwo's way can be applied in other new function, that returns key of avatar, that does not exist in a scene.

My way analyses presence of an avatar, under given name condtion, using boolean TryGetAvatarByName, that simplifies a lot the patch.

I also filter NPC characters, since they are allowed to use the same names as other existing presences in the scene, and that would make information useless.

Mandarinka Tasty (reporter)
2018-09-16 14:52
edited on: 2018-09-16 14:58

Here is example of a school script:

integer a;
integer chan;
key toucher;
    touch_start(integer num)
        if(a == 0)
            chan = (integer)llFrand(DEBUG_CHANNEL) * -1;
            toucher = llDetectedKey(0);
            llTextBox(toucher,"\nTo receive the user's key\nplease type resident's name in a box below:\n",chan);
            if(llDetectedKey(0) != toucher)
                llRegionSayTo(llDetectedKey(0),0,"\n\nPlease wait a moment. Busy with another resident.\n");
    listen(integer Channel,string Name,key ID,string Text)
        key user = llName2Key(Text);
        if(user != NULL_KEY)
            llRegionSayTo(toucher,0,"\n\n"+Text+"'s key is: "+(string)user+"\n");
            llRegionSayTo(toucher,0,"\n\nResident: "+Text+" doesn't exist in the region.\n");
        llRegionSayTo(toucher,0,"\n\nSession has expired. Try again later.\n");

Please remember, that name of foreign grid's avatar should be given in a form:

John.Smith ,
where FirstName = John.Smith and LastName =

mewtwo0641 (reporter)
2018-09-16 19:24

@Mandarinka Tasty - That is quite a bit shorter than mine :) Though I would like to point out that in my testing of your version, it doesn't satisfy a few of the requirements stated in the SL Wiki for the function; namely that the function should accept name format Firstname Lastname, Firstname.Lastname, or just Firstname (Last name of "Resident" is assumed in that case) and also that it is not case sensitive. I've uploaded a modified version of your patch that addresses those requirements which is basically a little bit of my first patch and your patch mixed together with a few tweaks to them :)
Mandarinka Tasty (reporter)
2018-09-16 19:49

@mewtwo ) It is fine. We may cooperate )
Few words of explanation, why I have decided to not deal with these tweaks of yours related to syntax of resident's name: When you analyse protected internal bool TryGetAvatarByName in SceneGraph, then you can notice, that string name that we use as parameter within new llName2Key(string name) is compared with presence.ControllingClient.Name. This comparison, the way how it is constructed, follows ignoring or honoring their case.
The so called "." <- dot is always separator inside FirstName of non-local resident = resident from foreign grid. for example:
John.Smith That could make problem for residents, when they can use "dot" or when not.
Third thing, the word "Resident", for me it is strict SL thing, hard to imagine that opensim grids have been using such syntax: John Resident,, though i can be wrong, but even they use, then it is very individual and requires additional work. Because my friend, how to see the difference between two residents: residentA = John Resident and residentB = John, and we add aritificial SL form Resident, it will not confuse ? hard to imagime for me in OpenSim. In SL i would do the same as you did )
Anyway, if such syntax as you offer is necessary, then I can't see any problem. Thanks for response)
mewtwo0641 (reporter)
2018-09-16 20:31

@Mandarinka Tasty - Those are some excellent points especially on the matters of foreign grid use; I was thinking more along the lines of "expectation of results" from an SL'er point of view when writing the handling for those cases. Perhaps a bit of additional code could be added in to handle strings containing '@' to not do String.Split() in the case of '.' so that foreign grid look ups work as expected?

Something like this:

string[] avName;

    avName = name.Split(' ', '.');

    avName = name.Split(' ');
Mandarinka Tasty (reporter)
2018-09-16 20:46
edited on: 2018-09-16 21:06

@mewtwo ) Feel free to provide with additional patch to make me test it too.

What else, you have noticed my LSL script above, right ? Please write, those situations, when person types usernames ( local and also foreign residents )in
text box. I would like to play it in-world to understand it correctly.
I was testing two no null_keys cases:
1) I have written in text box of my script name of avatar in the form:
Mandarinka Tasty and it correctly returned my UUID.
2) I have written in text box of my script name of my foreign avatar, that came to simualtor in the form:
Mandarinka.Tasty and it also returned correct UUID.

So can you show me example what you would like to type in text box of my LSL script to make me try to understand it why we need additional forms ?

And what might happen, if name of avatar is in form:
John@Smith ? I am asking to see how it can work with your offer: if(!name.Contains('@')) etc. Let's test it )

I have just created avatar in my beta test grid with name:
John@Smith Test, that means: FirstName = John@Smith, LastName = Test.

So filtering it against sign '@' will create problem, because normally we would assume, it can be only used for foreign avatar, but due to my experiment, it is also possible for local account.

mewtwo0641 (reporter)
2018-09-16 22:23

@Mandarinka Tasty - I do have a couple ideas on how to handle the '@' character although I may need a little bit to work out the code and test. I'll post a new patch soon for you to test with. However, I don't currently have a hypergrid setup to test with foreign grid avatars though so I am unable to test with "some" for instance.
BillBlight (developer)
2018-09-16 22:29
edited on: 2018-09-16 23:02

@mewtwo0641, Just to offer, there is a sim with pretty much full build perms on OSGRID that I setup for dev support, it is called Dev Outreach ..

And I am more than happy to test patches there ..

Mandarinka Tasty (reporter)
2018-09-16 22:34

@mewtwo ) Sure, I'll be looking forward your patch. So to make sort of resume:
you would like to type in text box to obtain uuid, not only case:
John Smith, but also John.Smith or only John .

Am i right ? and the same way you want to type in text box cases referring to
foreign grid avatars ? So in other words, you would like to have more possibilities to serve usernames to obtain their uuids.
I'm very precise and that is why I am asking about such details, that may help me to offer my ideas as well.
But also please consider that maybe we could implement analogous form of the function, but not identical one with SL. For instance if one wants to use particular form of input, then maybe filtering should be dealt with in- world script?
BillBlight (developer)
2018-09-16 23:07

@mewtwo, I have applied your second patch to Dev Outreach on OSGRID, with your changes

string[] avName;

    avName = name.Split(' ', '.');

    avName = name.Split(' ');

Appears to be working as expected ..
mewtwo0641 (reporter)
2018-09-16 23:32

@Mandarinka Tasty - Yes that is correct; Mostly I'm just trying to get it close as functionality and results as possible as described in SL Wiki. It's easy enough for me to code for with local accounts but foreign grid accounts throws a bit of a monkey wrench into the plan as we've seen due to the @ character :) And it gets even more complicated when we have to account for more than one @ character (For instance "John@")... As I think about it a bit more though... I am a bit concerned that OpenSim even allows creation of user accounts with @ in it at all as I would think that could cause more problems overall (Especially in hypergrid environments) with name handling... And in fact, from what I can tell, some viewers (Like Firestorm) use the presence of the @ character to denote what grid the account belongs to which is especially important when one has multiple grid accounts with the same name. For example: Test User @ OSGrid, Test User @ Inworldz, Test User @ SomeOtherGrid, etc. So having an extra @ in the name could possibly throw that off from the get go as well. I had some mixed results making account names with @ in it on different viewers as far as even logging in was concerned; so I would think that it would be unwise for a user to make a name like that at all. Though I do admit I haven't thoroughly tested my concerns; at this point it is speculation.

@watcher64 - I do very much appreciate the help with testing :) I did test that bit of code I was suggesting and ran into the issues I explained in my response to Mandarinka so I need to poke at it a bit more.
BillBlight (developer)
2018-09-17 03:48
edited on: 2018-09-17 04:01

I tried this, looks a little sloppy but seems to work, splits at the last occurrence of a @

 string[] avName;
        string[] split = name.Split('@');
        string firstPart = string.Join("@", split.Take(split.Length - 1));
        string lastPart = split.Last();
        name = string.Concat(firstPart, lastPart);
        avName = name.Split(' ', '.');

        avName = name.Split(' ');

Test Result ..

[03:57] llName2Key test whispers:

@ima.test@'s key is: b6d0a9d6-5e7f-422d-8a48-b516371a5907

[04:01] llName2Key test whispers:

Bill Blight's key is: 41b2a682-7288-42e3-9a00-3246fc51dc35

[04:01] llName2Key test whispers:

Bill.Blight's key is: f507a280-c270-11e6-b5ef-00269e0b06c2

mewtwo0641 (reporter)
2018-09-17 05:17
edited on: 2018-09-17 05:22

@watcher64 - I gave your code a test; It's very similar to the idea I had in splitting at the last occurrence of @ and it seems to work mostly, but it does fail in this instance: User with name "Test@ Resident" and checking the name as "Test@.Resident" ... at least with a local account. Checking as "Test@" does seem to work fine though.

I now have an idea to have the code do different variations on string splits depending on how many @ characters are in the name. If there's more than one @ then it should split on the last occurrence and parse the first half of it as normal (String.Split(' ', '.')) then add on the last half as is which would theoretically contain the grid information of the user; If there is only one @ then split it there; if there are no @ chars at all then just string split it as we were originally doing.

Problem I'm running into is... It's difficult to tell the difference between an actual hypergrid name (i.e. "some user @") and a name that has those characters in it just because (i.e. "@.@.@some name@.@.@") for whatever reason someone would want to make a name like that. It might make this easier if there was a way to test if the supplied name is an actual hypergrid user first before performing the string splits and checks. Is there a way to do this?

djphil (reporter)
2018-09-17 06:44
edited on: 2018-09-17 06:51

Not sure i understand the problem but:

@mewtwo0641: If you verify a username (local or HG) with the chart "@" is registred you can know if this user is a hypergrider or not and if split is needed or not, etc ... no ?

BillBlight (developer)
2018-09-17 06:50

@djphil ...

it is possible to have a local account with an @ in the name such as @ima test@ in my example, so therefor simply testing for the @ does not mean it is always a HG user ..
djphil (reporter)
2018-09-17 06:55

Well if this user isn't in the useraccount database, is a hypergrider ...
BillBlight (developer)
2018-09-17 06:56

Yes phil, but these functions check the scene not the database ...
djphil (reporter)
2018-09-17 06:57

Haaaaa, okayyyy. I am silent :)
BillBlight (developer)
2018-09-17 06:58

To me I'd rather just fix it so you can't have a @ in the username ..
BillBlight (developer)
2018-09-17 07:01

LOL @djphil, it would turn into a very heavy call if they had to go search the user accounts db see if the user exists ..

The scene already had the avatar name and UUID so unless wanted to make it take much longer checking the DB on every call is not really a good thing to do.
BillBlight (developer)
2018-09-17 07:15

@mewtwo0641 yeah that is an issue, as the code I tossed out will always split at the last @ so if testing a local account it is gonna freak out a bit, so need to test for it some other way ..

Ok now my brain is smoking, I've over used it today ...
BillBlight (developer)
2018-09-17 07:17
edited on: 2018-09-17 07:18

hmmm could test for and split at the last combo of " @" ...

My brain hurts ...

mewtwo0641 (reporter)
2018-09-17 07:20
edited on: 2018-09-17 07:21

Lol yes, my brain has pretty much turned into jelly for the day over this. So I think I'll take a break for a bit and take a fresh look at it again soon.

Also +1 on the fixing it so @ can't be used in the user name... Seems like it can potentially cause more problems than it's worth it to allow it.

BillBlight (developer)
2018-09-17 08:20

@mewtwo [^]
Mandarinka Tasty (reporter)
2018-09-17 08:30
edited on: 2018-09-17 08:34

I have attached next verision of implementation of that function.
Please test it using my LSL script above with various strings name.

I have verified it with:
1. John Smith
2. John.
3. John
4. John.Smith
5. John.Smith

Let me know if it works for you.

Mandarinka Tasty (reporter)
2018-09-17 08:39
edited on: 2018-09-17 08:39

But in my private opinion, it should be enough that we implement llName2Key, just to obtain userID of resident located in the scene.

And all those syntaxes referring to SL_Wiki, are for SL and chance that it can be used here, is very little. I simly can't see any useful things to write so called '.' = dot, between firstname and lastname. LL has made it, but they do not use such things like HG, they do not use dots, in the way we use for foreign avatars. Also, we all had been working many hours and next, administrator says, that is not necessary to apply ))) But I have liked to test it with you guys)

BillBlight (developer)
2018-09-17 08:45

Nice ..

But I don't think you need to add the @ Back in ..

name = firstPart + " @" + lastPart;

as it is already splitting to the left side of it, ( I think ).
Mandarinka Tasty (reporter)
2018-09-17 08:48

@watcher) It was necessary to add, otherwise, it was not giving UUID.
I hope,i have tested correctly, but it has become little boring i admit )
Please check it. I would like to know if it works also for you )
Mandarinka Tasty (reporter)
2018-09-17 08:51

@ is necessary as a prefix, to recognize account, also stored in region's cache.
Generally my way of splitting transforms to classical forms.

From to John.Smith
Anyway,please test various tricks and let me know. It is good for didactics too.
BillBlight (developer)
2018-09-17 09:14

@Mandarinka Does not appear to be working, testing and it will not return a uuid, says it can't find the agents, local or HG .. going to look closer
Mandarinka Tasty (reporter)
2018-09-17 09:17
edited on: 2018-09-17 09:18

@watcher Pass me string name that you input to obtain uuid.

Certainly, make sure that agents are present in the scene.

BillBlight (developer)
2018-09-17 09:25

I input Bill Blight, I input Bill.Blight and they were staring at each other ..
Mandarinka Tasty (reporter)
2018-09-17 09:31

where i can find you in world ?
Mandarinka Tasty (reporter)
2018-09-17 09:40

I'd like to show you how it should work, on my test region.
BillBlight (developer)
2018-09-17 09:41

I'll be bringing dev outreach on osgrid back up just shortly, I'll be there
BillBlight (developer)
2018-09-17 11:57

Was a minor issue with the patch, fixed now, Mandarinka will be putting up a new one soon ..
Mandarinka Tasty (reporter)
2018-09-17 13:02

I have updated the patch. It's ready for testing.
mewtwo0641 (reporter)
2018-09-17 19:04

Sorry about the silence... I needed to get some sleep :)

Mandarinka, I tested the new version of your patch and it seems to be working rather well with a couple minor snags. I used a similar method of verification that watcher64 used:

Am using two different test accounts: Test@ Resident and Test Resident

Test Resident Results:

Test Resident - Works
Test. - Does not work
Test - Works
Test.Resident - Works

Test@ Resident Results:

Test@ Resident - Works
Test@. - Does not work
Test@ - Does not work
Test@.Resident - Does not work

Still unable to verify foreign grid tests due to lack of proper setup

Names with random @ characters in them still seem to be troublesome but I am starting to think that it is a lot more trouble than it is worth to try to support that
Mandarinka Tasty (reporter)
2018-09-17 23:37
edited on: 2018-09-17 23:38

@mewtwo ) It's ok, I'm glad that you have nicely tested it.
Me and watcher, we have tested following cases:

John Smith

Every test have been successfully verified by us in-world.

You have provided me with next nice tests and i am sure I am able to finish it.
Unless you like to use my method ( nested conditions) to continue, that should be not extremely hard to finish , I hope.

I have decided that the base of method is so called: empty space between FirstName and LastName.
Next, I deal with LastName, if it contains @ or not, I have assumed, that I take last @ in LastName for investigation and then I sequentially go to the left side with logical considerations.

I was creating code in OSGrid and next I was using my avies from my grids to come to the simulator.

I was not creating avies that have only FirstName, so that is probably, that
I have not catched, cases, you have noticed, but again i am sure, that entire solution is very close. I just did not want to create tones of avatars in OSG.

Mandarinka Tasty (reporter)
2018-09-18 17:43
edited on: 2018-09-18 17:44

@mewtwo ) I have prepared another version of our patch, due to your last tests.

Again, I would like you to test all your cases and let me know, which one is discussable.

If you find problematic one, then please provide me with very precise description, ( I'm mathematician, I need very precise words, otherwise I can do not what is expected):

Precise name of the avatar from your database and
precise string that you put in LSL script in world, to obtain UUID.

By the way, I still consider, that our theoretical considerations are interesting from the scientifical point of view, but probability of an event that person can prepare such problematic usernames converges to the zero.
Please notice, that LL in SL do not worry about @ or about other OpenSim differences. So in my private opinion, the best way is as I have introduced in the first patch of mine = OpenSim users will be searching uuids of residents in the sim, just by providing names in the way, as their viewer can show:
John Smith or John.Smith
means, they will always put space between firstName and lastName.
And using dot in the way: FirstName.LastName or only FirstName with assumption, that some grid has made construction of usernames in an identical form as SL did, is, in my opinion, incredibly rare, if possible. ))

But let us continue and finish, I want these researchers of ours be successful.

mewtwo0641 (reporter)
2018-09-18 19:36
edited on: 2018-09-18 19:44

@Mandarinka - Just tested the new patch changes. I did tests in the same manner as my last test with some improved results :) I also added in a third test with a user named @Test@ Resident. As can be seen by the results users with arbitrary @ characters in their name (That is, part of their name, not HG) still gives some issues although the test results there have slightly improved.

I do agree with you that the probability of someone making a name like that is very small and the fact that this isn't worried about at all in SL makes me think that we shouldn't over complicate the code further to try to handle that extremely small chance a scripter might try to write their code to handle llName2Key() in a fashion that would fail (For instance, a scripter trying to use "FirstName." without providing a last name) or the low probability that someone using the script would have @ in their name. In my opinion I think that where we are at presently with the code should be sufficient provided it still handles foreign grid users properly. I believe that it is most important that it handles "FirstName LastName", "FirstName.LastName" and "FirstName" for both local accounts and foreign grid accounts and perhaps just don't worry about the case of names like "@Test@".


Test Resident Results:

Test Resident - Works
Test. - Does not work
Test - Works
Test.Resident - Works

Test@ Resident Results:

Test@ Resident - Works
Test@. - Does not work
Test@ - Works
Test@.Resident - Does not work

@Test@ Resident Results:

@Test@ Resident - Works
@Test@. - Does not work
@Test@ - Works
@Test@.Resident - Does not work

Mandarinka Tasty (reporter)
2018-09-18 19:51

@mewtwo ) Let me make little bit resume concerning your tests.

I. Your account = Test Resident, means FirstName = Test, LastName = Resident
in your tests, it fails in one case, when you put string = Test.
but in my opinion, it is wrong to put string, that contains only FirstName with additional dot.
You should test account Test Resident in only three ways:
Test Resident or Test or Test.Resident,
in my opinion, it is not due to SL. can you check it in SL too ?
I can eventually check it on avies in SL too.

II. Your account = Test@ Resident,
here you fail on case: Test@. and that is also wrong input as above.

and you also fail with Test@.Resident, here i can agree, so i correct it.

III your account = @Test@ Resident,

Here is analogously to case II, @Test@.Resident, i correct, but
@Test@. as above, should not be tested in my opinion.

Resume, we should test only for cases:

a) FirstName LastName
b) FirstName.LastName
c) FirstName

but not FirstName.
how do you think? you agree?
Mandarinka Tasty (reporter)
2018-09-18 19:53

@mewtwo ) Let me know, then i start to code )
mewtwo0641 (reporter)
2018-09-18 20:04
edited on: 2018-09-18 20:10

@Mandarinka - I only included the "Firstname." as a test because that was one of the tests that you and watcher64 did previously :) But I did go to SL and test and it does work... However I noticed something odd in my testing there. "FirstName." works but so does "FirstName.R" , and "FirstName.Re", and "FirstName.Res", etc. So that suggests to me that on SL, they're either doing a substring match (or possibly RegEx match) instead of full word matches or they're dropping the second half of the name entirely if testing for one of those cases fails and then test again using only the first name. So very possibly "FirstName." is actually failing on SL but we just don't see that because they are dropping the '.' or the ' ' (space) and every thing after it and testing again with just "FirstName". Interestingly "FirstNa" variants does NOT work there so I think that substring match is less likely and dropping everything after the '.' or ' ' and re-testing is more likely.

Long story short... I am now thinking that on SL, they test the case of "Resident" last names, so they automatically just drop the '.', the ' ', and the last name and test for that, very first thing. If that fails, then they fall back to testing with last name.

Mandarinka Tasty (reporter)
2018-09-18 20:09

@mewtwo ) Ok. you know, i have coded all with my rule:

Mandarinka Tasty

But I was not considering, that I should have put
Mandarinka. I hope we do understand each other. do we ?
I did not test case, when I use FirstName with additional suffix "."

Should I ?
Mandarinka Tasty (reporter)
2018-09-18 20:12

@mewtwo) In other words, tell me precisely, what we both need to correct ))
mewtwo0641 (reporter)
2018-09-18 20:15
edited on: 2018-09-18 20:16

@Mandarinka - Sorry, I made a couple edits to my previous post in the past couple minutes :) But I would suggest making a rule exception for people with "Resident" in their name, and automatically drop the '.', ' ' (space), and the entire last name and just test "FirstName" in that instance. Any other last name other than "Resident" doesn't get that treatment (This is also verified on SL because I don't see that anomaly with non "Resident" last names, it gives NULL_KEY as expected in that case)

Mandarinka Tasty (reporter)
2018-09-18 20:16

@mewtwo ) Due to my logics, we use symbol "." only to put it between FirstName and LastName, that means, we use dot symbol, this way:

FirstName.LastName , but we should not use it in the form:

FirstName+"." = "FirstName." even if in sl it works, it is very illogical for me. there appears question, for what to complicate and write:
"FirstName." if it is easier to write "FirstName" ?
mewtwo0641 (reporter)
2018-09-18 20:20
edited on: 2018-09-18 20:21

@Mandarinka - I don't think it's so much that SL accepts "FirstName." as it is that it just appears to work like that when the name being tested has "Resident" as their last name because it appears that they're just dropping that automatically because there is no point in testing for last name at all if the last name is "Resident". It's just a side effect that "FirstName." seems to work in the case of "Resident" last name because of that automatic last name drop. This doesn't work in the case with people who have actual last names in the case of legacy accounts. So I think that ultimately, we shouldn't worry about someone trying to test for "FirstName."

Mandarinka Tasty (reporter)
2018-09-18 20:23

@mewtwo) Ok. I go back to the coding, then. When I'm ready, I publish the patch and we continue testing )
mewtwo0641 (reporter)
2018-09-18 20:25

@Mandarinka - Alright :) May I suggest though, just in the spirit of keeping this "SL compatible", Just do a simple test for

  //Drop every thing after the '.' and ' '
  //And just test it as if the scripter provided "FirstName"
BillBlight (developer)
2018-09-18 20:32
edited on: 2018-09-18 20:32

Problem with that type of test mewtwo is in opensim someone could create Firstname Resident. ..

Or Firstname. Resident.

mewtwo0641 (reporter)
2018-09-18 20:38
edited on: 2018-09-18 20:38

@watcher64 - This is true... Had not thought of that. Perhaps it might be better overall to not try to account for cases of "FirstName" + "." (Or, "FirstName."); since this sort of test appears to be an anomaly unique to SL in the case of "Resident" last names and doesn't work like that anyway with legacy account names?

Mandarinka Tasty (reporter)
2018-09-18 20:41

@mewtwo) Exactly, that I have written about earlier ))

Let us establish together one thing ultimately:
we test local accounts ( foreign we did ) in three cases:
a) FirstName LastName
b) FirstName.LastName
c) FirstName
mewtwo0641 (reporter)
2018-09-18 20:45

@Mandarinka - That looks good to me :) I think those three cases listed are the most important to check for and we should stick with that.
BillBlight (developer)
2018-09-18 20:47

Cases out side of this is exactly why I submitted that patch to disallow certain characters in the name, would end up chasing our tails trying to account for every case possible ..

I mean First$name%is@@@Goofy AndMy%#@#Last....%&%$isworse
mewtwo0641 (reporter)
2018-09-18 21:01

@watcher64 - I would hope no one tried to make a name like that LOL! That looks like a nightmare. But agreed; trying to account for all cases would be an uphill battle to say the least.
Mandarinka Tasty (reporter)
2018-09-18 22:12

@mewtwo ) New version of the patch has been uploaded :)

Please check your tests:
Test Resident

Test Resident

Test@ Resident

Test@ Resident

@Test@ Resident

@Test@ Resident
@Test@ - Works

And let me know )
mewtwo0641 (reporter)
2018-09-18 23:10
edited on: 2018-09-18 23:11

@Mandarinka - I ran a new series of tests on the new code; I also added in a "Test User" this time to test for non "Resident" last names. Everything looks good :)

I would like to point out there is a minor hiccup though in testing "FirstName" only... It appears that if there is more than one user in the region with the same first name (Like Test User and Test Resident) it tends to get confused an can return the wrong UUID although I would expect that since it gets into the realm of ambiguity; but as long as both first and last names are provided it seems to return the correct UUID.

Test User Results:

Test User - Works
Test - Works
Test.User - Works

Test Resident Results:

Test Resident - Works
Test - Works
Test.Resident - Works

Test@ Resident Results:

Test@ Resident - Works
Test@ - Works
Test@.Resident - Works

@Test@ Resident Results:

@Test@ Resident - Works
@Test@ - Works
@Test@.Resident - Works

Mandarinka Tasty (reporter)
2018-09-18 23:19

@mewtwo ) I'm glad. So then maybe also to give up possibility to check only FirstName?
And only check "FirstName LastName' and "FirstName.LastName"
What do you think? this problem as you have found in here, does not exist in SL, since, there are not two accounts with same FirstName and LastName = Resident
mewtwo0641 (reporter)
2018-09-18 23:28

@Mandarinka - I think it would be fine to leave the "FirstName" only tests as-is and leave it up to the scripter to decide what works best for them. It would (should) be apparent to them rather quick what's happening if they happen to run into duplicate first names, which is, an ambiguity issue.

I'm unsure how SL handles that as the case for running into duplicate first names is pretty slim now that legacy names are no longer a thing (That is, we can't have a "User Resident" and another "User Resident") but there is always a chance there could be two legacy name accounts out there with the same first names and scripts on SL would have to account for that ambiguity anyway. I think that if we omit the "FirstName" only tests entirely from our code then it would break the scripter expectation for that to work as expected.
Mandarinka Tasty (reporter)
2018-09-18 23:45

@mewtwo ) Well, I again , remind what I think, how SL implementation should be applied in OpenSim.
In my opinion, an implementations can be analogous, but not identical, not exactly mirrors, ok?
Our environment is different, also, OpenSim is not one grid, but just a concept, where everyone can have various environments.

Also, we do not work for LL, right? If we had identical system of creating usernames with special LastName="Resident" etc etc, then we can try to make it with precision to the isomorphism )) But we do not own such system, even if one of us, like you, create such isomorphic clone of SL in aspect of LSL, then other ones can have different platforms and, ideas of yours will conflict with them.
Scripter, the person, you have mentioned above, should be intelligent, if he/she realises that UUID of assets are different, then also should realise, that some parameters that feed scripts may also vary.

In SL, when only firstname is provided with, then server searches avatar with usename = "FirstName Resident". it is not possible due to other meaning of the word Resident in our context, as also Watcher has noticed.
Scripter, rather, should create his/her script to satisfy all potential users of the script. That is how i think. Let us not take work from him/her ))

i have started to clean the code up, to make it more elegant, probably I use private helper string to do some work outside the function.

Please consider that ) I think about it too.

Also , in the meantime, i have written entire code for new function:
llRequestUserKey(string username) but i decided to wait with publishing, before we establish everything here with those game with strings of names ))
mewtwo0641 (reporter)
2018-09-18 23:57

@Mandarinka - I understand :) Those were just my thoughts on it but if overall it would be better not to support "FirstName" testing due to differences in how OS and SL handles account names then it is probably for the best... It isn't too hard to supply the first and last name in scripts anyway.

At this point I think we're just advocating for allowing scripters to be somewhat lazy in only checking for the first name ;) ... I'm kidding mostly lol.

Now that I think on it a bit more I believe that is the best course of action in this instance. It is probably better to require both first and last name than make assumptions based only on providing the first name.
Mandarinka Tasty (reporter)
2018-09-19 00:09

@mewtwo ) yes )I have even created such construction on my mind.
I could eventually make it work in such way:

if only FirstName is provided, then server automatically adds LastName = Resident, that would mean, you could test only Test Resident with providing only FirstName=Test, so your Test User would not conflict.
And if you would like to obtain uuid of Test User, then you would need to provide: Test User or Test.User

i can do that, but it is only for local accounts.
because when foreing avatar comes to our simulator, then he or she , at once, gets FirstName = Test.Resident or Test.User
what do then? if we can't know without uuid, whether avie came from HG or is local with @ inside the name?
So we would need to tell users, that firstname they can use only if they want to obtain uuid of local, when LastName=Resident, but in case of foreign avatar, they can only write:
Test.Resident or

can you see? that would mean much more stress in my opinion, not telling about other crazy cases.
Foreign avatars make problem for us within play of playing only with FirstName, since they FirstName consists of their home FirstName.LastName
)) So let us make it simple.
mewtwo0641 (reporter)
2018-09-19 00:35

@Mandarinka - Yes, I think the fact that we have special handling for HG names does complicate things a bit as far as FirstName handling goes. I am leaning towards in the interest of keeping things simple and preserving our sanity; let's require supplying first name and last name into the llName2Key() method and not worry about handling handling implied "Resident" last name.

I am fairly certain OpenSim requires specifying a last name upon account creation so there should not be any instances of people that truly do only have a first name, correct? Maybe make a note in the OS Wiki for compatibility of the function that "FirstName" is unsupported for these reasons?
Mandarinka Tasty (reporter)
2018-09-19 00:51

@newtwo ) LastName if not provided, it takes default form "User"
so in other words, some similarity of SL "Resident", plays "User" here.

So in future, local accounts, could work with "User" in analogous way as "Resident" in SL, does.
I prepare the version of the patch, referring forms:
"FirstName LastName' , "FirstName.LastName"
Sure you may write about lack of support of "FirstName" only case.
But do not forget, that our patch needs to be applied to the master before you describe all nicely) Otherwise, it has only theoretical meaning.
mewtwo0641 (reporter)
2018-09-19 01:01

@Mandarinka - That sounds good :) I'm not opposed to future expansion on it of course, but for now, I think we have the code and preliminary test results in a good position in my opinion.
Mandarinka Tasty (reporter)
2018-09-19 21:22
edited on: 2018-09-19 21:23

@mewtwo ) I have written, final version of our patch, using private string Name2Key(string name)

I've tested it, but if you could also repeat tests of yours, I'd be grateful )

Due to our agreement, two cases have been taken under consideration.

a) "FirstName LastName"
b) "FirstName.LastName"

mewtwo0641 (reporter)
2018-09-20 00:31

@Mandarinka - I tested the new patch out with good results :)

Test Results:

(Note that where they say 'Works' on this note, on OS, they show the valid UUID of the user, I just hand-replaced those IDs with 'Works' for privacy)

[00:26] Object: Test User3: Works
[00:26] Object: test user3: Works
[00:26] Object: Test.User3: Works
[00:26] Object: test.user3: Works

[00:26] Object: Test Resident: Works
[00:26] Object: test resident: Works
[00:26] Object: Test.Resident: Works
[00:26] Object: test.resident: Works

[00:26] Object: Test@ Resident: Works
[00:26] Object: test@ resident: Works
[00:26] Object: Test@.Resident: Works
[00:26] Object: test@.resident: Works

[00:26] Object: @Test@ Resident: Works
[00:26] Object: @test@ resident: Works
[00:26] Object: @Test@.Resident: Works
[00:26] Object: @test@.resident: Works

I just tested single FirstName for posterity (To make sure OS doesn't freak out or anything ;) ) and it returns NULL_KEY as expected due to patch changes

[00:30] Object: Test: 00000000-0000-0000-0000-000000000000
[00:30] Object: test: 00000000-0000-0000-0000-000000000000
[00:30] Object: Test: 00000000-0000-0000-0000-000000000000
[00:30] Object: test: 00000000-0000-0000-0000-000000000000
BillBlight (developer)
2018-09-20 00:34

I went a little different route, attached my patch ..

(hope the patch works as I had to manually fix it for master code)
BillBlight (developer)
2018-09-20 00:36

I'll most likely scrap my patch and go with the other one, but put mine here just for "completeness" of the discussion ..
mewtwo0641 (reporter)
2018-09-20 00:43

@watcher64 - I repeated my previous tests with your version of the patch and got some mixed results

Test Results:

[00:42] Object: Test User3: Works
[00:42] Object: test user3: Works
[00:42] Object: Test.User3: Works
[00:42] Object: test.user3: Works

[00:42] Object: Test Resident: Works
[00:42] Object: test resident: Works
[00:42] Object: Test.Resident: Works
[00:42] Object: test.resident: Works

[00:42] Object: Test@ Resident: Works
[00:42] Object: test@ resident: Works
[00:42] Object: Test@.Resident: Does not work
[00:42] Object: test@.resident: Does not work

[00:42] Object: @Test@ Resident: Works
[00:42] Object: @test@ resident: Works
[00:42] Object: @Test@.Resident: Does not work
[00:42] Object: @test@.resident: Does not work
BillBlight (developer)
2018-09-20 00:45

Yeah, I was just re-testing, as you posted that ... I think I'm just going to go with Mandarinka's final patch ..
mewtwo0641 (reporter)
2018-09-20 00:45
edited on: 2018-09-20 00:55

@Everyone - I made a "semi-auto" tester script to test various different name scenarios to make it a little quicker to test. Just change the name variable at the top

It tests FirstName LastName, FirstName.Lastname, firstname lastname, and firstname.lastname (forced lower case as the function is supposed to be non case sensitive)


string name = "Test User"; //Change this to name of agent to test for

string strReplace(string str, string search, string replace)
   return llDumpList2String(llParseStringKeepNulls(str, [search], []), replace);

string Name2Key(key name)
    if(llName2Key(name) != NULL_KEY)
        return "Works";
        return "Does not work / NULL_KEY";

        llSay(0, name + ": " + Name2Key(name));
        llSay(0, llToLower(name) + ": " + Name2Key(llToLower(name)));
        llSay(0, strReplace(name, " ", ".") + ": " + Name2Key(strReplace(name, " ", ".")));
        llSay(0, llToLower(strReplace(name, " ", ".")) + ": " + Name2Key(llToLower(strReplace(name, " ", "."))));

BillBlight (developer)
2018-09-20 01:30

It's a little long winded and a bit sloppy but this is what I am testing with after modding it from what @mewtwo posted , don't have to edit the script, best of both test scripts ..


integer a;
integer chan;
key newtoucher;
key toucher0;
integer mDlisten;
string query;
string strReplace(string str, string search, string replace)
   return llDumpList2String(llParseStringKeepNulls(str, [search], []), replace);

string Name2Key(key name)
    if(llName2Key(name) != NULL_KEY)
        return "Works";
        return "Does not work";

doit(string name)
            llSay(0, name + ": " + Name2Key(name));
        llSay(0, llToLower(name) + ": " + Name2Key(llToLower(name)));
        llSay(0, strReplace(name, " ", ".") + ": " + Name2Key(strReplace(name, " ", ".")));
        llSay(0, llToLower(strReplace(name, " ", ".")) + ": " + Name2Key(llToLower(strReplace(name, " ", "."))));
        llSetText("llName2Key Test box!\n\n CLICK ME and enter avatar name!", <0,1,0>,1);
    touch_start(integer num)
    { query="";
        newtoucher = llDetectedKey(num);
        if(a == 0)
            llSetText("llName2Key Test box!\nBUSY!\n Enter avatar name!\nin Text Box.", <0,1,0>,1);
            chan = (integer)llFrand(DEBUG_CHANNEL) * -1;
            toucher0 = llDetectedKey(0);
            mDlisten = llListen(chan,"",toucher0,"");
            llTextBox(toucher0,"\nTo receive the user's key\nplease type resident's name in a box below:\n",chan);
            if(llDetectedKey(0) != toucher0)
                newtoucher = llDetectedKey(0);
                llInstantMessage(llDetectedKey(0),"Please wait a moment. Busy with another user.\n");
    listen(integer Channel,string Name,key ID,string Text)
        key user = llName2Key(Text);
        query = Text;
        if(user != NULL_KEY)
            llSetText("llName2Key Test box!\n\n Last Avatar Query\n"+Text+"\n SUCESS!!", <0,1,0>,1);
            mDlisten = -1;
            toucher0 = NULL_KEY;
            llWhisper(0,"\n\nResident: "+Text+" doesn't exist in the scene.\n");
        llSetText("llName2Key Test box!\n\n Last Avatar Query\n"+Text+"\n FAILED,\nDID NOT EXIST IN SCENE!!", <0,1,0>,1);
        mDlisten = -1;
        toucher0 = NULL_KEY;

        if(mDlisten != -1 && toucher0 != "")llInstantMessage(toucher0,"\n\nSession has expired. Try again later.\n");
        if(mDlisten != -1 && newtoucher != "")llInstantMessage(newtoucher,"Menu Now Available");
        if(query=="")llSetText("llName2Key Test box!\n\n CLICK ME and enter avatar name!\nLast Query\nSession Expired", <0,1,0>,1);
        toucher0 = "";
        newtoucher = "";
        a = 0;


BillBlight (developer)
2018-09-20 01:36

I did test a hypergrid name ..

[01:35] llName2Key test: Bill.Blight Works
[01:35] llName2Key test: bill.blight Works
[01:35] llName2Key test: Works
[01:35] llName2Key test: Works
Mandarinka Tasty (reporter)
2018-09-20 08:47

@mewtwo, @watcher ) Thank you for your tests confirming that the code works appropriately. I'm grateful )
Mandarinka Tasty (reporter)
2018-09-21 22:28

@ mewtwo, @watcher ) I have prepared another yet, version of our patch.
I have simplified the code again. It supports our both cases:
"FirstName LastName" and "FirstName.LastName" for local and foreign avatars.
That construction of mine entirely eliminates the probability of false negatives, even for the weirdest names of residents located in the scene.

My tests have been successful, if you could confirm that, I'd be very happy.
BillBlight (developer)
2018-09-21 23:11

Tested with local and HG,

[23:10] llName2Key test: Bill.Blight Works
[23:10] llName2Key test: bill.blight Works
[23:10] llName2Key test: Works
[23:10] llName2Key test: Works

Wow that is so much simpler ... We were really over thinking it ...
Mandarinka Tasty (reporter)
2018-09-21 23:14

@watcher ) Thank you for your tests. You know, sometimes, we need to blow up the door, before, we create elegant, subtle key to enter)
mewtwo0641 (reporter)
2018-09-21 23:26

@Mandarinka - Wow! That a lot simpler! I ran my previous tests on the new patch and got great results.

Test Results:

[23:22] Object: Test User: Works
[23:22] Object: test user: Works
[23:22] Object: Test.User: Works
[23:22] Object: test.user: Works

[23:23] Object: Test Resident: Works
[23:23] Object: test resident: Works
[23:23] Object: Test.Resident: Works
[23:23] Object: test.resident: Works

[23:23] Object: Test@ Resident: Works
[23:23] Object: test@ resident: Works
[23:23] Object: Test@.Resident: Works
[23:23] Object: test@.resident: Works

[23:23] Object: @Test@ Resident: Works
[23:23] Object: @test@ resident: Works
[23:23] Object: @Test@.Resident: Works
[23:23] Object: @test@.resident: Works

(Tested 'FirstName' only just to ensure nothing crashes or get unexpected results; So works as expected)
[23:23] Object: @Test@: Does not work
[23:23] Object: @test@: Does not work
[23:23] Object: @Test@: Does not work
[23:23] Object: @test@: Does not work
Mandarinka Tasty (reporter)
2018-09-21 23:34

@mewtwo ) Thank you for your tests too. I do appreciate that )
mewtwo0641 (reporter)
2018-09-21 23:37

@Mandarinka - Very welcome, happy to help :)
UbitUmarov (administrator)
2018-10-23 14:14

Patch on master with a few changes: npcs are found, Child agents are not.
if there are several npcs with same name, first is returned and that may be wrong
But this is a bug elsewhere. NPCss with same name should not be allowed because we only have usernames and those should be unique.

- Issue History
Date Modified Username Field Change
2018-09-13 03:56 djphil New Issue
2018-09-13 14:56 idb Assigned To => idb
2018-09-13 14:56 idb Status new => assigned
2018-09-13 14:56 idb Assigned To idb =>
2018-09-13 14:59 idb Status assigned => new
2018-09-16 08:58 mewtwo0641 File Added: 0001-Implement-llName2Key.patch
2018-09-16 08:59 mewtwo0641 Note Added: 0032949
2018-09-16 08:59 mewtwo0641 Status new => patch included
2018-09-16 10:06 BillBlight Note Added: 0032950
2018-09-16 14:08 Mandarinka Tasty File Added: 0001-Mandarinka-concept-of-llName2Key.patch
2018-09-16 14:13 Mandarinka Tasty Note Added: 0032951
2018-09-16 14:13 Mandarinka Tasty Note Edited: 0032951 View Revisions
2018-09-16 14:14 Mandarinka Tasty Note Edited: 0032951 View Revisions
2018-09-16 14:52 Mandarinka Tasty Note Added: 0032952
2018-09-16 14:57 Mandarinka Tasty Note Edited: 0032952 View Revisions
2018-09-16 14:58 Mandarinka Tasty Note Edited: 0032952 View Revisions
2018-09-16 19:21 mewtwo0641 File Added: 0001-Implement-llName2Key-with-suggestions-by-Mandarinka-.patch
2018-09-16 19:24 mewtwo0641 Note Added: 0032953
2018-09-16 19:49 Mandarinka Tasty Note Added: 0032954
2018-09-16 20:31 mewtwo0641 Note Added: 0032955
2018-09-16 20:46 Mandarinka Tasty Note Added: 0032956
2018-09-16 21:06 Mandarinka Tasty Note Edited: 0032956 View Revisions
2018-09-16 22:23 mewtwo0641 Note Added: 0032958
2018-09-16 22:29 BillBlight Note Added: 0032959
2018-09-16 22:29 BillBlight Note Edited: 0032959 View Revisions
2018-09-16 22:34 Mandarinka Tasty Note Added: 0032960
2018-09-16 23:02 BillBlight Note Edited: 0032959 View Revisions
2018-09-16 23:07 BillBlight Note Added: 0032961
2018-09-16 23:32 mewtwo0641 Note Added: 0032962
2018-09-17 03:48 BillBlight Note Added: 0032963
2018-09-17 03:57 BillBlight Note Edited: 0032963 View Revisions
2018-09-17 03:59 BillBlight Note Edited: 0032963 View Revisions
2018-09-17 04:01 BillBlight Note Edited: 0032963 View Revisions
2018-09-17 05:17 mewtwo0641 Note Added: 0032964
2018-09-17 05:22 mewtwo0641 Note Edited: 0032964 View Revisions
2018-09-17 06:44 djphil Note Added: 0032965
2018-09-17 06:48 BillBlight Note Added: 0032966
2018-09-17 06:49 BillBlight Note Edited: 0032966 View Revisions
2018-09-17 06:50 BillBlight Note Added: 0032967
2018-09-17 06:51 djphil Note Edited: 0032965 View Revisions
2018-09-17 06:53 BillBlight Note Deleted: 0032966
2018-09-17 06:55 djphil Note Added: 0032968
2018-09-17 06:56 BillBlight Note Added: 0032969
2018-09-17 06:57 djphil Note Added: 0032970
2018-09-17 06:58 BillBlight Note Added: 0032971
2018-09-17 07:01 BillBlight Note Added: 0032972
2018-09-17 07:15 BillBlight Note Added: 0032973
2018-09-17 07:17 BillBlight Note Added: 0032974
2018-09-17 07:18 BillBlight Note Edited: 0032974 View Revisions
2018-09-17 07:20 mewtwo0641 Note Added: 0032975
2018-09-17 07:21 mewtwo0641 Note Edited: 0032975 View Revisions
2018-09-17 08:20 BillBlight Note Added: 0032977
2018-09-17 08:26 Mandarinka Tasty File Added: 0001-llName2Key-next-version.patch
2018-09-17 08:30 Mandarinka Tasty Note Added: 0032978
2018-09-17 08:34 Mandarinka Tasty Note Edited: 0032978 View Revisions
2018-09-17 08:39 Mandarinka Tasty Note Added: 0032979
2018-09-17 08:39 Mandarinka Tasty Note Edited: 0032979 View Revisions
2018-09-17 08:45 BillBlight Note Added: 0032980
2018-09-17 08:48 Mandarinka Tasty Note Added: 0032981
2018-09-17 08:51 Mandarinka Tasty Note Added: 0032982
2018-09-17 09:14 BillBlight Note Added: 0032983
2018-09-17 09:17 Mandarinka Tasty Note Added: 0032984
2018-09-17 09:18 Mandarinka Tasty Note Edited: 0032984 View Revisions
2018-09-17 09:25 BillBlight Note Added: 0032985
2018-09-17 09:31 Mandarinka Tasty Note Added: 0032986
2018-09-17 09:40 Mandarinka Tasty Note Added: 0032987
2018-09-17 09:41 BillBlight Note Added: 0032988
2018-09-17 11:57 BillBlight Note Added: 0032989
2018-09-17 13:00 Mandarinka Tasty File Deleted: 0001-llName2Key-next-version.patch
2018-09-17 13:00 Mandarinka Tasty File Added: 0001-llName2Key-next-version.patch
2018-09-17 13:02 Mandarinka Tasty Note Added: 0032990
2018-09-17 19:04 mewtwo0641 Note Added: 0032992
2018-09-17 23:37 Mandarinka Tasty Note Added: 0032993
2018-09-17 23:38 Mandarinka Tasty Note Edited: 0032993 View Revisions
2018-09-18 17:31 Mandarinka Tasty File Deleted: 0001-llName2Key-next-version.patch
2018-09-18 17:32 Mandarinka Tasty File Added: 0001-llName2Key-another-version-with-mewtwo0641-suggestio.patch
2018-09-18 17:43 Mandarinka Tasty Note Added: 0032996
2018-09-18 17:43 Mandarinka Tasty Note Edited: 0032996 View Revisions
2018-09-18 17:44 Mandarinka Tasty Note Edited: 0032996 View Revisions
2018-09-18 19:36 mewtwo0641 Note Added: 0032997
2018-09-18 19:44 mewtwo0641 Note Edited: 0032997 View Revisions
2018-09-18 19:51 Mandarinka Tasty Note Added: 0032998
2018-09-18 19:53 Mandarinka Tasty Note Added: 0032999
2018-09-18 20:04 mewtwo0641 Note Added: 0033000
2018-09-18 20:07 mewtwo0641 Note Edited: 0033000 View Revisions
2018-09-18 20:08 mewtwo0641 Note Edited: 0033000 View Revisions
2018-09-18 20:09 Mandarinka Tasty Note Added: 0033001
2018-09-18 20:10 mewtwo0641 Note Edited: 0033000 View Revisions
2018-09-18 20:12 Mandarinka Tasty Note Added: 0033002
2018-09-18 20:15 mewtwo0641 Note Added: 0033003
2018-09-18 20:16 Mandarinka Tasty Note Added: 0033004
2018-09-18 20:16 mewtwo0641 Note Edited: 0033003 View Revisions
2018-09-18 20:20 mewtwo0641 Note Added: 0033005
2018-09-18 20:21 mewtwo0641 Note Edited: 0033005 View Revisions
2018-09-18 20:23 Mandarinka Tasty Note Added: 0033006
2018-09-18 20:25 mewtwo0641 Note Added: 0033007
2018-09-18 20:32 BillBlight Note Added: 0033008
2018-09-18 20:32 BillBlight Note Edited: 0033008 View Revisions
2018-09-18 20:38 mewtwo0641 Note Added: 0033009
2018-09-18 20:38 mewtwo0641 Note Edited: 0033009 View Revisions
2018-09-18 20:41 Mandarinka Tasty Note Added: 0033010
2018-09-18 20:45 mewtwo0641 Note Added: 0033011
2018-09-18 20:47 BillBlight Note Added: 0033012
2018-09-18 21:01 mewtwo0641 Note Added: 0033013
2018-09-18 22:09 Mandarinka Tasty File Deleted: 0001-llName2Key-another-version-with-mewtwo0641-suggestio.patch
2018-09-18 22:09 Mandarinka Tasty File Added: 0001-llName2Key-with-mewtwo0641-suggestions.patch
2018-09-18 22:12 Mandarinka Tasty Note Added: 0033014
2018-09-18 23:10 mewtwo0641 Note Added: 0033015
2018-09-18 23:11 mewtwo0641 Note Edited: 0033015 View Revisions
2018-09-18 23:19 Mandarinka Tasty Note Added: 0033016
2018-09-18 23:28 mewtwo0641 Note Added: 0033017
2018-09-18 23:45 Mandarinka Tasty Note Added: 0033018
2018-09-18 23:57 mewtwo0641 Note Added: 0033019
2018-09-19 00:09 Mandarinka Tasty Note Added: 0033020
2018-09-19 00:35 mewtwo0641 Note Added: 0033021
2018-09-19 00:51 Mandarinka Tasty Note Added: 0033022
2018-09-19 01:01 mewtwo0641 Note Added: 0033023
2018-09-19 02:25 mewtwo0641 File Deleted: 0001-Implement-llName2Key.patch
2018-09-19 02:26 mewtwo0641 File Deleted: 0001-Implement-llName2Key-with-suggestions-by-Mandarinka-.patch
2018-09-19 21:17 Mandarinka Tasty File Deleted: 0001-llName2Key-with-mewtwo0641-suggestions.patch
2018-09-19 21:17 Mandarinka Tasty File Added: 0001-llName2Key-with-mewtwo0641-suggestions.patch
2018-09-19 21:22 Mandarinka Tasty Note Added: 0033025
2018-09-19 21:23 Mandarinka Tasty Note Edited: 0033025 View Revisions
2018-09-20 00:31 mewtwo0641 Note Added: 0033026
2018-09-20 00:33 BillBlight File Added: llName2KeyBB.patch
2018-09-20 00:34 BillBlight Note Added: 0033027
2018-09-20 00:36 BillBlight Note Added: 0033028
2018-09-20 00:43 mewtwo0641 Note Added: 0033029
2018-09-20 00:45 BillBlight Note Added: 0033030
2018-09-20 00:45 mewtwo0641 Note Added: 0033031
2018-09-20 00:55 mewtwo0641 Note Edited: 0033031 View Revisions
2018-09-20 01:30 BillBlight Note Added: 0033032
2018-09-20 01:36 BillBlight Note Added: 0033033
2018-09-20 08:47 Mandarinka Tasty Note Added: 0033037
2018-09-21 22:23 Mandarinka Tasty File Added: 0001-llName2Key.-Thanks-to-mewtwo0641-and-watcher64.patch
2018-09-21 22:28 Mandarinka Tasty Note Added: 0033043
2018-09-21 23:11 BillBlight Note Added: 0033044
2018-09-21 23:14 Mandarinka Tasty Note Added: 0033045
2018-09-21 23:26 mewtwo0641 Note Added: 0033046
2018-09-21 23:34 Mandarinka Tasty Note Added: 0033047
2018-09-21 23:37 mewtwo0641 Note Added: 0033048
2018-09-21 23:38 Mandarinka Tasty File Deleted: 0001-llName2Key-with-mewtwo0641-suggestions.patch
2018-09-26 06:37 Fly-Man- Summary [SCRIPT FUNCTION] llName2Key not implemented => [PATCH] llName2Key not implemented
2018-10-23 14:14 UbitUmarov Note Added: 0033258
2018-10-23 14:14 UbitUmarov Status patch included => closed
2018-10-23 14:14 UbitUmarov Assigned To => UbitUmarov
2018-10-23 14:14 UbitUmarov Resolution open => fixed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker