Archive: 31 posts

---

Hello fellow creators. I am having a few problems involving tags and tag sensors. My level involves a fair amount of logic, and a lot of tediousness is involved in setting the logic up, so I am (or was, rather) trying to come up with a more efficient (in terms of time, effort and thermo) way to do it. Part of this process involves sending signals through several tags and tag sensors. In most of the cases, it works fine, but in one instance, there seems to be a delay at some step along the process, which causes a major problem. All I'm doing is sending the signal through tags, there may be the odd 1-shot pulse counter, but no timers that would delay a tag being activated. Has anyone else had this problem, and has been able to come up with a solution? Thanks.

2012-01-19 13:37:00 Author: Ali_Star Posts: 4085

---

I just stuck 100 pairs of tags and tag sensors in a row and there is indeed a delay. Measuring it with a timer the delay came out to 3.3 seconds total. (1/30)*100 = 3.3' so there's 0.03 seconds, or 1 frame, of delay per tag sensor.

2012-01-19 13:58:00 Author: Ayneh Posts: 2454

---

I have more than that in my entire level, but for the section I'm talking about, we're talking about one tag activating a sensor, which is connected to another tag, which activates another sensor, which activates another tag..... I think there's one more step involved, but I can eliminate that step and the same problem still occurs. It's so annoying. Tags and their sensors can be real pains when they want to be. I've had situations where a pulse activates a tag, which is picked up by sensor that is connected directly to another tag. Sometimes, the sensor that picks that signal up, won't recognise it (even though I've laid it out identically 3 other times and it works fine), but if I remove the direct connection and put a 1-shot pulse in between..... it will work. Very strange.

2012-01-19 14:23:00 Author: Ali_Star Posts: 4085

---

How long is the initial pulse which activates the first tag? Have you tried just keeping it on and watching each tag activate in succession (eg: using lights or just watching the wires)? Also, you sure that they were all sensing tag strength, and the detection area was correct? The system you describe (1>2, 2>3, 3>4, 4>5, ....) is what Ayneh tested above. I can't imagine it would fail unless there is lag compromising your logic, some incorrect sensor, or the initial pulse is too short. A pic of your basic setup would be helpful.

2012-01-19 14:48:00 Author: SSTAGG1 Posts: 1136

---

I'll try and have another go tonight, and if it fails I'll post a picture. The tags are on their default setting with regards to how they detect (strength or the other one) - could this be why it is failing? Like I said, the previous method works. I haven't actually changed much. The ranges are all ok though. I might as well tell you why my logic is failing: Basically, my level is a turn-based multiplayer game. I want the it to change player when one tag is activated (let's call it tag A), but another one isn't (tag B). They're both supposed to be acitvated at the same time (for the player change not to happen). No timers involved, thought they're passing through different amounts of logic to get to the end destination. The problem is that when tag B is activated, there is the delay.... so it goes ahead and changes player when I don't want it to.

2012-01-19 15:10:00 Author: Ali_Star Posts: 4085

---

The tags are on their default setting with regards to how they detect (strength or the other one) - could this be why it is failing? Bingo. There's your problem. Switch them to strength detection and it should work. I can't tell you how often something this simple has completely crippled my logic. I don't see why strength isn't the default.

2012-01-19 15:22:00 Author: SSTAGG1 Posts: 1136

---

