Text properties are basically useless because we can’t extract anything from them.
I’m basically extracting the few digits of information I need using mod functions and floor functions.
fr? then I got nothing
yeah that’s what I thought
O.O.P. (that’s the acronym for it right?). Anyway, O.O.P. would be hard to implement as each number
property has a max of 11 characters. That’s only 11 bits, while that allows you to get numbers up to 2047
that’s not much. So if we wanted more bits to store data in “objects” we’d need more properties. While I don’t know the limit on properties that’d still limit us greatly. We wouldn’t even be able to use all 11 bits effectively because we’d have to check every possible combination of 1’s and 0’s. 11 bits gives us 121 different possibilities. We only have 75! we could use text properties, that’d give us 256 bits. that’s Impossible to use effectively with the restraints we have. If team gimkit gives us increased limits for having Gimkit Pro or the Ticket Pass then this might be simpler. But! We don’t have to use bits I didn’t even have to go on that tangent. As for functions, we could use something like an item granter you know how much I like using those to code or a trigger (anything that can have block code for a channel) and have the function there. Then use the property to store the answer. While we could use individual properties for each function that’d use a large amount of memory and could have multiple devices using the function at the same time and ruin it. There’s also a possibility of using a “request function#” and a “request function str.” property we could have. This could be used by all devices. This all depends that there’s no delay between channels, or a delay long/short enough that it doesn’t interfere with anything. We’d have to have a “function requester” property if the function is essential (or needs to happen right now) to call the next part. This all seems possible theoretically but might be limited with memory.
Wow, that was a big block of text just for functions. If I said something that had already been said, it’s because I haven’t read the replies yet. I might expand on this with more things such as classes or whatever. But that’d be basically building a coding language from scratch. I’ve also spent an hour on functions so I’m done writing for now. Now that I think about it, this is building a coding language from scratch (or at least how close we can get from scratch on GKC).
2 Likes
i tested this and it works. Anyway, that’s enough for today. i spent way too long on researching and doing.
EDIT: I just realized I figured out a basic “getting” of functions. I don’t think running block code inside a different workspace inside the one where the code is happening is possible. obviously my example isn’t practical as there already is a subtract block. and that is all the function is doing. but i tinkered and found, you do need to use the results inside a different workspace. The experiment was only for stuff right after, so you could run all the stuff at the start of the code, And it might work like that? you could also have a hub for functions if you use them a lot in your device. Functions would be useful just in normal GKC so i think the stuff i did is useful.
I know I said I was done but I’m done for real this time.
if anyone sees this, could we maybe start working on this more tomorrow after school
2 Likes
Uhhhhh… no. Properties are able to store I think around 32-48 bit numbers, I can’t remember if 48 bits worked, but I know 32 bits works.
I’m Not talking about integers, I’m talking about binary. And after reading the replies, I’ve learned we can’t use strings. Integers would work better though. I think the function calling would work better if we figure out memory allocation though. This would make the single property function more reliable.
I’m using 32 bit numbers to store data for a color display, so you can definitely fit 32 bits in a property…
3 Likes
You can store 11 digits in a number property. So that’s 11 binary bits that we can use. We can use all 32 (if the 48 is the bit limit then 48) with integers.
So like 0000010101 is 21. Binary wouldn’t make sense though, so why use it. Ig binary might be useful for encoding since we can’t use strings.
Memory allocation could also be as easy as a Boolean property turning true and false as it lets different devices use the function and a check.
I’ll continue this in the morning. It’s currently the middle of the night and I have school tomorrow. I’ll be on for a little longer. But after that I’m going to not get on until the morning
You can store stuff in base 2. So storing 19 would look like 10011.
Yep
And there’s 14 digits available. Using a bit of math stuff, we can expand to 16 digits that store the same amount of info but in a Boolean and a base 4.
1 Like
When I got onto see this post and see that, wow. Great work, Cryptoraider!
Ok, I went back and did some actual math:
Remember that each digit in a property can hold a number from 0-9, so we can just turn the binary number into a base 10 number:
binary: 11111111111111111111111111111111111111111111
base10: 17592186044415
This is a 44 bit binary crammed into 14 base-10 digits. I’m sure there are ways to optimize this even more though. Using binary numbers to store large amounts of data is a pretty effective method. So effective, in fact, that the devices we’re making these posts on encode everything in binary.
Using 100 properties, this allows us to store 4,400 bits, or a bit over half a kilobyte. This is 550 ASCII characters. If we make our own ASCII like system using only characters required for JSON or something (abcdefghijklmnopqrstuvwxyz1234567890[]{},"'), we can cram 733 characters in.
From here we could just do something similar to text operations where we just make a new system for storing data, but for classes instead of text. I did have a thought about using a JSON-like format for this, but I have schoolwork to do so I’m not gonna expand on that for now.
2 Likes
Quick clarification: we’re doing all this just bc there’s no blocks for advanced text manipulation?
Yes.