Jump to content

Felicia Silversmith

Resident
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Felicia Silversmith

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes i did of course. But Chaser havnt readed my text accurately. AgentUpdate message already sent and i do not send RegionHandshakeReply message because i dont get RegionHandshake message from server. I was trying to send RegionHandshakeReply without recieving RegionHandshake, but no relults. As for me, i think problem can be in RegionHandshake, but i am not sure. I've added AgentThrottle with 0x00 0x00 throttle. It fixed one issue at least. Now viewer recieve chat messages from local. But by some strange way. First empty message comes from with zero length, then message avatar near actually typed and then empty message again. AgentFOV and AgentWidthHeight messages do not affect anything. But there are some issues: Avatar still flying above floor Here is ComplereAvatarMovement message sample (session and circuit code can be different from run to run): 00 - flags 00 00 00 02 - sequence number 00 - no extra bytes FF FF 00 F9 - message code ( Low 249 - CompleteAvatarMovement ) 1F BA 15 93 1D 4E 48 CC B2 A4 A5 98 DC 84 D8 6C - agent UUID 16 C3 DF F6 F7 42 42 F2 94 8E 25 75 0A 4F C8 6D - session UUID 9B AC 52 3B - curcuit code Instead instant messages viewer recieve TestMessage ChatFromViewer message dont work Here is message before zero encodind of data part: 80 - flags (zerocoded) 00 00 00 06 - sequence number 00 - no extra bytes in header FF FF 00 50 - message ID ( Low 80 - ChatFromViewer ) 1F BA 15 93 1D 4E 48 CC B2 A4 A5 98 DC 84 D8 6C - agent ID 16 C3 DF F6 F7 42 42 F2 94 8E 25 75 0A 4F C8 6D - session ID 0D 00 - text length 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 - "Hello world!" text 01 - say normal 00 00 00 00 - channel 0 Of course before sending to server data part zero encoded. Result - silience in sim. So, is it bug or not, when correct message sent to simulator do not work?
  2. Whirly. Not helpful at all unfortunately. Huge amount of somebody's not commented code. To be honest i do not understand why during 10 years Linden Lab can not create normal documentation of protocol. I havnt found in wiki list of messages from server that should be replyed by viewer I havnt found in wiki UDP sequence to init normal agent presence in world Most wiki pages about separate messages looks like copies from messages.msg file and only some of them have tiny amount of additional info. It is not code bug. But it is documenting bug for sure. I know that there are tonns of opensource code: SL Viewer sourse, PyOGP and so on. But almost all of them have terrible commented code. About using OpenMetaverse lib or something like this for text viewer. It is like using huge truck to tranport single little bottle of milk. So, question is still open. Can somebody give login and presence inworld flow?
  3. Grettings. I've started to create tiny text viewer for making program controlled NPC in Second Life. Right now viewer making following Authentication Flow: 1. It sends SSL HTTP request to log in to Second Life and get necessary info for future work. 2. Viewer sends several UDP messages to Second Life sim server: UseCircuitCode CompleteAgentMovement SendAgentUpdate SendUUIDNameRequest 3. After that viewer works in loop where right now it just sending CompletePingCheck message as response to StartPingCheck message from sim. Agent staying online, but there are some problems: 1. Avatar flying in air above floor instead to stay on it 2. Viewer do not get RegionHandshake message from sim server 3. Viewer do not get chat and IM UDP messages when i type something in local near agent or sending IMs to it. 4. Simple UDP messages from viewer i've tryied to send like MoneyBalanceRequest or ChatFromViewer do not work. I do understand that its probably not a sim bug but may be you can tell correct sequence of UDP messages to make avatar stay correctly in Second Life and be able to use UDP commands. Thanks a lot. With best regards, Felicia Silversmith.
  4. I am not sure changing texture with script is a perfect decision. First of all you can not define by script wich LOD used to view your model. There are two ways to use another texture for low poly model. 1. You can use same texture, but different UVs for low poly version 2. Not sure, but i guess it should work also. You can try to use another texture for low poly. One model support up to 8 textures to be used. Matter is your model can be visible for several people. In this case model for each of them can be viewed using different LODs. So i dont think using scripts in this case is a nice decision.
  5. Notecards still going to be main engine of textures applying. Developer Kit contains ready to use MBPS compatible applyer temaplate wich clothes and skins creators have to just configure to use with their creations. llMessageLinked was added as extention to make possible creation of custom MBPS compatible appliers. It is optional functionality. In common way creators will just configure ready applier with notecard as they doing now with other appliers. About security holes... IMPORTANT INFO FOR SKIN & CLOTHES CREATORS Default MBPS applier have 2 prims. Scripts and notecard located in child prim. By default MBPS applier template is full perm to let you setup parameters in notecard. But before sharing applyer creator should make applier NO MOD for next owner. In this case notecard can not be readed somehow by scripted hacking tools and texture UUID can not be stolen. Applier shows warning when you configure it in case you did not made it no mod. So make sure you dont get warning message before selling your appliers.
  6. May be i got you wrong. But crypting code is not going be published. Of course there are another ways to get texture UUIDs without scripts (i dont think its good idea to publish detailed info about it here). Without knowing of channel number calculating and UUID crypting algorithms its not easy at all to get real UUID by scripted hacking tools. That is a main reason why MBPS scripts are NO MOD - to hide these algorythms and avoid hacking. And besides goal of standard is not only to secure texture UUIDs. First of all standard was created as common technique wich allow to create appliers for body parts from different creators. And wich allow any body part creator to make their products MBPS compatible. MBPS LAST UPDATES: 1. Some body parts added to standard: handnails feetnails nipples 2. Specifications changes: Textures for breast implants supposed to use Lolas compatible UV mapping ( left upper 1/4 of standard SL upper body texture). If body part have different UV mapping that defined in MBPS standard it is reccomended to use custom body parts names to avoid mess with UV mapping. 3. For better compatibility with existing appliers 3 parameters added: texture repeats texture offset texture rotation 4. It possible now to create custom MBPS compatible appliers. Code for communication between applers and mesh body parts moved to separate script. Scipt processing now linked message with code 0x40000, encoding textire UUID if message have some and sending message to mesh body part. Message format to be sended to script: part name | alpha value | color vector | repeats | offset | rotation Part name is only required parameter, others are optional. For example operator llMessageLinked( LINK_SET, 0x40000, "underpants||<1,1,1>", "89556747-24cb-43ed-920b-47caed15465f" ); will set underpants texture and color without changing alpha, texture repeats, offset and rotation. Texture UUID will be crypted before sending it to body part. 5. Existing formats support added A lot of clothes creators have tonns of appliers already. So support of existing popular applier configuration formats was added: Lolas Tango, Lolas Mirage, Lush, Boop breast implants Lucky Inc. Phat Azz mesh bottom Sking Mesh bottom
  7. Its not very smart idea to publish source code. We can not be sure that code will not be modified for texture UUIDs stealing. Having code source it is not problem to just put llSay() before llSetTexture() and print or send UUID by IM. Thats why scripts WILL NOT be open source.
  8. There is way to make implementation of channel calculating separately, but i guess it will be just headake with llMessageLinked processing. I am going publish MBPS sripts itself (except channel calculation part) so creators can deside themself to trust MBPS scripts or not. Here is script for mesh body parts: list faces; list params; string note = "MBPS Body Part Setup"; integer line; key query; integer value; string str; integer getChannel() { [ HIDDEN ] } load() { faces = []; line = 0; if( llGetInventoryType( note ) != INVENTORY_NOTECARD ){ llOwnerSay( "ERROR! Notecard \"" + note + "\" not found." ); return; } query = llGetNotecardLine( note, line ); } process( string data ) { value = llSubStringIndex( data, "//" ); if( value != -1 ) data = llGetSubString( data, 0, value - 1 ); data = llStringTrim( data, STRING_TRIM ); if( data == "" ) return; params = llParseString2List( data, [ "=" ], []); if( llGetListLength( params ) != 2 ){ llOwnerSay( "ERROR! Incorrect parameters count in config note: " + data ); return; } str = llStringTrim( llList2String( params, 1 ), STRING_TRIM ); value = (integer) str; if(( string ) value != str ){ llOwnerSay( "ERROR! Incorrect face number in config note: " + data ); return; } faces += llStringTrim( llToLower( llList2String( params, 0 )), STRING_TRIM ); faces += value; } default { state_entry() { load(); llListen( getChannel(), "", NULL_KEY, "" ); } attach( key id ) { if( id != NULL_KEY ) llListen( getChannel(), "", NULL_KEY, "" ); } on_rez( integer param ) { llListen( getChannel(), "", NULL_KEY, "" ); } changed( integer ch ) { if( ch & CHANGED_INVENTORY ) load(); } dataserver( key id, string data ) { if( id != query ) return; if( data == EOF ){ query = NULL_KEY; return; } process( " " + data ); query = llGetNotecardLine( note, ++ line ); } listen( integer ch, string name, key id, string msg ) { if( query != NULL_KEY ) return; if( llGetOwner() != llGetOwnerKey( id )) return; params = llParseString2List( msg, [ "|" ], []); if( llList2String( params, 0 ) != "MBPS" ) return; value = llListFindList( faces, [ llList2String( params, 1 )]); if( value == -1 ) return; value = llList2Integer( faces, value + 1 ); if( llList2String( params, 2 ) != "" ) llSetTexture( llList2String( params, 2 ), value ); if( llList2String( params, 3 ) != "" ) llSetAlpha(( float ) llList2String( params, 3 ), value ); if( llList2String( params, 4 ) != "" ) llSetColor(( vector ) llList2String( params, 4 ), value ); } } Appler source code will be publised after beta-testing. And yes, suggestion about message crypting is really good and will be implemented also.
  9. Scipts are available in COPY/TRANSFER versoin. They are NO MOD to hide listened channel number calculation algotythm. 2 Sassy: A lot of clothes and skins creators interested in existing some standard. Now they have to make a lot of appliers for each creator. After making this standard work amount of needed appliers will be decreased.
  10. ====================================== MESH BODY PART APPLIER STANDARD (MBPS) ====================================== Currently most creators of mesh body parts using own texture applying technique, channels and message format for applying textures to their creations. As a result appliers wich work for parts from one creator doesn't work with others. Clothes and skins creators have to do a lot of work to make their creations compatible with different versions of body parts. Mesh body parts for sure is a future of SL and with time more creators will start to make mesh body parts. To avoid mess with appliers we introduce this standard wich allow make body parts and clothes compatible without described common techinque for texture applying to be used in future versions of body parts and clothes for them. This version of standard suppose that applyers using SL compatible UV mapping. FOR MESH BODY PARTS CREATORS ============================ All you need to make your creation MBPS compatible is it put script and configuration note to your creation. In note you setup to wich face of object each body part related. Each line have following format: part name = face number Supported body parts listed in clothes creators section. If body part have more then 1 primitives MBPS script and configuration note should be placed in each of them. How script works: Script using similar technique as most appliers. Numbers define wich face of mesh will be used for applying listed body part. Example of configuration note: legs = 0 // skin layer underpants = 1 pants = 2 Note: • Texture offset, scale and rotation should be set manually (using Edit tool) by body part creator. • Number of channel for listening based on mesh part owner avatar key. Technique of channel number calculating will not be published anywhere to avoid stealing of textures UUIDs. FOR CLOTHES & SKINS CREATORS ============================ To setup MBPS applyer you should edit note included in applyer. Configuration note for applier have following format: option = value Emtpy lines are ignored. Any characters following // are ignored until end of string. Note can have have following parameters: part = <body part name> texture = <texture key> color = <RGB 0-255 vector> alpha = <float> Body parts is only required parameter. Other parameters are optional. Here is list of currently supported parts: Mesh heads: =========== • head • headtatoo • hairbase Mesh upper body: =============== • torso • torsotatoo • undershirt • shirt • jacket Breast implants: ============== • breast • breasttatoo • bra • top Mesh hands: =========== • hands • handstattoo • gloves Mesh lower body: =============== • legs • legstatoo • underpants • pants Mesh feet: ========= • feet • feettatoo • socks Example of applier configuration note: part = top texture = 89556747-24cb-43ed-920b-47caed15465f color = 224, 224, 224 alpha = 1 Any suggestoions about standard are welcomed. You can recieve scripts inworld by contacting me. Later i going to place MBPS scripts at market and free vendor inworld. With best regards, Felicia Silversmith
  11. Tari, i agree with you. Sometimes contacting customer help to solve problems. But sometimes it does not. Some people writing reviews without thinking about results. I've created this topic because sales of product really decreased after this review appeared. And even may be problem already solved, girl who wrote review do not care about review she wrote. I've tryed to contact Linden Lab, but so far no success. So right now i see situation like this. Anybody can write any review and does not matter contains review real information or fake. And merchant who spent a lot of time for creating and promoting product start to lose sales. I see situation with product . Sales really decreased. And merchant can not do anything with that. That is how situation look right now. Products are not protected from unresonable defaming. 2All: Guys, i am not talking about cutting somebody rights to do something legal. And of course if product has disadvantages customer have rights to write review about it. It is normal. But when i talking about blacklist i mean reviews wich giving FAKE information about product. It is not fun. We talking about business here. Creators paying money for promoting products. Sometimes paying to buy some building components (textures, scripts, animations etc) for creating product. And every creator also have rights to expect that nobody allowed to public fake defaming information about things they create. I repeat, i an not against reviews wich contains real info about product. Does not matter good or bad, but real.
  12. I would like to concentrate attention to one moment. I am not suggesting to ban customers for bad reviews. If review is bad but it telling true its another situation. I was talking about unfair defaming of product. There is now already system of flagging reviews and think it can be modified a bit to flag fake defaming reviews. We have abuse report in SL for defaming persons. As i said creators spent sometimes really long time to create some products and i guess protection from unfair defaming should exist. About who will decide is it fair review or not. In some cases it visible at first sight. I dont know if comments to review can fix situation. Some people here saying that customers rarely paying attention to reviews. Then i guess they even more rarely paying attention to comment to reviews. But anyway, even if merchant lose at least ONE customer because of fake defaming review this situation should be solved. I mean solved in common, not in particular case. I spent monthes to create and promote some of my products and i dont want to lose customers because of fake reviews. Merchants should have way to protect their products from unfair defaming.
  13. Storm, there are mechanisms to unlist bad products. But merchants dont have any protections from incorrect reviews. Thats is what topic about,, People spending a lot of time to create product and then some person writing defaming review wich really fake. And all merchants can do in this case is to write tickets to Linden Labs. But it will not stop this person from writing more fake reviews like that.
  14. Greetings! I would like to suggest creation of marketplace customer banlist. Everybody who have own shop at marketplace knows that people writing reviews rarely even if they like product. Thats why products protected bad from bad reviews. Of course if review contain correct information creator can work on issue. But sometimes customers writing reviews with content like that - "I don like it"... Then is hard to understand why person bought it if do not like product. Of course if product is not same as described in listing its creator fault. But sometimes people write reviews like that just because they have bad mood. And SL laws dont protect creators from it. Or as in case with one of my product even placing fake info about product into review. So people now writing reviews without any responsibility for review content. I suggest 2 things: 1. Reviews wich defaming product without list of REAL disadvantages of product should not be allowed. 2. Placing reviews with fake or incorrect information about product should cause placing review author into banlist. And such customers should not be able write reviews anymore. I guess i am not only creator who have issues with incorrect reviews.
  15. Thanks for detailed answer Tari. Just you see there are some rules according to wich items sorted in each case. Its hard to say about sorting by relevance. But when we talking about sorting by best selling i guess rules are clear. Products sorted by number of sales for some last period of time. And that is what makes me really suprised when i see on top items wich can not be on top by sales. So question is how does they get on top? That is what i trying to find out. Imagine such situation: search results by some word shows furniture about 2000 L$ cost and avatar attachement about 100-150 L$. We all knows that there are much more people in SL who dont have own land at all. So, people bying attachement more often then furniture. Plus difference in price. 2000L$ is a big enought money for many people, in opposite much more people can afford 100-150 L$. But.... I see furniture at top of search result. I dont know about others, but for me its nonsence. Yes, there are famous brands and big inworld shops wich have own groups and with right marketings they can do really good sales. But we talking about Marketplace. And when i see product of not famous brand, and even more - very specific product wich people need rarely at top of bestselling i have question: "How so?" If it is some way of advertising i guess all creators should know about it. Because i have experiance with list enchancement - they dont give exectly similar result. So if answer is "i dont know" question is opened still. I really appretiate your opinion, but i want marketing to be fair and if there are some ways how they do it, i guess creators have right to know about such ways. Thats it.
×
×
  • Create New...