Archive: 19 posts

---

*Edit* Sod it, I've decided to think of an easier way to do this. I've left the original post here for people to boggle at. Sorry to be facetious, as I'm not really asking for help, but I am currently setting up the logic for a password system in a level with 30 stages, and the password mechanic is a 5-digit code using the image buttons on the pad. So that's 625 possible combinations, BUT, I am only putting the logic in for the 30 'true' combinations so it's not so bad. However, each password has 5 digits, and I'm using a branching microchip method, so that's 150 microchips I'm going to have to open up and wire together. Bleeergh, I don't think there are many jobs more tedious. If anyone has any suggestions for an easier system to implement, which will let me have a password for 30 stages but one not easy to guess passwords for, and one which doesn't involve giving away stickers....please let me know! I made the job of creating passwords slightly easier by writing a simple C++ program to generate 30 random passwords, then pasted them into Excel and ordered them by first digit, then second digit, etc, to minimize the amount of microchip opening I'll have to do. At this stage I'm wondering if it's worth doing at all, as people will no doubt post the passwords anyway...but the later levels are quite tricky and I don't expect people to make it all the way through in one sitting.

2011-03-06 03:31:00 Author: merkaba48 Posts: 79

---

I created a puzzle using password logic in my research level. If you want it or want to check it out, try the level in my sig "Research" and tell me if you're interested. There are 26 lights in each row. (Like the alphabet) And there are 7 rows. That's a total of 8,031,810,176 combinations.

2011-03-06 06:14:00 Author: Devious_Oatmeal Posts: 1799

---

Thanks, just tried it out. It's neat, but I don't think its for me I'm actually going to go the sticker route, but only give out a levels sticker if the player requests it. That will prevent cheating too, making the scoreboard results more accurate. Your level was pretty sweet btw. I had trouble with the sackbot puzzle though, because it took me ages to realize they could double jump...then when I got back in the elevator after finishing that puzzle it took me back down to level 2....then I died on the plasma door and I'm not respawning Nice ideas in there though. (edit) just replayed, the elevator went down a floor again, but I activated it again immediately and it took me up 2 floors to the correct spot. Now I'm standing in an empty area...level not finished?

2011-03-06 14:18:00 Author: merkaba48 Posts: 79

---

I was working on a password chip (ordered input) logic last night, it's actually much easier than you might think. Now you will have to wait until later to see a picture of the logic circuit but I will try to give you an outline on how it works, also my method (I am probably no where near the first to do this though) allows for easy customisation of the code length and code itself. Okay so: The whole thing is based on the use of 2 MC's* one MC holds the password and the other is actually the controllinator chip which fires off the button presses and checks each correct entry. Right on the first MC lets call it MC1, we have a sequencer that's set to POSITIONAL with it's input from a counter* and set to NOT LOOP (this is important!), labeled tags are then placed on the sequencer to represent each character of the code/password/order of input eg triangle,square,R1,L1,circle,circle,x get the picture?. Right so in my example we have a string of 7 inputs = 7 positions on the sequencer with 1 tag per position (just re-order/re-label the tags to change the code). We control the sequencer with a counter set to a target count of 7, this counter will increment EVERY button press. Then we need another counter to count the number of 'correct' inputs, this counter should also be set to a target of 7 and will ONLY increment when the correct button is pressed. Each counter is then fed into an 'AND' gate which will only send an 'unlock' signal if bother counters reach there target count, but we will come back yo this! Each counter is incremented via it's own TAG sensor (not the same for both), the first counter waits for a TAG labelled 'increment' , the second from a tag labelled 'positive' or 'correct', okay so far? Okay, to set up the inputs we go to the controllinator board & create an MC, in here we place a TAG sensor wired to another tag labelled 'positive' or 'correct' or whatever you like, we also place another TAG on the chip labelled 'increment' or 'next'. Create a copy of this MC for every button you want as part of your password and then wire in said buttons, the TAG sensors must then be colored and labelled to correspond with the TAGS on the sequencer of the first MC. The result should be for example that when 'R1' is pressed it turns on an MC which always increments the first counter on MC1 , and wil also increment the second counter of MC1 BUT ONLY if the corresponding TAG is activated on the MC1 sequencer, rinse repeat for each button press, remember that the 'unlock' or 'activate' signal is given only if both counters of MC1 reach their target count. And ther you have it, actually very easy! oops..I almost forgot, our old friend/enemy latency requires that you use an inverted 0.1sec timer (reset on activation) between the buttons and SENSOR MC's on the controllinator, this is to give enough time for the sequencer to step to the next TAG and then SENSE them on the same MC. OMG I hope at least one of you can make sense of my text, at least enough to realise that once built this '2 MC' system is very easily customised for any code and any string length. If not I will upload an image of my build once I can get to my PS3. Hope this is useful! *The controllinator MC and a separate MC must be used because TAG sensors won't respond to TAGS on the same MC, and since my logic uses TAGS/SENSORS..well it's obvious!