I have more than that in my entire level, but for the section I'm talking about, we're talking about one tag activating a sensor, which is connected to another tag, which activates another sensor, which activates another tag..... I think there's one more step involved, but I can eliminate that step and the same problem still occurs. It's so annoying. With the last step eliminated that should result in a 0.06 second delay. Tags and their sensors can be real pains when they want to be. I've had situations where a pulse activates a tag, which is picked up by sensor that is connected directly to another tag. Sometimes, the sensor that picks that signal up, won't recognise it (even though I've laid it out identically 3 other times and it works fine), but if I remove the direct connection and put a 1-shot pulse in between..... it will work. Very strange. If there's a 1/30th of a second delay between the tag switching on and the tag sensor outputting a signal then a pulse, which also lasts for 1/30th of a second, is unlikely to activate the next sensor in the sequence. When you add the counter between one sensor and the next you're essentially lengthening the duration of the signal, which allows the next sensor in the sequence to be able to register it. Maybe SSTAGG1's solution works because you don't need a full on signal to trigger the sensor when it's set to strength scale. That's my intuition, anyway.

2012-01-19 15:36:00 Author: Ayneh Posts: 2454

---

Bingo. There's your problem. Switch them to strength detection and it should work. I can't tell you how often something this simple has completely crippled my logic. I don't see why strength isn't the default. Isn't there a problem with using strength as a setting, in that if I have a tag which is activate by.... say, a 4-count counter - wouldn't that result in the tag sensor giving a 25% output if the count is at 1? EDIT: Also, if the tag sensor is set to a count of 4, will it give a 25% output if only 1 tag is active? With the last step eliminated that should result in a 0.06 second delay. If there's a 1/30th of a second delay between the tag switching on and the tag sensor outputting a signal then a pulse, which also lasts for 1/30th of a second, is unlikely to activate the next sensor in the sequence. When you add the counter between one sensor and the next you're essentially lengthening the duration of the signal, which allows the next sensor in the sequence to be able to register it. Maybe SSTAGG1's solution works because you don't need a full on signal to trigger the sensor when it's set to strength scale. That's my intuition, anyway. That's fair enough, but it still doesn't explain why it worked for 3/4 of the tags, when they were all set up in the same way. I had a similar problem with my BattleSnakes level. Like in the classic game of Snake, you are able to pass from one side of the "board" to the other. I did this by having it delete your snake when it got to one side, and emitting it from the other. Using similar methods to scenario I described earlier (without having that extra counter in place) I found that it was working fine initially..... then some of the emitters randomly stopped working whilst others kept working (I initially had about 100 emitters, 1 for each edge position... until I found a better way to do it), so it's clear in my eyes that the tags are inconsistent.

2012-01-19 15:53:00 Author: Ali_Star Posts: 4085

---

That's fair enough, but it still doesn't explain why it worked for 3/4 of the tags, when they were all set up in the same way. What do you mean by "same way"? Take a few of those tags that seem to operate differently to you, orientate and space them all the same as each other, check that the sensor settings are identical and activate them together. There's no reason for any of them to act differently to each other.

2012-01-19 16:37:00 Author: Ayneh Posts: 2454

---

"Same way" in the sense that the only thing that's different, is the naming of the tags.

2012-01-19 16:40:00 Author: Ali_Star Posts: 4085

---

If it does pose a problem, a one shot counter after your 4 count counter would remedy the situation, though doesn't the tag sensor have to be receiving 100% for it to be turned on digitally? So I wouldn't think it would cause a problem, unless the analogue signal influences something else in your logic.

2012-01-19 16:41:00 Author: Xaif Posts: 365

---

"Same way" in the sense that the only thing that's different, is the naming of the tags. Can you describe which names we need to enter for otherwise identical tags that make them operate differently so other people can replicate this? It's an interesting finding.

2012-01-19 16:52:00 Author: Ayneh Posts: 2454

---

Probably best to just get someone to come see what you've done. I'd help, but no access to PS3 here.

2012-01-19 17:16:00 Author: SSTAGG1 Posts: 1136

---

Can you describe which names we need to enter for otherwise identical tags that make them operate differently so other people can replicate this? It's an interesting finding. My tags are thus: Business Guy 1 Business Guy 2 Business Guy 3 Homeless Guy ...... for some reason, "Business Guy 3" doesn't work. No, but seriously, they're just named U, D, L and R... for the directions. You'll just have to trust me on this really. It's probably just a consequence of having too much logic in a relatively small space. Probably best to just get someone to come see what you've done. I'd help, but no access to PS3 here. I'm gonna give it another go first, do what you said and turn the tag counters to the strength setting. The I'll report back.

2012-01-19 18:32:00 Author: Ali_Star Posts: 4085

---

My tags are thus: Business Guy 1 Business Guy 2 Business Guy 3 Homeless Guy ...... for some reason, "Business Guy 3" doesn't work. I expected Homeless Guy to be out of a job...

2012-01-19 19:42:00 Author: Antikris Posts: 1340

---

I expected Homeless Guy to be out of a job... Hehe. That was the joke. I took you in one direction, then flip-turned you right on your head..... for I am the master of deception!!!!!!

2012-01-19 20:10:00 Author: Ali_Star Posts: 4085

---

I expected Homeless Guy to be out of a job... In today's economy!? You must be kidding! I didn't expect any of them to be working. On topic: Well, like said above. If you have the issue with the tag strengths triggering things when not at a full value (although most things come default as power based, so only binary logic rules apply....in most cases ), you need to check your logic and ensure it's all on/off power settings, not speed scale or whatever else there is. Question: Are you trying to get <100% signals? If so, it could be a matter of the signal not triggering something that relies on a full signal to activate. A positional sequencer conversion (battery covering entire length) to a 100% signal would ensure that any signal will produce a full activation state. (Note: I was testing some complex logic, and my positional sequencer conversion does NOT work with a value of 0.3%. To fix, I extended the length of the sequencer and battery. Could be an issue of the little 'bar' in the sequencer being the thing that triggers things, rather than the value itself, since the bar could not be seen, but with a signal probe I did get a reading of 0.3%..........)

2012-01-19 20:28:00 Author: SSTAGG1 Posts: 1136

---

Ok, I went back to the old method again (which I saved in a seperate place on my moon), I again found that just ONE of the tags was not working properly. So I'll ask you guys a question - if your something is not working on your PC, what is the most simple solution? That's right - you turn it off and on again. So what I did, was I captured the offending microchip, then deleted it. Then I took the captured microchip and placed it in the exact same position that it was originally in....... and it worked. So surely that means the fault must be with the game, and not my logic?

2012-01-20 11:45:00 Author: Ali_Star Posts: 4085

---

TBCH, that's bizarre. Nice to see you fixed it though. I've run into enough logic bugs (eg: certain MC's unglueing everything it's attached to, a full 100% signal through a wire without a starting point), but these happen only rarely (once...), and I've spent pretty much all my time playing LBP2 making random logic stuff. I don't think it should be a problem again.

2012-01-20 15:48:00 Author: SSTAGG1 Posts: 1136

---

they're just named U, D, L and R... for the directions. I tried naming the tags U, D, L and R and they all worked as expected. They were all identical save for the name. surely that means the fault must be with the game, and not my logic? No, not really. The only testable example you've given so far works fine. It's more likely to be either human error or another problem on your end until you can provide some evidence otherwise.

2012-01-20 16:03:00 Author: Ayneh Posts: 2454

---

I tried naming the tags U, D, L and R and they all worked as expected. They were all identical save for the name. No, not really. The only testable example you've given so far works fine. It's more likely to be either human error or another problem on your end until you can provide some evidence otherwise. The names of the tags is irrelevant, and obviously you couldn't have possibly set it up in the same way I did. I don't know how it can possibly be human error when I capture the microchip, delete the microchip I captured, then placed the captured microchip back again..... and it starts working. The microchip in question is placed on a block of hollow. So, I copied the (now working) microchip and it's holo base, and paste it. I change a couple of the tag names (again, irellevant) to what I needed them to be, I tested it, and lo and behold.... it didn't work. I did the same trick as before..... capturing it and whatnot......... and it worked. If that's human error, then I'm a giraffe!

2012-01-20 16:13:00 Author: Ali_Star Posts: 4085

---

The names of the tags is irrelevant, and obviously you couldn't have possibly set it up in the same way I did. You wrote previously that all the logic was otherwise identical except for the names of the tags. That's fair enough, but it still doesn't explain why it worked for 3/4 of the tags, when they were all set up in the same way. "Same way" in the sense that the only thing that's different, is the naming of the tags. How do you have things set up, then? Are you placing the tag right on the edge of the sensor radius? Are you using a narrow degree setting? I just assumed you were placing the tags well within the radius of the tag sensor. That's the first thing anyone would have checked. I don't know how it can possibly be human error when I capture the microchip, delete the microchip I captured, then placed the captured microchip back again..... and it starts working. Yeah, there's an issue with captured objects behaving differently. Sometimes when you capture pistons they won't work, for instance. Until the problem can be reproduced on another machine, i.e. you write the steps you need to go through to replicate the problem, there's no reason to assume it's anything other than human error or a problem on you end instead of a fault with the tag sensors themselves. So far it has been proved that there's a delay between tags and tag sensors, but this other problem where identical tag sensors don't work as they should hasn't. The first was easy to test and prove, the second where you noted the only difference between tags were their names (U, D, L and R) worked ok for me.

2012-01-20 17:25:00 Author: Ayneh Posts: 2454

---

You wrote previously that all the logic was otherwise identical except for the names of the tags. How do you have things set up, then? Are you placing the tag right on the edge of the sensor radius? Are you using a narrow degree setting? I just assumed you were placing the tags well within the radius of the tag sensor. That's the first thing anyone would have checked. Yeah, there's an issue with captured objects behaving differently. Sometimes when you capture pistons they won't work, for instance. Until the problem can be reproduced on another machine, i.e. you write the steps you need to go through to replicate the problem, there's no reason to assume it's anything other than human error or a problem on you end instead of a fault with the tag sensors themselves. So far it has been proved that there's a delay between tags and tag sensors, but this other problem where identical tag sensors don't work as they should hasn't. The first was easy to test and prove, the second where you noted the only difference between tags were their names (U, D, L and R) worked ok for me. 1) The delay between the tag and the sensors was fixed by capturing the object, deleting the original and placing it back again. This is a different problem to the "3/4" problem. 2) Tags are in the middle of the radius. 3) I just don't understand why you won't believe me when I say that 1 of the tags didn't work, when the other did. The fact that it worked ok for you does not matter because you won't have had the logic set up the same way I did. There are numerous tags involved, all activated in different ways, they often activate subsequent tags, and so on and so forth. Now, part of the process (pretty much the first or second step) involved 4 tags, named U, D, L and R. These recognise which direction has been pressed. All set up in IDENTICAL fashion, in that I just connected them directly to another tag. I basically just copied the first one I created, and pasted it 3 other times, changing the names of the other 3 tags. Right, the way I do my logic is that I do it in steps. I start of by trying to get the basic elements in place, which includes the process I'm mentioning. So I make sure that's all working fine before I proceed to the next step. However, at some later stage, one of those tags sensor-tag connections fails to work. I haven't changed the way in which it activates.... so why should it stop working?? The only explanation that I see for this, is that the more logic I place, the more chance of logic lag happening, which results in some of those connections not working as they should. 4) Like I've said before. I had the same problem on my last level. Here is the setup, how I did it originally (later moved onto a more efficient method): http://i42.tinypic.com/ivlbo5.jpg The dark green is the edge of the arena. The black boxes are microchips (placed all around the edge), placed next to each other on a large grid. Inside the microchip is a tag sensor, which is activate when the "head" of the snake reaches the edge of the arena. There are two tags activate by this sensor - tag A is consistent with all the chips, but tag B is related to its position (for example U12, R3, L6). When I was placing the emitters activated by the tag Bs, I went through the tedious process of testing each chip to see if it worked properly. It did. That was until I came back another day, did some work in an unrelated area of my level, only to come back to testing the arena part and finding that 1 or 2 of them had stopped working. When I viewed the offending logic to see exactly what was happening as I tried to passs from one side to the other, I saw that the wires lit up.... but the tag didn't. The solution (as prev mentioned) was to place counters between those connections.

