Archive: 31 posts

---

I've finally identified the screwy mechanics of my versus shooter scoring, and it reveals an underlying mechanic that requires proper investigation. Basically, how you trigger a spawner can affect who a points giver identifies as "you" when awarding points. I'm creating a tanks game, four remote controlled tanks that shoot each other. Shots fired correctly gave points to whoever fired them, but an energy beam gave points to whoever was hit, or the second player - only have two controllers for testing. After a lot of messing around to see if holo collisions were different to physical collisions or if emmitters could get bugged identities, I finally realised that my spawning mechanic for shots and beam are different. So, my point giver is currently on the shot and the beam. When the shot impacts a target, it awards points to "you only". "You" is identified as the player who spawned the shot. The shot emmitter is connected to some selector logic ANDed with the fire button (L1) leading to a 1 shot emmitter. My beam weapon, connected to the same firing mechanism and selected via a pickup, has the same point giver logic (copied over the same chip exactly), but the points are awarded wrongly. With my beam creation, I have five different beam objects each on an emmitter, and I use a randomiser to select between them. With these, I hold down the fire button to activate the randomiser, and in doing so the emitted objects LOSE THEIR PLAYER IDENTITY. Or rather, they don't inherit it. This leads me to the following theory : Emmitters connected directly to player activation inherit the player's identity for the point giver Emmitters activated by timing type logic like randomisers have no inherent identity, and the identity given to a point giver is via some mechanic I don't yet know. There may be an indentity signal path in effect just as there is with analogue and digital signals. Perhaps ANDs, ORs, and various components pass through (or not) any identity signal from a DCS receiver? This would be a consistent design approach. It's early days yet, but I know others have been hitting issues with giving points remotely, and this identity inheritance is something that needs to be factored in so I felt it best to get the word out ASAP.

2011-01-31 14:27:00 Author: Shifty Geezer Posts: 131

---

'Timing type logic' - not sure what you mean there but timers definitely inherit the player data, through the main input - no longer thru the reset input, which used to work in the beta. Pretty much everything can pass through player data, it's just tricky working out exactly how if there is any ambiguity. The simplest way to avoid ambiguity is to pwire whatever the ambiguous signal is into a microchip enable and then wire an unambiguous signal through the microchip. It's pretty cackhanded, but it's robust and easy to get right. I was gonna write some stuff up on player data when I get the chance. Seems many people are really struggling with it atm...

2011-01-31 14:37:00 Author: rtm223 Posts: 6497

---

I can't say exactly what I mean by 'timing type' logic either because I haven't investigated which components pass through player data and which don't. I've just rigged a working system and it definitely points to the idea that an object takes its player identity from a DCS connection, but not all circuitry echoes this data on. For my beam weapon, having the logic : (L1) AND (Selector) > (Randomiser) > (five emmitters) ...the player identity is not passed on. My new configuration : (Selector) > (Randomiser) > (five (L1) AND (Emmitters)) ...so that each emmitter receives a player value from the direct L1 value ANDed to the randomiser signal, works. From this it was a straightforward fix to get my 500 points awarded to the round victor. On each tank is a tag sensor for End of Round, which is a level tag activated when there's only one tank left. The points were originally awarded to the wrong player with the logic (Tag Sensor) > (Point Giver) ...but as expected, ANDing the Tag Sensor with DCS power (Tag Sensor) AND (DCS Power) > (Point Giver) ...awards the points correctly. So for giving points, creators have to be aware of feeding the correct identity signal to a points giver. I don't know if there are any descriptions of all the different signal types and stuff, but this is the first I've found out about it, and certainly no-one mentioned it in my or other's point problem threads!

2011-01-31 15:08:00 Author: Shifty Geezer Posts: 131

---

