Current understanding:
To my understanding, the functionality of a <prompt> element is to define prompt audio to be played, followed by the system waiting for a user utterance. My impression comes from the VoiceXML 2.0 specification for prompts:
Conceptually, prompts are instantaneously queued for play, so interpretation proceeds until the user needs to provide an input. At this point, the prompts are played, and the system waits for user input.
Additionally, I understand the difference between a <block> and a <field> to be that:
a <block> is a control item and is "not for gathering input", and
a <field> is an input item whose value is "gather[ed] from the user"
Lastly, I know that a <prompt> can be a direct child of both a <block> and <field>.
Questions:
I am pretty sure that a <prompt> collects input when inside a <field>, but what is supposed to happen when it is inside a <block>, since blocks are control items?
In the case that a <prompt> in a <block> does not collect input and only plays audio, why wouldn't you instead write the text for a prompt as content inside a <block>, omitting the <prompt>?
There is no difference.
1 - It is the field that is driving the input process, not the prompt. Try it without the prompt.
2 - If you aren't using any of the other features of the prompt element, it doesn't matter.
Note, there is something important to realize in the text you quoted. "prompts are instantaneously queued" Prompt and similar element structures just queue audio. Yes, you will usually start to hear them if there is a delay. But, the playback is separate from the element.
As far as to why you might do one over the other, it could just be development style or flow based logic. For example, when playing back data, having multiple blocks that can be jumped through to cover different scenarios might be cleaner that a complex field/prompt configuration.
Related
I'm in a pickle. (not literally, of course)
I had a ship game, which used Proximity Prompts to enter the docks. This worked well enough. However, that was for a click to move system, and now I'm attempting to make a direct control system (e.g. you press WASD to move your ship instead of clicking a point on the ocean), and as such, there is no character in the game, and have done everything else without a character.
In short: They don't work now and I have no clue why.
The script is near enough the exact same on both games (The original game's script has a lot more other functions in it, but nothing that would affect this), and so is the configuration of the Proximity Prompt. But I don't see how it could be to do with the lack of a player Character, and if it is, how do I edit the default code for it, to work without one? (I had a look, but couldn't find anything useful) As it doesn't seem like it will have direct dependence on the character, as any animations or custom behaviour would have to be done connecting to the ProximityPromptService/Prompt itself to add those via the events.
This is literally the whole server-side script I have for it.
local proximitypromptservice = game:GetService("ProximityPromptService")
local function get_player_data (player)
... --Unrelated, it's just a function to get player data, no issues here.
end
proximitypromptservice.PromptTriggered:Connect(function(promptobject,player)
print("Prompt TRIGGERED") --Not seen in the log when the Prompt is pressed.
if promptobject.Name == "DockControl" then
print("DOCKCONTROL")
if player.IsLoading.Value == false then
game.ReplicatedStorage.Dock.AccessDock:Fire(player,...)
end
end
end)
It's probably worth noting that when you press the key, e.g. E, it does the hold Duration animation and then disappears, and reappears as you'd normally expect. Creating a custom docking system is not out of the question, but I would really really prefer not to create an overcomplicated, clunky system for something that should work out of the box.
Any help would be appreciated,
The Frog.
PS: Also tried this on both local and server scripts as a child of the prompt to no avail.
script.Parent.Triggered:Connect(function()
print("TRIGGERED")
end)
I have a Gather-Input-On-Call widget that stops gathering on key press #. I want to know if this widget times out or user pressed # only. Both of them are treated as NoInput now. How to distinguish between them?
There isn't a distinction since a # without any input is considered No Input (as the # is not submitted).
What are you trying to achieve that you need to determine the difference? It sounds like you are overloading the role of #?
I want to enable accessibility support in my app where i have In-line validation message (e.g As per below screenshot) when user enters something invalid data. My app doesn't show any error message.
What can be best and intuitive way to inform visual impaired/blind user about wrong data entries. e.g. Username & password mismatch, invalid.
First off, there is no "correct" way to do this. There are just a bunch of ways that work. The "best" way to do this, would be for iOS to have a "required" trait (IMO). But this is not supported, so we have to work with what iOS has given us... hints and labels.
Step 1:
Tell the user what is required. I would do this by adding the information to the hint. I like to add information to the hint that only non-familiar users need. "Power users" of your application will get use to what fields are required (assuming you're going to have return users, some views are just "hit and run" types). But, point being, don't flood users with unnecessary information. Users who visit a particular view frequently will get use to what is required, so keep non-crucial information in the hint. What you want is voiceover to read out the text input fields like this: "Email(accessibilityLabel) text field (the type of object), (pause) This field is required.(hint)" Don't wait until after a failure to provide this information to VoiceOver users. It should just always be set this way. If the type of failure changes, change the hint to adapt to this particular type of failure. If you'd like to keep the hint in sync with the Red highlighted labels, you can consider overriding the functions from the UIAccessibilityProtocol to pull out this information EX:
- (NSString*)accessibilityHint {
return myUILabel.text;
}
This should cause to keep the hint of the object, and the text of your UILabel in sync.
Step 2:
Mark all elements that are not the text input fields, as not accessibility elements. All of the information a user needs about those fields is either stored in the type of the field (a text input field), the label (email/password), or the hint (whether or not it is required). Therefore, we don't want VoiceOver to look at the other elements, because this would be duplicate information.
Step 3:
Use the following line of code:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, anAccessibilityElement);
In your login action. On a failed login action, you should shift voiceover focus to the element that caused the failure. This informs the user that their action was attempted, and that it failed. It also allows them to easily know which element caused the failure, and that it needs fixed. In the event of multiple failures, make sure you shift focus to the first failure!
I'm planning out how to track internal search data in Omniture/SiteCatalyst.
It's a fairly straight-forward plan for a standard "enter a term and get a page of results" model: set sProps and eVars with the terms, the count of results, and the page searched from, then fire a success event for searching and another for clicking a search result.
For a type-ahead search--where the user is given search results as they type in a search bar--what's a good strategy for handling the timing of event submissions so that you don't end up with different events/entries for letters 4, 5, 6, and 7 of a search term's entry?
Our solution was to leverage a delay on the autocomplete to reduce the number of calls. From a tracking standpoint, if someone pauses for 1 second (or 500 ms, whatever), then they're probably actually waiting for the autocomplete results, and that constitutes a valid search.
From a technical standpoint, we leveraged the delay option on the jQuery UI widget.
Strategy I've always used is to not track the "auto-complete" search features..put the tracking on the search results page same as normal. Or are you saying the whole search results page is being output as the user types? If that is the case...one thing you could do is write some code to pop the Omniture code when the search field loses focus.
Another thing you can do is as the visitor is typing in the search bar, on each keypress, write the current value to a cookie. Then have some code that runs on page load to look for that cookie and if it exists, pop the Omniture search variables and erase the cookie. Alternatively you can keep track of current value w/ a server-side session variable since I assume this thing is ajax driven, and output the omn code w/ server-side code if session var exists. These methods would mean that the search events and vars would not pop on the search results page...this probably isn't that big a deal, unless you have supporting variables you pop, like an "internal search referrer" prop/eVar that keeps track of the previous page the visitor was on (or the page the visitor was on when they performed the search). So you'll have to keep that in mind and carry that over as well.
Whenever you do a search you might be aware of the concept that query string parameter get added at the end of URL.
Suppose www.stackoverfow.com is website and when are you performing a search on it then it will be like www.stackoverflow.com?q=yourname , yourname is the searchkeyword.This keyword we can capture in sitecatalyst.
you can see google.com while searching on internet for sitecatalyst is ---
www.google.co.in/search?q=sitecatalyst
In the same way we can use query string parameter as q = something.
after doing all this thing we can use the plugin getQueryParam in plugin section of the s_code library file to fetch that variable and store that in sitecatalyst variable...
example:-
function s_doPlugins(s) {
var one = s.getQueryParam("q");
if(one)
s.eVar1=one;
}
s.doPlugins=s_doPlugins
insert this below code outside plugin section
/*
* Returns the value of a specified query string parameter, if found in the current page URL.
*/
s.getQueryParam=new Function("p","d","u",""
+"var s=this,v='',i,t;d=d?d:'';u=u?u:(s.pageURL?s.pageURL:s.wd.locati"
+"on);if(u=='f')u=s.gtfs().location;while(p){i=p.indexOf(',');i=i<0?p"
+".length:i;t=s.p_gpv(p.substring(0,i),u+'');if(t){t=t.indexOf('#')>-"
+"1?t.substring(0,t.indexOf('#')):t;}if(t)v+=v?d+t:t;p=p.substring(i="
+"=p.length?i:i+1)}return v");
s.p_gpv=new Function("k","u",""
+"var s=this,v='',i=u.indexOf('?'),q;if(k&&i>-1){q=u.substring(i+1);v"
+"=s.pt(q,'&','p_gvf',k)}return v");
s.p_gvf=new Function("t","k",""
+"if(t){var s=this,i=t.indexOf('='),p=i<0?t:t.substring(0,i),v=i<0?'T"
+"rue':t.substring(i+1);if(p.toLowerCase()==k.toLowerCase())return s."
+"epa(v)}return ''");
you will find that it will capture your search results
please let me know in case of more clarifications
How do you make a combo of two emotes in lua in World of Warcraft work?
function Button2_OnClick()
PlaySoundFile("Interface\\Addons\\Fart\\common_fart[1].wav");
DoEmote("moon");
DoEmote("sit");
DoEmote("dance");
DoEmote("beckon");
end
I am using Wow Addon Studio to make a fart application on Wow.
I used this function, and only the sit motion showed, and beckon and moon only showed on the chat window. The dance emote didn't show up anywhere.
Blizzard has explicitly prohibited anything that can be used to make lua wait or pause because it is an essential ingredient to making a gold mining or grinding bot.
There isn't a native (i.e. lua only) way to have lua wait without using all the CPU. Outside of the WOW client, you'd use win.sleep or some other 3rd party API call that calls into the host application or operating systems threading functions.
It may be possible to simulate a wait by having code execute on a frequent event (such as text arriving at the chat window) and then in the event handler checking to see if enough time has passed to permit executing the next command in the sequence. This probably wouldn't be a very accurate timer and it would be rather complex as you'd have to create a data structure to hold the sequence of commands, the timings between each, the current command, etc. and so on.
This may be an intentional limitation of the API to prevent in game automation (botting).
What has worked for me is to have a global variable that is incremented through the loop. Such as
Integer count = 0;
function Button2_OnClick()
i++
switch
case(1)
PlaySoundFile("Interface\\Addons\\Fart\\common_fart[1].wav");
case(2)
DoEmote("moon");
case(3)
DoEmote("sit");
case(4)
DoEmote("dance");
case(5)
DoEmote("beckon");
default
i=0;
end
end
What you would have to do then is to click the button multiple times, but you would get the effect you're going for.
I would suggest you wait some time before doing the next emote. As far as I know, the server disconnects you if you spam too much. This might just trigger it sometimes.
Besides that, I guess maybe the client has a way of preventing it? In either case, I would suggest you add some sort of fraction-of-a-second delay between the emotes.
Cheers,
Amit Ron
Could it be that the last two can't be done while sitting?
infact, integer i = 0, because defining integer 'count' and then using i is incorrect. :)