2012-01-20 19:03:00 Author: Ali_Star Posts: 4085

---

My only issue with everything you've said is that you had the tag sensors using proximity values rather than strength. That leads me to think there are some other areas where a simple mishap has resulted in some failed logic. Don't get me wrong, it is strange that two sets of the same thing work differently in the same situation, but it could be you're just missing some event that to you seems irrelevant, but to the system, results in failures. If you're running into issues of having far too much logic in the level, you're going to have to rethink some of your designs. It gets worse when there's more than 2 players. I had systems that worked fine in single play, but completely and utterly failed the moment another player joined.

2012-01-20 21:34:00 Author: SSTAGG1 Posts: 1136

---

though doesn't the tag sensor have to be receiving 100% for it to be turned on digitally? the analog % will never influence the digital state. analog and digital exist seperately within the same wire/signal, you can have a 100% analog signal with digital OFF, or a 0% analog with a digital ON, the misconception is caused by the fact timers and counters produce a digital ON signal when the timer/count is full (analog 100%) so some think one is caused by the other. however this is just a function of timers and counters and is not related to the way signals work in general.

2012-01-21 10:09:00 Author: evret Posts: 612

---

The fact that it worked ok for you does not matter because you won't have had the logic set up the same way I did. There are numerous tags involved, all activated in different ways, they often activate subsequent tags, and so on and so forth. I start of by trying to get the basic elements in place, which includes the process I'm mentioning. So I make sure that's all working fine before I proceed to the next step. However, at some later stage, one of those tags sensor-tag connections fails to work. I haven't changed the way in which it activates.... so why should it stop working?? The only explanation that I see for this, is that the more logic I place, the more chance of logic lag happening, which results in some of those connections not working as they should. What makes you think then that's it's a fault with the tags themselves instead of what you listed? We already know stuff doesn't work or even display properly when you have high complexity present in a level. That's not a fault with the game itself but a result of you placing so many objects and logic components to begin with.

