-
Followers
Pilus (Assigned To) , Katecia
AttachmentsNo attachmentsAssociationsNo associationsActivity
on Dec 11, 2011 @ 11:48am UTC * By Aurorablade
we could do this and the option of a popup dialouge showing what the item would make you say. Though you may have that planned already.on Dec 26, 2011 @ 11:53am UTC * By Pilus
Type changed from Feature to ImprovementComponent changed from None to Renovated Item ActionsDescription changed from Add an option to disallow a... to Add an option to disallow a...Status changed from New to AcceptedSum of Child Work remaining changed from 0.0 to 4.0Work remaining changed from 0.0 to 4.0I have made a detailed description of the task now, including the idea from Aurorablade.
I estimate that it could all be done in around four hours.
on Dec 26, 2011 @ 10:06pm UTC * By Katecia
Assigned to set to KateciaStatus changed from Accepted to In ProgressI'll start working on this. I assume that you want this to apply to both Expression actions AND from-script calls such as SendChatMessage() and Emote() - Are there any other functions I should be aware of that require handling for this?
It appears that the say/emote functions are awaiting either a rewrite, or for GHI_UseItem to be included in the TOC. Are they in need of complete rewriting, and if so, in what file should I be putting the new functions? If not, should GHI_UseItem be added to the TOC?It all looks fine so far. Regarding the menu for situation 2, then you can either make a static popup menu or use a GHM menu. Regarding the delay, for situation 3, then I can recommend saving the current time whenever a notice message is shown. Then make a check, earlier, that only shows the message if X sec have passed since the saved variables.
Keep up the good work.
I think I'm going to change the delay that I implemented last night to the one you described, since that should mean less processing per update.
I reorganized the order of some portions of SendChatMessage. Messages are now added to the queue before being prompted, rather than prompted, then added to the queue, which was causing them to be prompted a second time when the message came off the queue. I'll look into the menu itself next, and see what I can come up with.
The overall code looks good and the content also. Quite good work. I got a few suggestions to improvements.
Layout inprovements:
- Displaying what chattype it is in the UI frame. I assume that you plan on doing this already, as I can see that you have passed the arguments for it in the Show function.
- Maybe 'Promt first' in the options menu is not clear enough for a new user.
Code inprovements:
- Regarding the use of dummy objects in the GHM setup table. Text labels does not have a height, so a line with only a text label on it gets the default minimum line height. That can indeed be fixed with dummy objects, but I suggest putting the dummy objects on the same line as the text label. You can then adjust the height of the dummy object to set how much space the text label is allowed to take.
- It is no longer needed to specify the background in the ghm setup table, since we added the menu layout system. We still have them many places in the different menus, but they are no longer needed.
- If you do not specify any height for the menu, then it will automatically get a height fitting to content.
- In GHI_ExpressionHandler you forgot to make lastDisallowedMessage a local variable.
Test concerns:
- Have you considered what happens if another premission request occurs while the menu for a premission request is open?
on Jan 05, 2012 @ 04:58pm UTC * By Katecia
Sum of Child Work remaining changed from 4.0 to 1.0Work remaining changed from 4.0 to 1.0Re: Layout Improvements
- I can definitely show the chat type. The main reason the arguments are passed to the show function is for the SendChatMessage call if the user clicks "OK." I had considered it at one point, but thought that users might be confused if it the chatType was something like "2."
- I shortened it to "Prompt First" due to some issues with the layout. Making the combo box longer caused it to get placed oddly.
Re:Code Improvements
- I was wondering if that might be the case. I couldn't tell if changing the height was doing anything. I put them on a separate line because if a different localization's text was more or less lines, then a fixed-height box could cause issues with them overlapping.
- The GHM setup was all using GHI_ImportItem. In fact, most of it was not touched, aside from the window's height. I can remove it, though.
- lastDisallowedMessage wasn't set to local because spamCounter wasn't set to local, and I was using the existing information in the file as a template. I've updated that now.
Re; Test concerns
- Originally I'd figured that allowing it to skip any extra queued messages would be a built-in spam filter for if a person ended up with a large number of messages. However, I've added a queue to the confirmation window. If you see fit, I can also add a button next to "Cancel" that will clear the entire message queue. I'm mostly not sure what to label this button.
It seems good. Following our ticket handling progress it should then be moved to "Ready for test", as the "Ready for review" is mainly for concept review and work in progress.
However, I just found an error, so I will just straight forward it to "Failed in Re-Test".
It is just a minor thing and the rest of it seems to work completely correct.
The bug is that standard emotes seems to not be handled correct. E.g. "peer" will turn into "charactername peer" instead of "you peer around searchingly".
I havent been able to test it yet, but I have discovered one possible issue from analyzing the code. To me it seems that if you send a "say" with the text "kneel", then the system would send the emote kneel.
This could be fixed by changing line 85 fromif isStdEmote == false then
intoif chatType:lower() == "emote" and isStdEmote == false thenTime ExpenditureLoading
This could be use full for players who dont want to suddenly post random stuff.
Design details and requirements:
There should be a drop down menu in the main GHI options page with the label "Permission for Say, Emote etc."
The drop down menu should have three options:
- Allow all
- Ask for confirmation
- Block all
The default option is 'Allow all'.Data wise the options should be saved in the GHI_MiscData table as the variable 'chatMsgPermission' with the number value 1 to 3.
The variable should result in the following behavior in the expression handler, when posting a chat message:
If the variable is 1, post all emotes, says and other chat messages as normal
If the variable is 2 and the message is send by a chat environment not belonging to the player, then a confirmation box should be shown. This box shows the following information:
- name of the creator of the item posting the message
- message type
- message text
If the variable is 3 then the message should not be posted. Instead a message is printed to the chat log with the text "One or more chat messages was blocked". This message is only posted if it have not already been posted within the last 5 minutes.