Reading through the forum I am finding a wealth of links, including a lot of redundancy with documentation that either is outdated, or outdates other documentation, which I have also read.
In what I believe to be the most current documentation on the Blinks API, I found a section on Datagrams, all entries in that section currently have a beige highlight. I would soon find, that the highlighting means the entry for those functions are empty.
Do we have an API with the entries for datagrams filled in?
I am looking for a function that will cause one blink to ask for, and receive information from two neighboring blinks. The asking blink wants to know how many faces of each color (out of four colors) both neighboring blinks currently have lit.
1.Do datagrams concern themselves with this ability?
2.If Datagrams do not concern themselves here, is there a better function to use?
3.There is an assumption that a blink can “send” the value of each of the six faces, and not just the face that the asking blink is connected to. Is this indeed the case, or is my asking blink only going to receive information on the exact connected face of its neighbor?
Datagrams work as per the defined API. There is one caveat that datagrams are best effort so there is no guarantee a datagram sent to a face will reach a Blink connected to that face (but most of the time it does anyway). I did write a custom Blinklib primarily to address this (it adds support for guaranteed delivery of datagrams):
You can always check the blinklib.h header file for documentation on available functions (link to the official Blinklib):
You can use datagrams to do what you want, yes. Considering the entropy of the information you want to expose is actually bigger than what you can express in a face value (without some form of complex signaling on top of it) it is most likely the best way to do it.
A Blink “knows” everything about itself, so it known the value of datagrams and values received in any face, can know the color of any face (this is a fun one because there is no way to read the color of a face, so you ned to keep track of the color you set whenever you set it). So yes, you can received a datagram on any face, obtain information about any other face and send datagrams to any face (there are some caveats, but this is all generally true).
I am not sure what you mean, but the only way to set a face to a specific color is by telling it what color you want. So one way or another you can always know what color you set it to and act accordingly. Querying a face for its color would be convenient and save a few bytes of memory but is not a requirement to do anything.
I have no idea what your programming experience is, but being random or not is irrelevant in this context. Lets assume you have a function that returns a random color:
Color random_color();
you can always do something like:
Color face0_color = random_color();
setColorOnface(face0_color, 0);
You can always refer to face0_color to know what color was set, it being random or not.
Also note that you will most likely not send a color through a datagram. You will send a number that represents one or more colors and on the receiving and you would have a function to convert that number to an actual color (usually mapping an enum into an array) if needed.
Right or wrong, this was at least a thoughtfully made design decision. The color representation typically used at the blinklib level uses 3 bytes - one each for red, green, and blue. Once the color of an LED is set, the platform does not need to remember the full R,G,B values and so instead keeps the color in a more compact format internally. In order to give the programming layer the ability to ask what the original RGB color the the LED had most recently been set to, the platform would need to store these otherwise extraneous 3 bytes per pixel for all 6 pixels (18 bytes total), which can be significant on this tiny platform. While it would be convenient to have a built-in function to check what the most recent RGB color and LED had been set to, it would consume these 18 bytes of RAM in every game - even those that did not use it. So instead we decided it was better to let games that needed to be able to check the previously set RGB value to store it themselves, which is trivially easy to do.
In practice many programs use a model-view-controller pattern for blinks games (or at least a tiny version of it!) where the colors that are set on the LEDs are based on some other internal state, and it is easier to just refer to that state directly rather than setting a color on the LED and then going back to get the color from the LED. At least for me, this makes for simpler and easier to debug programs - but it is a matter of taste and it only takes an extra line or two to store the LED colors when setting them so LMK if you want some examples!
In broad strokes, I was aware, that as other games did do this, there had to be a way to do it.
The exact logistics, not so much.
Being able to take a snapshot of one instance of random, and making that instance more or less permanent in comparison a bit more.
Vague memories of = vs == a bit more, as I some how passed one course of Java and a separate course of JavaScript in college, and felt that, i had reached my aptitude halfway through the semester.
The real, and obvious frustration, mostly coming from my years of experience if it can be called that, in LOGO shaping up to be full of experience I can’t use.
I’m torn between the programing I do know, versus what blinks can actually do. And everywhere I turn, serves to only widen that chasm.
I feel like I’ve worked my idea around (yet again) to a faithful and playable experience. Which, i think is more than enough given I only got my blinks on 31 May. … And my dev kit still on order.
In treating the news that I couldn’t pass colors in the way I had originally intended as a hard limit, I started to question, ultimately, if I even needed that function in my game.
Perhaps it’s not a good sign, that I resolved that my game can require basic math, because Monopoly itself has multiplication in it. – Not that Monopoly is a paragon of good gaming.
Finally, sending colors as I originally intended, motivated only a faster shortcut to aid scorekeeping. Nothing that couldn’t be done, at worst with pencil and paper, if not mentally.
And, apparently, this resolves a memory bloat issue, and lack of skill issue.
Also, I think my proof of concept gets made without a single user created nested if.
When done correctly, the entire blink dev experience is going to be a metric ton of Nested If Loops, and other loops, right?
I suggest you brush up your programming skills and, more specifically, try to get a grasp on how the C language works generally. That will be a requirement for creating any compelling game for Blinks (note compelling does not imply complex). The best course of action would be to check sample code bundled with the Blinks SDK and try to understand how they work (maybe even doing small changes to them). After that, you might want to check the source code of actual games (starting from smaller ones and moving your way up to the more complex ones).
Not if I am the one writing the code, no. Also, although I understand what you meant, an “if” is not a loop statement. It is a conditional statement. Note that although you might not have nested ifs (or loops, for that matter), you might still have lots of them scattered throughout your code.
I was pretty much already going this route anyway, and I felt bad for doing it. however, as I have seen other people thumb through what has gone before, I remind myself, that this community, and I can only assume all programing communities, and, frankly, all open source communities, tech, or otherwise, are open, for this exact reason.
In what I have written (on paper) for my game, I have citations on where I can find relevant code snippets from Wham, the “Aw Shux” / “Doorscape” game that Dan King posted on Youtube, and other pieces from the actual examples.
While I take your point for “complex” I think we can both agree that I am not there yet.
I believe I can get my idea “running” and the experience playable and interactive ((As Interactive as a game of cards can ultimately be, as this project is descended from Poker)) … if not with obvious steps that can trade physical time and physical math for tasks the blinks themselves can do. Memory permitting. At that point, I hope to release what I have, as cobbled together as it is, to simply have a foundation to start from. Hopefully you guys willl look at it, and can point me in a further direction.
No sooner did I type this, … the notion of the If statements, did I then find that a lot of Ifs and a lot of loops in general is a glaring hallmark of bad code / and a bad programer.
What I was speaking to, was the notion that Arduino uses a void loop, and that all of the code, after set up is (and apparently, has to be) content to run within that loop itself. And that from that, everything coded is either in the void loop itself, constantly looping, or built into further loops, still within the original void loop.
There is another question I am starting right after this. I need to confirm one assumption, and if so, I think it will remove an issue I have with Blinks at large.
Also, although I understand what you meant, an “if” is not a loop statement. It is a conditional statement. Note that although you might not have nested ifs (or loops, for that matter), you might still have lots of them scattered throughout your code.