2012-01-21 19:53:00 Author: Ayneh Posts: 2454

---

Just to say, I had some troubles like that once, and I realized my tags were triggering chips. Somehow, having a 1-frame signal running through a tag then activating a sensor which goes to a chip won't activate the chip. Does the chip need to be on for more than a second ? No idea. I just placed tons of and gates instead of triggering batteries on chips, and it worked.

2012-01-21 21:21:00 Author: Unknown User

---

Just to say, I had some troubles like that once, and I realized my tags were triggering chips. Somehow, having a 1-frame signal running through a tag then activating a sensor which goes to a chip won't activate the chip. Does the chip need to be on for more than a second ? No idea. I just placed tons of and gates instead of triggering batteries on chips, and it worked. Activating a microchip introduces a single frame of delay. Thus, a one shot timer pulser will have deactivated before the signal to the logic in the MC is sent.

2012-01-22 00:18:00 Author: SSTAGG1 Posts: 1136

---

You mean a one shot counter, don't you ? Cause a 0.1 sec timer would work, since it's 3 frames ^^

2012-01-22 03:39:00 Author: Unknown User

---

Yeah, I suppose I did. I really meant to say a pulser, which can be done with anything really. A count-down timer with self reset is the same.

2012-01-22 03:46:00 Author: SSTAGG1 Posts: 1136

---

Part of this process involves sending signals through several tags and tag sensors. In most of the cases, it works fine, but in one instance, there seems to be a delay at some step along the process, which causes a major problem. Has anyone else had this problem, and has been able to come up with a solution? You might get latency when sending a signal via multiple tag/sensor pairs, and although there's a way to avoid it (https://lbpcentral.lbp-hub.com/index.php?t=49984-Comparing-4-analog-signals-to-find-the-strongest&p=786106&viewfull=1#post786106), it doesn't play well with emitted logic. ...it still doesn't explain why it worked for 3/4 of the tags, when they were all set up in the same way. To clarify, the latency is not between the tag and the sensor, but between the sensor and the next tag in the chain, so the overall latency of 'n' chained tag/sensor pairs is n-1 frames.

2012-01-25 20:06:00 Author: Aya042 Posts: 2870

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.