I'm currently doing some work with the Youtube Live Streaming Api - more specifically the live chat messages API. Its all working fine for now but my main problem is with superchats and superstickers.
https://developers.google.com/youtube/v3/live/docs/liveChatMessages#snippet.superChatDetails.tier
I'm reffering to this bit in youtube's livechat messages documentation. It addresses that each superchat has a tier variable, and that tier correspond's to a UI color which I will need when designing my UI. The documentation says
The tier is based on the amount of money spent to purchase the message. It also determines the color used to highlight the message in the live chat UI, the maximum message length, and the amount of time that the message is pinned the ticker.
The Super Chat tiers, which also cover Super Stickers, are documented in the YouTube Help Center. (See the expandable section about Super Chat purchase details.) In that list, the tier with the lowest purchase amount is tier 1, the next lowest amount is tier 2, and so forth. The Super Chat tiers, which also cover Super Stickers, are documented in the YouTube Help Center. (See the expandable section about Super Chat purchase details.) In that list, the tier with the lowest purchase amount is tier 1, the next lowest amount is tier 2, and so forth.
So I went ahead to the the Youtube Help Center and the closest thing I can find to it supposedly describing the youtube superchat tiers is this article below:
https://support.google.com/youtube/answer/9178268?visit_id=637544258197433496-560511224&rd=1
But again, this article really doesn't document anything that would be relevant to a developer.
So here is my question exactly. Does anybody out there know where I can find the documentation or if somebody knows what the YouTube Superchat tier levels and UI colors are?
If I were stuck on something like this, I would usually just test it out myself rather than trying to find specific documentation, but that's not really possible here. Since if I were to test every single tier, it would probably cost me hundreds of dollars in test donations.
Extra question:
Can anyone also explain what's going on with the whole authorDetails.sponsor vs the member resource, apparently its deprecated but I'm not sure about the exact situation of that?
I'm also trying to access the authorDetails.sponsor variable but apparently the whole Sponsor resource got deprecated and was changed to the Member resource. But then when I visit the member resource it says you need prior approval to use the members.list method but does that also include the authorDetails.sponsor variable?
Here are the documentation links below:
https://developers.google.com/youtube/v3/docs/members
https://developers.google.com/youtube/v3/live/docs/liveChatMessages#authorDetails.isChatSponsor
https://developers.google.com/youtube/v3/live/docs/sponsors
I also noticed that Google does not provide documentation on this (even though the Super Chat API docs mention it is documented.)
I've found this chart to be a useful starting point: https://www.midiaresearch.com/storage/uploads/blog/images/2017/02/Screen-Shot-2017-02-09-at-09.50.17.png
In case that image is not available in the future, here are the values:
Amount Range
Color
Time Displayed (in Ticker)
Max Characters
$1.00 - $1.99
Blue
0s
0
$2.00 - $4.99
Light blue
0s
50
$5.00 - $9.99
Green
2m
150
$10.00 - $19.99
Yellow
5m
200
$20.00 - $49.99
Orange
10m
225
$50.00 - $99.99
Magenta
30m
250
$100.00 - $199.99
Red
1hr
270
$200.00 - $299.99
Red
2hr
290
$300.00 - $399.99
Red
3hr
310
$400.00 - $499.99
Red
4hr
330
$500.00+
Red
5hr
350
The Super Chat API docs mention:
In that list, the tier with the lowest purchase amount is tier 1, the next lowest amount is tier 2, and so forth.
It's probably safe to assume that there are 11 tiers for Super Chats.
edit: I wrote some code to calculate the colors for each amount. I verified that these colors are correct. Feel free to re-use it:
/**
* Calculate the colors for a given super chat amount.
* Returns the background color [0], the header color (darkened) [1],
* and the text color [2].
* #param {string|number} amount
* #returns {[string, string, string]}
*/
const getSuperChatColors = (amount) => {
if (typeof amount === 'string') {
amount = parseFloat(amount.replace(/[^\d.-]/g, ''))
}
if (amount >= 1 && amount <= 1.99) {
return ['#1565C0', '#1565C0', '#FFFFFF']
} else if (amount >= 2 && amount <= 4.99) {
return ['#00E5FF', '#00B8D4', '#000000']
} else if (amount >= 5 && amount <= 9.99) {
return ['#0F9D58', '#0A8043', '#000000']
} else if (amount >= 10 && amount <= 19.99) {
return ['#FFCA28', '#FFB300', '#000000']
} else if (amount >= 20 && amount <= 49.99) {
return ['#F57C00', '#E65100', '#FFFFFF']
} else if (amount >= 50 && amount <= 99.99) {
return ['#E91E63', '#C2185B', '#FFFFFF']
} else if (amount >= 100 && amount <= 199.99) {
return ['#E62117', '#D00000', '#FFFFFF']
} else if (amount >= 200 && amount <= 299.99) {
return ['#E62117', '#D00000', '#FFFFFF']
} else if (amount >= 300 && amount <= 399.99) {
return ['#E62117', '#D00000', '#FFFFFF']
} else if (amount >= 400 && amount <= 499.99) {
return ['#E62117', '#D00000', '#FFFFFF']
} else if (amount >= 500) {
return ['#E62117', '#D00000', '#FFFFFF']
} else {
console.error('Invalid amount for super chat', amount)
return ['#1565C0', '#1565C0', '#FFFFFF']
}
}
Usage:
const [bgColor, headerColor, textColor] = getSuperChatColors('$100.00')
// or
const [bgColor, headerColor, textColor] = getSuperChatColors(60)
// or
const [bgColor, headerColor, textColor] = getSuperChatColors('$1')
// or
const [bgColor, headerColor, textColor] = getSuperChatColors('20')
Related
I'm trying to write an Ea with 2 moving averages, and I want it to send an order when they cross.
Sell orders seem fine, but for Buy orders in 1-min chart, the Ask price which I use to send the order is not in the candle price range. Actually I did Print("Ask=",Ask) right before my OrderEntry function and right after OrderSend(). They are equal to some price way above the candle-[High] and previous candle-[close]
But when I try higher time frames, it get closer to the candle and in daily time frame, the Ask price for orders would be in the candle range (High-Low). Does anybody know why this is happening?
void CheckForMaTrade(){
double PreviousFast = iMA(NULL,0,FastMaPeriod,FastMaShift,FastMaMethod,FastMaAppliedTo,2);
double CurrentFast = iMA(NULL,0,FastMaPeriod,FastMaShift,FastMaMethod,FastMaAppliedTo,1);
double PreviousSlow = iMA(NULL,0,SlowMaPeriod,SlowMaShift,SlowMaMethod,SlowMaAppliedTo,2);
double CurrentSlow = iMA(NULL,0,SlowMaPeriod,SlowMaShift,SlowMaMethod,SlowMaAppliedTo,1);
if(PreviousFast<PreviousSlow && CurrentFast>CurrentSlow)
OrderEntry(0);
if(PreviousFast>PreviousSlow && CurrentFast<CurrentSlow)
OrderEntry(1);
}
void OrderEntry(int direction){
if(direction == 0){
double bsl=0;
double btp=0;
if(StopLoss != 0)
bsl = Ask-(StopLoss*pips);
if(TakeProfit != 0)
btp = Ask+(TakeProfit*pips);
if(OpenOrdersThisPair(Symbol()) < 10 )
OrderSend(NULL,OP_BUY,LotSize,Ask,0,bsl,btp,NULL,MagicNumber,0,Gold);
}
enter image description here
In MT4, the candles are drawn by BID prices only. ASK prices are not taken into consideration. So it is possible that Ask > highest bid.
I'm looking for a way to optimize our website's Speed Index metric on Lighthouse
I found this helpful article describe Speed Index metric very well, and help me understand how Speed Index is calculated.
https://calendar.perfplanet.com/2016/speed-index-tips-and-tricks/
But there is a key concept not being described clear on the article, and I search for a lot of other Speed Index related blogs still can't found the answer.
What is the 100% visual completeness frame?
We all know the First Frame is 0% VC because it's blank, but the VC keep increasing during the page load process, so what frame will be consider as 100% visual completeness?
The definition of 100% VC frame is important because it's the baseline for calculate all other frame's visual completeness.
If I have a page that simply print from 1 to 100 with interval 100ms and just enough to fill in the viewport, will the 100% VC frame be the frame that number 100 is printed?
Lighthouse
According to Google's description of the Lighthouse "Speed Index" audit:
Lighthouse uses a node module called Speedline to generate the Speed Index score.
sends Speedline
Speedline's Github readme says
The Speed Index, introduced by WebpageTest.org, aims to solve this issue. It measures how fast the page content is visually displayed. The current implementation is based on the Visual Progress from Video Capture calculation method described on the Speed Index page. The visual progress is calculated by comparing the distance between the histogram of the current frame and the final frame.
(Italics mine.)
a timeline of paints
The Speed Index page goes into painful detail about how visual progress is calculated. Here's a snippet:
In the case of Webkit-based browsers, we collect the timeline data which includes paint rects as well as other useful events.
I believe "timeline data" refers to a JSON object retrieved via the Performance Timeline API.
It seems Lighthouse passes the JSON timeline to Speedline, which then extracts an array of "frames," describing the page load's paint events:
/**
* #param {string|Array<TraceEvent>|{traceEvents: Array<TraceEvent>}} timeline
* #param {Options} opts
*/
function extractFramesFromTimeline(timeline, opts) {
which calculates histograms
Speedline converts the image data from each paint event to an image histogram, interestingly excluding pixels that are "close enough" to pass as white:
/**
* #param {number} i
* #param {number} j
* #param {ImageData} img
*/
function isWhitePixel(i, j, img) {
return getPixel(i, j, 0, img.width, img.data) >= 249 &&
getPixel(i, j, 1, img.width, img.data) >= 249 &&
getPixel(i, j, 2, img.width, img.data) >= 249;
}
A lot of math goes into calculating and comparing histograms. The project maintainer is the right person to ask about that. But this is where the eventual determination of the "visually complete" happens:
// find visually complete
for (let i = 0; i < frames.length && !visuallyCompleteTs; i++) {
if (frames[i][progressToUse]() >= 100) {
visuallyCompleteTs = frames[i].getTimeStamp();
}
}
and infers "progress",
The "progress" of a given frame seems to be calculated by this function:
/**
* #param {Frame} current
* #param {Frame} initial
* #param {Frame} target
*/
function calculateFrameProgress(current, initial, target) {
let total = 0;
let match = 0;
const currentHist = current.getHistogram();
const initialHist = initial.getHistogram();
const targetHist = target.getHistogram();
for (let channel = 0; channel < 3; channel++) {
for (let pixelVal = 0; pixelVal < 256; pixelVal++) {
const currentCount = currentHist[channel][pixelVal];
const initialCount = initialHist[channel][pixelVal];
const targetCount = targetHist[channel][pixelVal];
const currentDiff = Math.abs(currentCount - initialCount);
const targetDiff = Math.abs(targetCount - initialCount);
match += Math.min(currentDiff, targetDiff);
total += targetDiff;
}
}
let progress;
if (match === 0 && total === 0) { // All images are the same
progress = 100;
} else { // When images differs
progress = Math.floor(match / total * 100);
}
return progress;
}
and "visually complete" is the first frame with 100% progress.
Without fully auditing the code, my interpretation is that the "visually complete frame" is the first frame calculated to have the same total difference from the initial frame as the final frame (which is determined by which frames Lighthouse chooses to send to Speedline).
Or, in other words, it's complicated.
Visually complete is when the page in the viewport stops changing. I.e. the visuals are not changing.
It is calculated by taking screenshots throughout the load and comparing them to each other and to the final end state. So yes in your example when all numbers 1-100 are printed and the page stops changing you are “visually complete”.
So if a page loads the data in view quickly but renders “below the fold” content (e.g. off screen images) more slowly then you will get a quick visually complete, even if the page overall load time is still long.
Similarly if most of the on screen content is drawn early on but one small part is drawn later (perhaps a “click to chat” option) you will get mostly visually complete early on and so a good speed index, even if not as good as the above example.
On the other hand if you load fonts, or perhaps a large hero image, last and it redraws large parts of the page in view you will get a slow visual complete time and also a slow speed index score.
More details here: https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
I just got the answer from Lighthouse repo contributor, pls check this link guys.
https://github.com/GoogleChrome/lighthouse/issues/8148
I have a room with 6 iBeacons and call an action if one of them is under 2.5 meters from the device, but that is not working very well because there a often big interferences, which caused the false Action.
My question is what is better for sorting these Beacons - using the rssi-value or the accuracy?
Below the Code I use for sorting/call the action:
if beacons.count > 0 {
let sortedBeacons = beacons.sorted { (first, second) -> Bool in
if first.accuracy == -1 || second.accuracy == -1 {
return true
}
return first.accuracy < second.accuracy
}
let beacon = sortedBeacons[0]
if beacon.major.intValue == helperMajorValue && beacon.accuracy < 2.5 {
if beacon.accuracy != -1 {
if triggeredMajor == 0 {
counter += 1
} else if abs((helperMajorValue - triggeredMajor)) < 3 {
counter += 1
}
}
} else {
counter = 0
helperMajorValue = beacon.major.intValue
}
if counter > 4 {
counter = 0
print("majorValue: \(beacon.major.intValue) distance: \(beacon.accuracy)")
if beacon.accuracy < 2.5 {
startNavigation = true
majorValue = helperMajorValue
triggered = false
}
}
if majorValue == 171 {
//call action
} else if majorValue == 170 {
//call action
} else if majorValue == 172 {
//Call action
}}
The big difference between using CLBeacon's rssi or accuracy fields for sorting beacons is the variability or the number and the averaging interval.
The accuracy field is averaged over approximately 20 seconds, so it essentially gives you the estimated distance of where the device was over the past 20 seconds. The real advantage is that this number is much less noisy than rssi, but there is significant lag.
The rssi field is averaged over 1 second, so it uses many fewer data points. While it has less time lag, it also has a lot more noise. For sorting purposes if using rssi, you will see the sort order jump around a lot more.
You must set your expectations appropriately for how accurate these numbers will be as estimates of distance as #Duncan-C describes in his answer. But for some uses cases where precision is not important they can work very well.
The sad answer is "none of the above". The "accuracy" reading is the best source of distance from the beacon, but it is very crude. Think in terms of far, medium, close, and right on top of the phone. Trying to evaluate distance any more finely than that is pointless, and even that is iffy. The radio signal strength is subject to so many variables that have nothing to do with distance that it isn't a very accurate measurement.
I am making a 2D reaction game with sprite-kit and I am having the same problem again. I already asked this question once and had good answers and everything worked finde but now I am stuck again.
Like the title says I want to speed up my game every 50 points, but it just speeds up when I get the right point number like 50, 100, 150.. The problem is that I have combo points and its always some points more. For example from 48 to 51 points, so it never speeds up. How can I speed up the game even its some points more ? I mean from 50 to 100 one speed up and from 100 to 150 and so on. Here is my code so far:
if (points % 10 == 0) {
if (readyToSpeed) {
speed++;
NSLog(#"speed up");
readyToSpeed = NO;
}
}
Thanks for the help ! (code in objective-c please)
EDIT: Works perfectly using both answers combined.
Instead of incrementing your speed you could do it like so:
speed = baseSpeed + (points / 50);
Where baseSpeed is the speed at the start of the game.
Don't worry about the exact 50x multiple points, keep track of the current point "group" via modulo to derive your speed value
cur_speed = points - (points % 50);
e.g. if they're at 203 points, then cur_speed is 203-(203%50) -> 203-3 -> 200. If they suddenly jump to 308 pts because they hit an insane points combo, then the speed becomes 308-(308%50) -> 308-8 -> 300
if you want just between 50-100 and 100-150 do something like this:
If points > 50 && points < 100 {
//speedup code
}else if points > 100 && points < 150 {
//speedup code
} //etc
Update: if you want this to be endless do this:
var speednumber = points/50
speednumber = speednumber-decimal //some code to cut of the decimals
setSpeedTo(speednumber+1) //you got to make a function for this
setSpeedTo(1) will be normal
2 will be from 50-100
3 100-150
Etc.
i am gathering accelerometer and gyroscope data using push methods( startDeviceMotionUpdatesToQueue:withHandler: and startGyroUpdatesToQueue:[NSOperationQueue mainQueue]
I compare these raw data with certain thresholds, if it satisfies the threshold, I do increase a label counter by one , my problem is when I start detecting ie reading the methods and comparing it to thresholds , the counter increases so fast, I have read in (Simple iPhone motion detect) that " if condition will become true twice for every single motion" , so if this is what is happening with me, how do i solve the problem, my code is simple
checkData{
if ( ( acc_2 >= 0.03885) && (gyro_3 >= 0.0003) && (gyro_3 <= 0.00838))
{
i=i+1;
//then Label data
_Counter.text=[NSString stringWithFormat:#"%d",i];
}
else if (( acc_2>= 0.01103) && ( gyro_3 >= 0.00851))
{
/
//update the counter
i=i+1;
_Counter.text=[NSString stringWithFormat:#"%d",i];
}
...... same other conditions
}
then I do call this method inside startDeviceMotionUpdatesToQueue:withHandler: block.
[ self checkData];
what can i do to fix the problem, can you guide me ?
}
I'm not 100% sure if this is what you're asking, but if you're looking to change the rate a which you receive updates from the hardware, which would then slow the rate at which your label updates (and save battery), you could use CMMotionManager's setGyroUpdateInterval: and setDeviceMotionUpdateInterval: to adjust the refresh rate. A value of 1 is update once per second.
[_myMotionManager setDeviceMotionUpdateInterval:1];
[_myMotionManager setGyroUpdateInterval:1];