Can we have emoji in team names, pretty please?
Wouldn’t that require modifications to literally everything that handles team names and displays them? That seems like quite a lot of work for not much benefit. And IMO, I don’t see how emoji can be part of a name.
Not likely. Previously (before the Robot Events update) teams were able to add emojis into their team information by using the emoji’s decimal code. It would only display properly online (not in Tournament Manager, for example). I assume they removed this ability on purpose.
I remember back in 2016 team 2587Z was able to put basketball emojis into their name, to go along with the nothing but net theme of course. And as far as I know, there weren’t any problems with TM and it would even show up on vexDB (and RobotEvents?) properly. As for why? Well why not? There’s no absolute practical purpose behind it, but that shouldn’t mean its useless. If we really separated everything into wants and needs, then things like a team name might seem without purpose as well, and we’d be happy going around with just team numbers to identify ourselves.
If it’s legitimately super difficult to implement / causes real problems, then yeah, no reason to do it. But if it’s even remotely feasible, I and quite a few others would definitely appreciate it. 
It does cause real problems. Just because you don’t see the problems at events doesn’t mean that someone somewhere didn’t have to do extra work to make it look good.
For example, a lot of times (especially for Worlds) the team lists are worked on in Excel (like when splitting up the divisions). Excel does not export to CSV using Unicode by default, so whenever teams use special characters in their name it turns into garbage after going through Excel.
We’ve had to write special scripts on-site at Worlds every year to fix that mess so that it looks good in TM (we needed different scripts each year because the way the team lists were split into divisions is done a little differently each year).
I frequently convert very large data sets to “align” one collection with another. I’ve been involved in this for decades, and through the years we’ve measured the effects of handling “exceptional” data. Historically for us, more than 90% of the labor hours on any data migration, conversion, alignment, or analysis is spent on .001% of the data. It’s often worse than that, with around 97% of the time spent on dealing with special cases created by the “one in ten thousand” records. Obviously, if we knew ahead of time which records would cause the problem, we’d hold those out and process them by hand. You tend to find out how the data record is exceptional or which downstream program can’t process odd data only after hours of analysis and debugging on multiple data runs.
The clients never really understand why we don’t “just handle it” as someone at Fidelity Investments told me once. But we have no control over either the input data or the output processing software.
I named it the “giant chicken” problem, and some other people picked up the term. The very first data analysis project I did was for a chicken nutritionist (who knew?) at Rose Acre farms . He wanted to correlate egg production to a variety of factors, including day/night temperature, relative humidity, hen age and weight, and levels of different nutrients in chicken feed. Things worked pretty well, considering we couldn’t even load the entire data set at once and had to use stream editing and statistical windowing to process things. (2.3 million chickens at any given time, tracked over a three year period. Processed on an Apple II computer with no hard drives and 64K of memory. Uphill both ways, ya’ hear me? And I was grateful. Kids today, with your space-shot pocket computers. Phones? Those ain’t phones. Phones had wires. Those things are computers with radios that talk to satellites…But I digress.)
So, the analysis work was going pretty well, but sometimes a reporting run would fail to finish. Other times, the reports would produce graph curves with good continuity and good trends, until it hit a cliff wall. Our first assumption was problems in the programs I’d written. After much code review, changes to print out intermediate processing data and long debugging sessions, we found it: a data record referencing a 28 pound chicken. Some other data item in that record had caused the input editing/outlier processing filter to skip the record. And the order-of-magnitude weight shift caused lots of statistics to go wonky in our 16 bit integers.
But emojis in team names, sure, why not? I can see the benefit to that. And I don’t have to process any of it.
Interesting. Well I didn’t just mean if it doesn’t work now, just let it go. I also meant that if it’s not completely infeasible to fix then it should be fixed.
For example, money, time, energy, and resources were spent on creating UI and code for the RobotEvents sign up wizard so it did not allow emoji. More money, time, energy, and resources were spent at worlds to deal with those emojis in 2015-16. What if those resources were spent on actually addressing the core problems? For example, you said a big problem was the CSV conversion of emoji that excel can’t handle? Well, why not use those resources to redevelop code within the robotevents csv generation engine that excludes emojis, bypassing any of those issues in the first place? And the same should be done for any similar issues.
Obviously, I absolutely can’t tell the RECF what to do. They have their priorities and definitely know how to spend their money. But the forum is also a place where users like me can make feature and product requests. I just wanted to put the idea of bringing back emojis out there and make sure the RECF knows that a sizable portion of the community has demand for something like this.
I’m not part of the RECF, but just from a coding perspective, I imagine it’s quite a bit easier to simply refuse emojis than to rework the engine to parse them.
It’s always easier to refuse a request than to fulfill it.
Well, you argued that instead of spending resources denying emojis, that the RECF should have redirected those resources to dealing with emojis, but I imagine very few resources were spent. And as @kypyro noted, cutting out even a few corner cases can be a tremendous time saver.
It’s tough enough to work a tournament with teams with pronounceable team names, but emojis are a worthless impediment. I think “no emojis in team names” should be a rule, and not an IT support issue. If the Roman alphabet was good enough for Shakespeare, it’s good enough for VRC.
>:(
Shakespeare often made up his own words to express something he couldn’t with the standard English word-set.
Go ahead and make up your own words for team names, but I believe you should use the Roman alphabet.
I think emojis in team names would be cool, but I don’t see why it’s worth arguing either way for anyone.
I am building a VBA API to interface with VexDB.io, and have already had issues with this.
One team used “}{” instead of “H” in their team name. My API was parsing the JSON strings based on the curly brace characters. I did not appreciate their artistic choice.
I firmly vote against Emojis in VEX data.
that is a lot of chicken tenders …
Also I am against Emojis. That is nightmare fuel for data analysis.
One of my favorites. I am going to have to build a better program to parse the JSON if people pull shenanigans like that.
Hover text was funny too.