2011-03-06 16:04:00 Author: CloaknBlagger Posts: 78

---

I'll be patiently and anxiously waiting until you can post pictures. I've been waiting and trying to figure out how to make a system of persistance to carry over character development between levels. There's already a couple of other threads about "saving" logic, or at least emulating it anyway. Still... stoked to learn something new.

2011-03-06 18:36:00 Author: DigiOps Posts: 111

---

That's sounds like a nice tidy way to implement this (though pictures would be helpful as I don't fully understand the last paragraph yet). I imagine it would still be a lot of work to do this for 29 different passwords? I'm considering cutting it down to 10 passwords; one every 3 levels.

2011-03-06 19:29:00 Author: merkaba48 Posts: 79

---

Actually no, all you would need to do for extra passwords would be to wire 'n' (eg 29) number of sequencers through a SELECTOR to cycle through when needed, so it would be first COUNTER to OR gate with 'n' ports to each SELECTOR port (1 per sequencer). Neither the controllinator logic or counters would need any duplication unless you start to use different length strings (number of buttons per password). Hope I will be able to upload the image in the next hour or so, sorry if you have to wait a little longer. ....also the latency thing is simply means that you have to turn on the MC's on the controllinator just a fraction longer than a button press might be so that the data has time to register true or false. This is because with this method the controllinator MC's control both the stepping of the counters (and therfor the sequencers) but also detect whether the TAGS that are activated AFTER the step match the button press. We need the timers on the controllinator give the MC's chance to work. (maybe I should have started with that sentence. Okay now I'm gonna try to get on my PS3, (I have chldren you see so time is not my own!)

2011-03-06 21:11:00 Author: CloaknBlagger Posts: 78

---

I've got a demo level I published that shows off a 5 digit passcode system that could easily be expanded to 8 digits (or more if you change tag labels instead of just colors). It takes input from multiple contollinators which each have there own target passcode which is fed into the system wirelessly. I would be happy to show you the logic if you want. Here's the level link http://lbp.me/v/y79mrz . If it looks like something that might work for you let me know and I'll show you in edit mode so you can see how it works. My PSN is Dilz669.

2011-03-06 21:20:00 Author: Unknown User

---

So here is the photo I promised I'm kinda in a rush so I will answer questions later.......http://i5.lbp.me/img/ft/995b4e2cc7e75b180ed76d7a5a2a1537ff871052.jpg ...note: the version above has only a 4 string password but the principal remains the same and also the ability to expand it as much as you like!

2011-03-06 21:42:00 Author: CloaknBlagger Posts: 78

---

I have an easier system. If you hook up DCS buttons to level links, you shouldn't be able to enter locked levels. Then all you need to do is find some way to slip keys to the players in a cutscene or something.

2011-03-06 21:45:00 Author: Green-Tomato Posts: 140

---

