> have a means to get it ... in tv broadcasting etc
I think you're missing the point of wearing an analog watch, which is fine, but still missing the point nonetheless. :)
As an avid watch wearer, all analog, I built the game so I could improve my skills, because under pressure when somebody asks "what time is it?", I want to be able to tell them exactly, because I should be able to read it! I think it's good to want to improve your skills, whatever that may be. You shouldn't bar people from that because you disagree.
Appreciate the feedback! It cares, yeah, but being off-by-a-minute doesn't really dock your overall score very much. I figured without that, a "perfect" would be much less meaningful.
Thanks for playing. It's been a fun little game I play to make sure I don't embarrass myself when somebody asks me what time it is, since I wear a lot of watches. I'd love to add a global leaderboard, but right now it's all client-side! A server-authoritative leaderboard seemed a bit too complex, especially i.r.t. preventing cheating, but I might tackle it at some point.
I don't understand how the agent's own authz doesn't match the prompter's authz -- in fact, the agent shouldn't even have its own authz at all! it should always use the prompter's authz, even if that means 'layered' authz (i.e. AND'd) across prompts. Almost all of these prompt-injection attacks crop up because companies decide an agent should be trusted, able to decide its own authz, or that authz for one prompter is the authz of another prompter, which is quite frankly, retarded.
Thankfully, most devs aren't the one making purchasing decisions in B2B. I haven't seen any change in the build vs buy equation for real businesses tbqh, and in B2B, those are the customers you want to target anyways, not the indie devs who think they can build Dropbox in a weekend. In B2C, I can definitely see this being true, but I have very little experience there so anything I say here is more on gut-feeling than anything else. But I have over 10 years of experience in B2B, and I've never seen businesses more eager to buy, to free teams up to work on the things they're experts at -- myself included.
I did this exact thing this year. I moved about >5 TB of event and log data into Clickhouse. I went from having to increase Postgres storage capacity every few months ($$$) to never thinking about it. Migrating to Clickhouse took me from constant timeouts on analytics queries to all queries returning in well under 100ms, and automated data retention using TTLs going from nightly pruning jobs that failed constantly (Postgres hates DELETEs on large tables) to again, never thinking about it. Because of this, I was able to increase retention per-account from a mere 30 days like I had -- just to keep performance and storage costs under control -- to much, much longer. Huge fan.
> Our philosophy through this transition is to bring existing projects along, not to force a hard break. Studios shipping on UE5 today should expect a manageable, and clear path forward when UE6 is ready for them. To allow for this, Actors and Blueprints will be in early versions of UE6. Eventually, these will be deprecated when the new framework is sufficiently mature, and you’ll have conversion tools to move projects from one framework to the other.
Very interesting to see them deprecating Blueprints. The proliferation of Blueprints is actually why I chose Unity DOTS over Unreal. I wanted to code (especially with LLMs), and from who I talked to, the industry seemed to use Blueprints more than code for gameplay scripting, which didn't appeal to me at all.