Archive: 4 posts

---

Ok, so I've been messing with getting an analog scoring system set up, but analog calculations in LBP aren't my strong suit. I get how it works for the most part, but I just can't seem it get it to work some of the time. For example: Two batteries set to 80 and 70 run through a direction combiner gives 10 as expected. Same batteries set to 70 and 60 gives 9 Run that 9 through an OR gate with 10 inputs set to addition, and you get 99 Subtract 90 from that and multiply again, you get 99..it keeps repeating like that at least through 4 more iterations. This seems to be true whether I use counters, batteries, or whatever. I'm going to need to do quite a few calculations in my level. While these inaccuracies can be worked around for simple values, I'm afraid they will interfere with the final total. Anyone know a way around this?

2014-11-28 07:37:00 Author: tdarb Posts: 689

---

Not really, you just work with it. Like, use the value in an analogue manner so small inaccuracies don't matter, or set your discrete boundaries wide enough to allow for them. As an example of the latter, if I have possible inputs of 0, 10, 20, ... up to 100, I set up my logic to check against 5, 15, 25, ... up to 95.

2014-11-28 12:37:00 Author: Rogar Posts: 2284

---

Well that stinks. I was hoping for a magic bullet. My possible outputs will be from 0-1000 (0-1000000 on the final score). That's a lot of potential for error. I'll have to look at it more, but is it always specific values that do this? Should I go down to .0001 for my main scoring, and .0000001 for the final, so I can properly adjust? If I wasn't so stubborn I think I'd just give up and go back to binary, but it bugs me that it's not working It will be interesting to see how the thermo/latency compares with the binary counterpart once it's done and has display elements added.

2014-11-28 17:41:00 Author: tdarb Posts: 689

---

I've decided that for this specific purpose analog isn't the answer. I really have to go digital for the scoring here. One thing that I did find is that in my tests all the numbers that were not dead on were divisible by three with a remainder of five or seven. Tygers also mentioned this in a blog post when using timers (I was using batteries), so there must be something there. Another interesting thing I noticed in one test was that the numbers 7, 11, 13, 14, 19, 21, 22, 25, 26, and 28 were the first to appear with errors. Once I started comparing the values on my results of all the numbers up to 100, I noticed that the numbers with errors that were evenly divisible by three appeared in the same sequence (21, 33, 39, 42, etc when divided by 3 equal the initial sequence). This pattern continued up to 90 (30 in the initial sequence), so there's something there. I just don't have the patience to suss it out. Anyway, thought I would post this for any others out there looking at the inconsistencies with analog numbers. Hope it helps someone.

2014-11-30 04:47:00 Author: tdarb Posts: 689

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.