If anyone has any suggestions for an easier system to implement, which will let me have a password for 30 stages but one not easy to guess passwords for, and one which doesn't involve giving away stickers....please let me know! Rather than using predetermined codes, I'd probably do it using a checksum-like system, where part of the code contains the number from 1-30, and the rest of it is generated using some reasonably obscure algortihm, so when the player inputs the code, you just check the checksum matches, and if so, accept the number as a valid input. Kinda depends on the mechanism you're using to input the code - one of my earlier variants used a shift-register system to accept all the inputs, then check the data is valid after the complete code is entered.

2011-03-06 22:09:00 Author: Aya042 Posts: 2870

---

There's some real good ideas in here, and I thank you all for contributing and suggest posting to the tutorial forum if you have something new to show (I'm looking at you in particular, CloaknBlagger). I decided in the end to plough on with my original plan, but with only 10 passwords of 4 digits length each. My system isn't as eloquent as many suggested here, and I basically have a big branching set of microchips so its heavy on logic usage; the whole system is emitted then destroyed after the title screen so it shouldn't affect the rest of the level. For the curious, here's an example of how NOT to implement a password system http://id.lbp.me/img/ft/19ddc0d9f6fdda5b98b85e108a91b1f5908aaa8f.jpg

2011-03-06 22:34:00 Author: merkaba48 Posts: 79

---

I've got a demo level I published that shows off a 5 digit passcode system that could easily be expanded to 8 digits (or more if you change tag labels instead of just colors). It takes input from multiple contollinators which each have there own target passcode which is fed into the system wirelessly. I would be happy to show you the logic if you want. Here's the level link http://lbp.me/v/y79mrz . If it looks like something that might work for you let me know and I'll show you in edit mode so you can see how it works. My PSN is Dilz669. Actually the colours have nothing to do with my system, the colours just represent the buttons on the controller, All you need to do to expand mine is as you said, change the labels within the tags on the sequencer (the sequencer holds the code) or increase the target for the counters to say 32 and lengthen the sequencer accordingly and add more tags! It really is VERY SIMPLE, the only thing I haven't shown here is the reset mechanism for failed entry, but that only takes 2 more components!..I think you should figure out what! Rather than using predetermined codes, I'd probably do it using a checksum-like system, where part of the code contains the number from 1-30, and the rest of it is generated using some reasonably obscure algortihm, so when the player inputs the code, you just check the checksum matches, and if so, accept the number as a valid input. Kinda depends on the mechanism you're using to input the code - one of my earlier variants used a shift-register system to accept all the inputs, then check the data is valid after the complete code is entered. Yes I completely see where you are coming from here, pretty much how most software developers generate the activation keys for their software and if you need that many variants you can't just write a list of pre-determined codes for it. As usual though the application of one solution over another is determined by it's contextual demmands, and in my case I only really needed a simple method, I didn't for example need a 'parity bit' error check.

2011-03-07 00:14:00 Author: CloaknBlagger Posts: 78

---

As usual though the application of one solution over another is determined by it's contextual demmands, and in my case I only really needed a simple method, I didn't for example need a 'parity bit' error check. Well, that was more aimed at the OP, and based on the original spec (30 valid codes from 625 possible), I figured it might be cheaper on the thermo to do it this way, rather than a more 'brute-force' approach, but I haven't really looked at other possibilities. I only mention it, cos it seems similar to something for which I previously implemented this system, to handle 220+ valid codes from 240 possibilites, represented as an 8-character code from 32 of the 36 letters and numbers.

2011-03-07 14:59:00 Author: Aya042 Posts: 2870

---