This seems like a semi-relevant place to ask this, as opposed to making a new thread - Is there a way of nullifying the score givers output? Y'see, I have a similar thing going on to what Shifty Geezer spoke of, except mine has AI enemies aswell as human enemies. I have the game giving the correct player the points when they make a kill, however whenever one of the AI vehicles makes a kill, the score giver seems to give the points to the closest player, instead. As you may figure, I really don't want AI kills, awarding human players with the points, but I haven't a clue how to stop this from occuring. Oh, and thanks for the explaination about randomised laser-ish weapons having difficulty with scoring. Isn't something I've had trouble with yet, but I would have shortly, if not for this thread.

2011-01-31 23:50:00 Author: Ostler5000 Posts: 1017

---

I think you'd have to add another conditional check on your point giver and differentiate between shots from players and shots from AI bots. The behaviour of the Score Giver indicates it'll always award points, and a NULL identity will just pick the closest or last player or whatever its mechanic is. Most straightforward solution is to have different shots for the AI bots tagged differently. TAG(Player_Shot) AND (Impact Sensor) >> (Score Giver), with player shots tagged Player_Shot and bot shots untagged. Or tagged Bot_Shot for later use.

2011-02-01 10:08:00 Author: Shifty Geezer Posts: 131

---

Looks like I may need to add a "detected player color" section to my logic probe (http://lbp.me/v/wqzn-q), to help people with debugging this sort of thing.

2011-02-01 10:18:00 Author: Balorn Posts: 92

---

Does player identity get carried across AND/OR gates? In that case: positional Sequencer stuck on a nested MC batteries on its canvas your Randomizer plugged into Sequencer input your Controlinator's action button activates the MC the Sequencer sits on each battery on the Sequencer hooked to a separate AND gate on the main board, combined with your DCS' action input each unique AND gate hooked to a unique beam If the AND gate preserves player ownership, it should directly go from the DCS into the beam emitters; the randomizing process is now wired parallel to this setup instead of in sequence. Does this work? Forget it. My idea is way more complex than it should be. (Reminding myself to think my rambling through before hitting Post button) Randomizer to Selector (cycle input) each Selector output wired to its own AND gate player action to the other port of each AND gate unique beam emitter behind each AND gate

2011-02-01 10:31:00 Author: Antikris Posts: 1340

---

I think you'd have to add another conditional check on your point giver and differentiate between shots from players and shots from AI bots. The behaviour of the Score Giver indicates it'll always award points, and a NULL identity will just pick the closest or last player or whatever its mechanic is. Most straightforward solution is to have different shots for the AI bots tagged differently. TAG(Player_Shot) AND (Impact Sensor) >> (Score Giver), with player shots tagged Player_Shot and bot shots untagged. Or tagged Bot_Shot for later use. Oh, man. This seems so obvious I dunno why it never occured to me before. Thanks very much for this - it worked.

2011-02-01 11:46:00 Author: Ostler5000 Posts: 1017

---

Yes, AND gates pass through IDs, which is how I'm currently working with them. The Power connector of the DCS controller is the ideal ID signal. I've encountered what looks to be an unworkable issue though, in that ID inheritance from emitters only goes to the first generation of nested spawners. I have a special type of powerup bullet that splits into three shots on impact. The original shot emitted from the player's tank has the player's id, but the shots it emits have no id. Unless there is a way to force passing of an id to an emitter, it looks like that information is lost and emitter ID is only automatically assumed from a DCS as part of the emitting object's circuitry.

2011-02-01 15:21:00 Author: Shifty Geezer Posts: 131

---

Looks like I may need to add a "detected player color" section to my logic probe (http://lbp.me/v/wqzn-q), to help people with debugging this sort of thing.Good idea. Should be easy enough with a light set to player colour or something.

2011-02-01 15:22:00 Author: Shifty Geezer Posts: 131

---

I've encountered what looks to be an unworkable issue though, in that ID inheritance from emitters only goes to the first generation of nested spawners. I have a special type of powerup bullet that splits into three shots on impact. The original shot emitted from the player's tank has the player's id, but the shots it emits have no id. Unless there is a way to force passing of an id to an emitter, it looks like that information is lost and emitter ID is only automatically assumed from a DCS as part of the emitting object's circuitry. Creators like you are at the frontiers of LBP2 innovation. The challenges you people face benefit the community a lot! That said, how about emitting three bullets at once, on top of each other, that simply change direction at one point and only make it appear to split? Before that split, of course a hit will count as three hits... Or you could have three invisible pieces of halo track the main bullet and then follow the split ones individually. Bullet and halo communicating through tags. Way more complicated than should be, but let's hope MM patches things.

2011-02-01 15:49:00 Author: Antikris Posts: 1340

---

Looks like I may need to add a "detected player color" section to my logic probe (http://lbp.me/v/wqzn-q), to help people with debugging this sort of thing. That would be cool.

2011-02-01 15:53:00 Author: Sehven Posts: 2188

---

Creators like you are at the frontiers of LBP2 innovation. The challenges you people face benefit the community a lot! I dunno. Gets stressful! Nothing like as many bugs as LBP1 had though, so at least progress is fairly constant. the worst part is, you go to all this work and then only ever get a handful of plays! That said, how about emitting three bullets at once, on top of each other, that simply change direction at one point and only make it appear to split? Before that split, of course a hit will count as three hits... Or you could have three invisible pieces of halo track the main bullet and then follow the split ones individually. Bullet and halo communicating through tags. Way more complicated than should be, but let's hope MM patches things.There's not really a workaround at the emitter stage if I was to keep the same exact mechanic. The shots are solid projectiles so they bounce, so can't overlap. I've dropped the triple shot and replaced it with mines, but that throws up the same sort of scoring problems. A Score Giver on a mine set off by collision with a labelled tag doesn't have an identity. That is, a mine with three collision tags for the other three player through an OR gate to a Score Giver, the Score Giver doesn't give the points to the player who emitted the mine. Not sure if a Tag Sensor overrides an ID. The labelled Impact Sensor on the shots works fine, but I can't use straightforward impact detection as that messes up the point mechanic. I think mines need a little more work!

2011-02-01 18:33:00 Author: Shifty Geezer Posts: 131

---

OK, done. My Logic Probe level (http://lbp.me/v/wqzn-q) now gives out a version with a player color indicator, as well as a slightly larger input port. (The signal combiner doesn't pass the player color through yet; it already uses some odd tricks to do what it does so I'm not sure if that's going to be fixable.)

2011-02-01 19:58:00 Author: Balorn Posts: 92

---

I've encountered what looks to be an unworkable issue though, in that ID inheritance from emitters only goes to the first generation of nested spawners. I have a special type of powerup bullet that splits into three shots on impact. The original shot emitted from the player's tank has the player's id, but the shots it emits have no id. Unless there is a way to force passing of an id to an emitter, it looks like that information is lost and emitter ID is only automatically assumed from a DCS as part of the emitting object's circuitry. Have you tried putting a DCS Reciever on the bullets and wire the active state into your logic? That seemed to work for me on a similar issue as long as you are using a DCS transmitter.

2011-02-01 22:53:00 Author: Osprey71 Posts: 93

---

The nested emitters thing is pretty much a trivial problem. The emitter passes on the player data of the signal inputting to the emitter, but it only passes player data onto the materials, for example if using coloured hologram or non tag-based impact sensors. As far as I can tell it does not implicitly pass on player data to any of the logic (though it might to some components, for the most part it seems not to). Therefore if you wish to get player data into an emitted object you will need to explicitly pass that data in through your logic design. Only way to pass logic into an emitter is wirelessly. So to get player data passed onto the second level of emitters then all you need to do is pass the data on to the emitter by using a wireless method-imput the dcs power output to a player tag, which will then be picked up by a tag sensor on the emitted object and route that value into the second emitter. With the and gates, remember to be careful that only one of the inputs to it can actually have any player data. The system has to be unambiguous, or you are going to hit sporadic problems Wrt debug... Why would you use a probe when you can just set the logic devices to display player colour on the wire.... It gives far more information. Also, I dunno what you are using to display data, but please remember that hologram shows the last player data that was input to it. Meaning it often shows a player colour, when there is actually no player data being passed into it. appologies for the messy post, am on my phone and away from my ps3. But don't worry, player data's not that hard to deal with... Just takes a little getting used to :-)

2011-02-02 18:11:00 Author: rtm223 Posts: 6497

---

...Therefore if you wish to get player data into an emitted object you will need to explicitly pass that data in through your logic design. Only way to pass logic into an emitter is wirelessly. So to get player data passed onto the second level of emitters then all you need to do is pass the data on to the emitter by using a wireless method-imput the dcs power output to a player tag, which will then be picked up by a tag sensor on the emitted object and route that value into the second emitter.Of course. Thanks. Wrt debug... Why would you use a probe when you can just set the logic devices to display player colour on the wire.... Ha! Would ya look at that! Didn't even know we had that option.

2011-02-02 22:01:00 Author: Shifty Geezer Posts: 131

---

Also, I dunno what you are using to display data, but please remember that hologram shows the last player data that was input to it. Meaning it often shows a player colour, when there is actually no player data being passed into it. Yeah, I noticed that while testing. I have some ideas but I don't know if I'll have time to do much about that until after the weekend.

2011-02-03 02:14:00 Author: Balorn Posts: 92

---

In Real CTF i was able to control score giving via wireless logic (tag sensor trigger) and place it on player sackbot and made tag sensor different each player, i think same effect can be done by placing this score giver with wireless in controllinator Also i think the trigger it self should be neutral, but im not sure. In my level point was triggered by the flag that been following tag on sackbot going near the base, it worked fine

2011-02-03 03:51:00 Author: Shadowriver Posts: 3991

---

Only way to pass logic into an emitter is wirelessly. So to get player data passed onto the second level of emitters then all you need to do is pass the data on to the emitter by using a wireless method-imput the dcs power output to a player tag, which will then be picked up by a tag sensor on the emitted object and route that value into the second emitter.I've tried all sorts of methods and nothing is worling. I don't know if it's a fault of my logic or a bug. For a mine - holo object dropped by player. It tracks nearby players and damages them on impact, activating a Score Giver set to "You Only". The points are always awarded to layer 1 in testing. I started with, exactly as you suggested, a labelled tag on each player, Score_R, _G, _B, _Y, activated by the DCS receiver. I AND this with the activation signal when firing the Score Giver, supplying, in theory, the correct player identity. This didn't work, but I saw that the activation signal (coluor to player colour) was set to player 1 for some reason, no matter who spawned the object or who impacts with it. I stripped out that ID signal with a selector, so the Score Giver was only receiving the ID from the tag sensor, which I confirmed is the playre colour, but it still gave points wrongly. I changed the DCS transmitters and receivers from fixed colours to player colour, but that didn't work. I tried a DCS receiver instead of the tag sensor on the mine, getting the receiver power directly, and that didn't work. It is proving very hard to suplpy a Score Giver with the indetity of who you want to get the points!

2011-02-04 10:49:00 Author: Shifty Geezer Posts: 131

---

Yesterday together with Tanrock we discover that you can wipeout player information from signal via battery activation via microchip, after that same as my previus method sackbot/controllinator ownership takes over and gives points to owner of sackbot or controllinator. Of corse same as hologram last set ownership stays, so if you leave sackbot he still be owned by you and give you point, or else other player will come and overwrited.

2011-02-04 15:20:00 Author: Shadowriver Posts: 3991

---

Yesterday together with Tanrock we discover that you can wipeout player information from signal via battery activation via microchip, Yeah, this is pretty obvious, you break the chain through which the player data is transmitted. It's basically the same thing I was posting on the previous page, wrt using microchip as a relay to remove ambiguity. The point is that the player data cannot be transmitted through the enable of a microchip, so the signal wired through retains it's data. Obviously if you enable a battery in this way then the battery's player data is what will be output (battery has no player data). I stripped out that ID signal with a selector This doesn't work. The select switch does a very good job of passing on player data in a permanent fashion. It's quite cool as you can re-activate the same input with a new player and it will overwrite the previous player data. Not sure why you thought it would remove player data TBH. Further testing with AND and OR gates demonstrates they are actually quite nasty - I'd definitely avoid using them unless you properly understand 100% exactly how they work with player data, especially ambiguous player data, which is likely to be the case if you are trying to use select switches to strip player data. Edit: They might not be that nasty actually.. It seems that in the case of ambiguity, AND gates pass through the player data of the signal into input 1 (or probably the lowest index input that actually has player data - hypothesis, untested). Also, it seems that AND gates don't need both inputs active to pass on player data. Also, as far as I can tell, the player data passing is completely independent from both the analogue and digital aspects of the signal being passed. Also, watching colours on the wires won't always tell you the full story - try wiring up two NOT gates in series and you'll see that part of the circuit will be off so will display no player data whatsoever, but then after the second NOT the data is recovered - so player data exists even in signals that are off. To accurately see, for sure, if there is player data on the wire I suggest: out = in OR NOT(in) o = i + !i (using the annotation I had for my blog ages ago, if anyone prefers that. This is neatly demonstrated in the case of a player sensor, where the digital signal does not activate until the player has passed through the hysteresis zone. However, whilst in the hysteresis zone the player data does get through and can be seen in the negative part of the circuit. You would typically (and quite reasonably) assume that until the player sensor has been activated, no player data exists, but this is incorrect, and such an assumption will add ambiguity to your system. So basically, as I recommended in my first post of this thread, unless you are 100% confident you understand the system fully (which I don't think any of us do TBH), create your logic with no thought for player data, then use your points trigger to activate a microchip relay allowing an unambiguous signal to pass through. Your scoring logic cannot fail if you fall back to that safety-net.

2011-02-04 18:18:00 Author: rtm223 Posts: 6497

---

[a bunch of incomprehensible stuff] Wow, you're really not very good at making stuff easy to understand, are you? I think I get the gist of it, but you lost me a few times in there.

2011-02-04 22:42:00 Author: Sehven Posts: 2188

---

This doesn't work. The select switch does a very good job of passing on player data in a permanent fashion. It's quite cool as you can re-activate the same input with a new player and it will overwrite the previous player data. Not sure why you thought it would remove player data TBH.Well as I said in this thread, the behaviour of passing the signal from a selector didn't apss on the identity to spawned object. ANDing with the DCS power switch sovled that, hence my belief that there was no signal from the selector. Now I know to set the selector to player colour, I can see it does maintain player value, in which case I plain don't understand why it doesn't work directly and I am having to AND it with the DCS signal. To accurately see, for sure, if there is player data on the wire I suggest: out = in OR NOT(in) o = i + !i (using the annotation I had for my blog ages ago, if anyone prefers that. That makes sense, thanks. Although it's not an issue with my current wiring. So basically, as I recommended in my first post of this thread, unless you are 100% confident you understand the system fully (which I don't think any of us do TBH), create your logic with no thought for player data, then use your points trigger to activate a microchip relay allowing an unambiguous signal to pass through. Your scoring logic cannot fail if you fall back to that safety-net.Yes, I see that now, although as you said originally it's rather cack handed. I'd rather know what's really going on and be able to wire the components as you'd expect to, but if it's way too complicated, then it's simpler just to use a simple chipped solution.

2011-02-04 23:00:00 Author: Shifty Geezer Posts: 131

---

@Sehven: In fairness, that was mostly me switching back and forth between testing things and musing upon them on here. Plus I spent about 15 minutes on finding that stuff out, so it's hardly a proper breakdown! Yes, I see that now, although as you said originally it's rather cack handed. I'd rather know what's really going on and be able to wire the components as you'd expect to, but if it's way too complicated, then it's simpler just to use a simple chipped solution. Yeah, it'd be great to fully understand how every component transfers player data, but that's gonna take a while to determine. Overall it's better to fall back on something simple but slightly clumsy that we can know, beyond any doubt, will work by design, than try to determine every case for a more complex system that we don't fully understand. Remember we're only a couple of months into using this system - in LBP1 we were still trying to understand it after 2 years, so we can't expect to know everything right at the very beginning. We can strive to understand more, but in the mean time, stick to what you know will definitely work for what you are doing now and try to find better ways of doing the same for future projects

2011-02-04 23:54:00 Author: rtm223 Posts: 6497

---

I really still would like to see some more player specific tweaks, strange and complex nature of signal ownership makes hard for newbies to control who get the points and other things But little off topic, specially in followers since without such tweaks is impossible to make stable following HUD without sackbot or isolating players.

2011-02-05 04:57:00 Author: Shadowriver Posts: 3991

---

Okay, here's the working summary solution for any new visitors who haven't followed the discussion. It's an easy solution to take control of who gets what points in a versus match. For every DCS controlled player (sackbot or vehicle), add a tag on their DCS circuit board. Label this tag "Score_1" or 2 or 3 for each player. Connect the DCS power output into this tag. Create a microchip. Add a Score Giver. Add a Tag Sensor the same colour as your player tags, labelled "Score_1". Set its radius HUGE so it can always see the player. Connect this Tag Sensor into the Score Giver. Copy this to your objects for frequent future use! For every object you want to score points - Add this microchip where you would a Score Giver, and connect your score mechanic (impact sensor or switch or whatever) to the power on for this microchip. Set the tag sensor in the microchip for whatever player you want to give points to. The tag sensor passes on to the score giver the ID of who you want to pass the points to. This gives you exact control in specifying players for every score giver. Many thanks rtm223 for this idea and your work in discovering the inner workings of LBP2!

2011-02-05 10:36:00 Author: Shifty Geezer Posts: 131

---

Okay, here's the working summary solution for any new visitors who haven't followed the discussion... In most cases, this is overkill. Enable the Transmitter option on the Controlinator the player actually sits in (if you're not already using it), create a corresponding Receiver somewhere else in the level, and AND the power signal from the Receiver with whatever triggers the score, and feed that into a Scoregiver. The additional Tag/Sensor is typically unnecessary.

2011-02-05 21:53:00 Author: Aya042 Posts: 2870

---

Hey everybody. Just wanted to say thanks for all the info. I've been working on a shuffleboard game (my first LBP2 level!) and the scoring at the end of a round was always going to player 2. After reading through this thread, I tried a few of the suggestions and got my level working and published! One odd quirk I found with the order though. I have three inputs that trigger the score: Selector (choosing how many points to award) Tag sensor triggered by the end of a round Tag sensor triggered by a Player Sensor/Tag (added after reading this thread) If I just did a 3-way-AND between all of these, it didn't work If I did a 2-way-AND between the Selector and the end-of-round sensor, then fed that into another 2-way-AND with the player tag sensor, it still didn't work BUT when I swapped the order and did the Selector/player-tag-sensor AND first and the end-of-round sensor AND second, it worked! I also tried using the power output from the controlinator without success, but that was before finding the above solution. I'll try using that instead of the player-sensor-tag solution tonight. I'll see if maybe the order of inputs changes things in a 3-way-AND, as well. Thanks again! btw, my level is called Hazzmax Shuffleboard. Any notes would be much appreciated! (and hearts!)

2011-02-16 18:25:00 Author: hazzmax Posts: 12

---

One odd quirk I found with the order though. You might be interested in reading this thread (https://lbpcentral.lbp-hub.com/index.php?t=48588-Observations-about-player-data-and-logic-gates).

2011-02-16 18:55:00 Author: Aya042 Posts: 2870

---

You might be interested in reading this thread (https://lbpcentral.lbp-hub.com/index.php?t=48588-Observations-about-player-data-and-logic-gates). That did the trick! I made sure the controller power output was the first input and I was able to consolidate back down to a 3-way &. Made my chip look alot nicer and works like a charm! Thanks again guys!

2011-02-20 22:02:00 Author: hazzmax Posts: 12

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.