Well, that was more aimed at the OP, and based on the original spec (30 valid codes from 625 possible), I figured it might be cheaper on the thermo to do it this way, rather than a more 'brute-force' approach, but I haven't really looked at other possibilities. I only mention it, cos it seems similar to something for which I previously implemented this system, to handle 220+ valid codes from 240 possibilites, represented as an 8-character code from 32 of the 36 letters and numbers. Sorry Aya042, I didn't mean to dig, (my kids were getting the better of me at the time and my fuse was just a little short), and I absolutely agree that your method would be far more useful for multiple variants, and in retrospect, once built just as easily implemented for ANY scenario where a code/password was needed, please accept my apology. ..furthermore it seems my design is slightly bugged because the TAG signal from each previous step seems to echo somehow (pretty sure this is latency again), so that for example say my code is square,X,triangle,circle if I press square twice in succession it registers as being a positive entry and pushes the second counter up anyway, now I don't think this is a problem with a long enough string, say 7-8 or more (still testing and refining), but for only a 4 length string it sometimes gives a false 'success' for the whole string?? mm....I am wondering whether swapping the TAG/SENSORS over would solve it, any thoughts?

2011-03-07 16:10:00 Author: CloaknBlagger Posts: 78

---

Sorry Aya042, I didn't mean to dig... No need to apologize, I didn't even interpret it as a dig - on the contrary, I welcome alternative points-of-view, and you are correct that, given sufficiently few possible codes, that a 'brute-force' solution is more efficient from a thermo POV, and sometimes that's reason enough to use it over a more generic solution. ...pretty sure this is latency again... I can see two potential latency issues: one with the sequencer input, which there's no workaround for, as far as I'm aware, and one wherever you connect a Tag Sensor's output to a Tag's input, for which this post (https://lbpcentral.lbp-hub.com/index.php?t=49984-Comparing-4-analog-signals-to-find-the-strongest&p=786106#post786106) might be of interest.

2011-03-07 17:55:00 Author: Aya042 Posts: 2870

---

Eureka!, yes thank you Aya042, I read your linked post, it makes perfect sense as to why the error is likely occurring. I managed to negate the latency at time of sequencer/counter reset pretty easily (after a full string had been entered) np, but without control over the component update hierachy (shame) there will always be a degree of latency with each read/write pulse whilst mid string. I can negate the effect so that the logic works perfectly every time but each workaround is at the expense of input response time (so far) bugger!...there are still a few tricks to try but I fear my simple solution may not be so simple by the time I am finished, ho hum. The good news is that the overall false/positive effect is reduced with longer strings, but I am a stubborn B@$t@?d so we will see what happens. Nice post Aya042 thank again!

2011-03-07 21:52:00 Author: CloaknBlagger Posts: 78

---

I can negate the effect so that the logic works perfectly every time but each workaround is at the expense of input response time Once you understand how to control the update order, you should be able to eliminate all latency from a circuit, with the exception of... Some feedback circuits, for example, chaining NOR-based SR-latches, you'll always get latency in one direction, but it's pretty obvious that, given the update order is fixed, there's no one order which will work in both cases. Sequencers, which in most cases you can replace with an alternative implementation. It may cost a little more on the thermo to do this, but it's your choice as to which of latency or thermo-cost is more important. With regards to your use of, what looks like, a counter controlling a sequencer, it would seem as if you could create something similar using a selector, but it's tough to tell exactly what it does. With regards to enabling tags generally, you may find that emitting tags works better - I made some logic gates (https://lbpcentral.lbp-hub.com/index.php?t=23400-Zero-Latency-Set-Reset-and-Toggle-Switch) in LBP1 based around this principle, which operate in a single frame, and they still work correctly in LBP2. However, I'm guessing that in your case, the tags represent the code, so emitting may be too much hassle.

2011-03-08 14:32:00 Author: Aya042 Posts: 2870

---

Yes, I had thought about using selectors instead of counters, as it happens I am now building a different 'engine' in which sequencers have been banned!, very much along the lines of the sequencer model in terms of 'pure logic', but without the need for TAG based strings, I won't say too much yet but my comment about a 'parity bit' got me thinking!

2011-03-08 16:36:00 Author: CloaknBlagger Posts: 78

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.