Home    LittleBigPlanet 2 - 3 - Vita - Karting    LittleBigPlanet 2    [LBP2] Help!
#1

I need help making, well, let me explain.

Archive: 15 posts


I'm playing around with some logic. I'm pretty new to logic in every respect and i'm trying to make a little contraption for a level i've very recently began making.

The contraption is a panel 3 small grid thick, 1 layer thick, hollowed out with a middle layer 1 small grid thick that slides down vertically after the panel its nestled in slides out from the wall horizontally. The idea is to have a hit sensor on the very middle panel that once hit enough triggers an emmiter making some stairs appear that goes up to a lever that... e.t.c.
I have a surrounding housing in a sort 3 walled box fashion that the panel sits in and is held in place with a piston.

This piston extends pushing the panel out from the wall horizontaly and in turn the smaller panel slides down vertically via a second piston holding it to the inner underside (middle) of the first panel.

The way i have it set up so far is i have a 2 way switch and a sensor switch hooked up to an and gate the sensor is set to reverse so only turns on when the first piston is fully extended (after the panel is fully pushed out).

I can't remember exactly how, but i know i have the 2 way switch as a placeholder for whatever i'm going to use in the final piece, the 2 way switch is simply a way of triggering the initial beggining of the circuit.

The output of the and switch is linked to a timer switch that cuts the spistons circuit for 'x' seconds, the sensor on the 1st piston is also linked up to trigger the second piston, which extends when the 1st circuit breaks, this is to make sure the second piston only extends when the 1st piston is fully extended.

Now i hit my problem. I'm trying to get the inital circuit (for the 1st piston) to break, after triggering the 2nd piston, until the 2nd piston has fully extended, stopped for a manually definable amount of time, and the 2nd piston has detracted back to its original position.

I've been playing around with trying to get a triggered circuit with a new timer to interupt to timer switch on the first circuit, then re-initiated the timer on the first circuit from the possition it was frozen.... not possible, you can't stop a timer switch once its been triggered.

I've also tried messing with using a second sensor switch (tag senor i think they're called in lbp 2) that triggers when the 2nd piston fully extends. Using the input from the sensor as part of the input of an and gate with a timer switch as the other input for the and switch to act as a time buffer, and have the output of that and switch as 1 input along with the original input for the timer switch on the first circuit.

that doesn't work either.

My big problem is that i can't get the second piston to stop dead until i want it to trigger again, i've sort of done it with the first piston but its just a timer switch, what i 'really' need is some form of trigger event thats triggered when the 2nd piston fully extends that stops the 1st pistons circuit (instead of using a timer switch, as while using a timer switch i 'have' to keep the 2nd piston in-out motion within the time frame of the 1st pistons timer switch, and keep the pistons in sink, which is a DAM pain in the behind i tell you!) freezing the 1st piston, then have another form of circuit break that stops the second pistons movement for a time manually definable, then say after 15/20 seconds, have the 2nd circuit re-trigger which detracts the 2nd piston, which in turn reconnects the 1st circuit which detracts the 1st piston....

How to actually 'do' all that though is proving wayyy to complicated for my tiny brain to comprehend....

I'm kinda stumped and have spent hours trying to figure out how to get the 2 pistons working in sink in amongst the logic. Most of what i've been doing is trial and error. I would REALLY appreciate some help with the ol logic stuff. I'm trying desperately to get into logic in a big way but this always happens to me, it seems my mind simply isn't capable of thinking in such a robotic fashion hah.

help me?! fanx please! (really though, thanks if you do help me out.)

I'de be happy to swap PSN details and get some in gakme help with what it is i'm trying to do. cheers!
2011-01-25 06:39:00

Author:
Epicurean Dreamer
Posts: 224


Can you post some pictures please? I can't tell what it is from your description.2011-01-25 06:56:00

Author:
Yofig
Posts: 288


I've made some advancements since last posting. I've managed to get the 1st and second circuits to cut when the 2nd piston hits its full extent, which in turn triggers a count down gate I can set to any time that freezes the whole system until it finishes. the countdown gate completing begins the detraction of the 2nd piston which once reaching the top cuts the circuit for the 2nd piston and triggers the circuit for the 1st piston which then detracts.

I still have some issues though, which i will speak about in a minute. First though as requested, a few pictures.

In these images, Ignore the button, its simply an input to an OR gate that triggers the 1st piston, its not important for the logic to work properly (i think...) I'm simply playing around with getting the logic circuit to trigger just once with a manual input, go through 1 whole revolution of states and then cut to an idle state. I've not managed to get this to work yet. Anyway...

http://ib.lbp.me/img/ft/afb56aa7ecf6f165038483d1dab895cb7a208b9a.jpg
Logic state 1. Both pistons detracted. (in this state though once triggered with the 2 way switch (which triggers the initial 'on' state of the entire circuit) the whole process of states runs indefinitely. I need help on stopping this.)

http://i7.lbp.me/img/ft/c979efacce6b8b91f84101e71ac308678f0dfe3c.jpg
Logic State 2. 1st piston extended, 2nd piston circuit triggered.

after this point as the 2nd piston begins to extend, the circuit for the 1st piston is cut stopping the detraction of the 1st piston.

http://if.lbp.me/img/ft/70f7605d9e902437afb9c20dee3548fbe6c59fb1.jpg
Logic State 3. 2nd piston extended. Both 1st and second piston circuits are now cut. Timer is triggered which counts down (manually definable) 'x' seconds.

http://id.lbp.me/img/ft/c5d422208ae4dd9c0ea9c09c3ab53861275f544e.jpg
Logic state 4. count down gate completes triggering the circuit for piston 2. Making piston 2 detract.

http://i1.lbp.me/img/ft/551c07a1c9074cbdd093c4341d3175e9eff85249.jpg
Logic state 5 (same as state 2). 2nd piston finishes detracting triggering 1st pistons circuit.

http://i7.lbp.me/img/ft/e1750a557f3248130ba4d527f0ca813e9ad02f38.jpg
Logic state 6 (same as state 1). Between this state and state 5 2nd pistons circuit is cut stopping it trying to extend again into the bottom of the panel housing.
This is the final and initial state of the logic states.

The whole process will run indefinitely through these steps after the initial circuit is fired up with the 2 way switch. I do not want it to do this. I want to use a sensor trigger with an emmiter that emits objects with the correct tag to be placed in the sensor zone that triggers a single revolution of states 1 through 6 and then becomes idle until the sensor switch (to be put in place of the button) is triggered with a tag again.

A second issue i have is the 2nd piston gradually becomes out of sink with the 1st piston and will eventually get caught against the bottom wall of the housing as the 1st piston tries to detract while the 2nd piston is still extended. In other cases the 2nd piston will try to begin extending 'just' as the 1st piston detracts and hit the bottom of the internal housing slightly before its circuit is cut, so the next time the 2nd piston is fired it 'thinks' it needs to travel up instead of down which throws the entire synk out of, well, synk.

Keep in mind this is my very first attempt at logic in LBP 2 and i only very vaguely looked into logic in LBP 1. So i understand there may very well be a much easier way of doing what it is i'm trying to do. I'm no logic buff in any respect.

I here-by humbly request help from all you logic geniuses out there. Advice on here or help in game would be awesome.

To give you an idea of what it actually is i'm making:

http://ic.lbp.me/img/ft/88ce4afec30f5f6b750c81fca3059a3ebadfb9b7.jpg
Side view. Completely closed up, imagine this is part of a wall, middle plane.

http://i5.lbp.me/img/ft/575650018debe2eb1e4501e6d25fe8631f0fc4aa.jpg
Side View. Completely Open. Note the impact sensor (may need to be a different sensor... anyway). This will once hit enough trigger an emitter that emits some steps that lead up to a switch opening a slide panel with a button inside that triggers the pulling down of a wall panel and drops a swing grabby thingy what have you allowing you to leave the room and get to the next bit. Thats the plan anyway....

Bit difficult to put together. thanks in advance for any advice RTM?? wink hehe
2011-01-26 01:34:00

Author:
Epicurean Dreamer
Posts: 224


Or you could always just have the hit sensor connected to a counter and when filled t will activate the emitter...
That's what yer trying to do, right?
Have the emitter emit the stairs after the sensor recieves a certain amount of hits?
At least that seems like a faster lss complext way to do it from what I undeerstood.
2011-01-26 03:19:00

Author:
Silverleon
Posts: 6707


the problem isn't getting the sensor to work. The problem is with the hydraulics system that's in place to get the sensor out of the hidden compartment for 'x' amount of time and then back in again.

I'm allot further than i was when i wrote the initial post. But i am still stuck at certain points and still a long way from having it exactly how i want it to be. Saying that. I have simplified the logic quite substantially and got rid of parts of the system that after many hours of staring at the current flow have been discovered to be completely redundant or i have discovered a better way of doing the same thing.

I'll upload some pictures of the new logic.

http://ie.lbp.me/img/ft/e0ed1ab5f48bd7f25e3497fd401501384a1a8855.jpg
State 1. Power coming from the two way switch above top right of the image. Entering AND gate, second input on AND gate is from a NOT gate linked to the BLUE sensor switch that triggers when the 2nd piston extends (set to reverse so it triggers when the tag leaves its radius). The AND gate is linked up to piston 1. This is the "Main Power Input" As this is the circuit aspect that receives manual input from an external source. That source is of course changeable to be anything that provides a current flow to the 1st input on the first AND gate.

NB: i feel this part of the logic network (the flow from an external source going into the first input on the main AND gate for piston 1) is where i will have to place further logic to interrupt the signal flow to the 1st piston, creating some form of 'trigger once and then idle' mechanism for the whole contraption. This is one of the main things i want to implement into the device, therefor one of the main things I need help with. I explain this in more detail near the end of this post.

The idea here is when piston 2 begins to extend it triggers the blue sensor, triggering the NOT gate and cutting flow from the circuit powering piston 1. Keep this in mind.

The piston extends.

http://i4.lbp.me/img/ft/dd4a296795368f14b6c70bc4d2311747d231e2a4.jpg
State 2. As piston 1 reaches its full extent the GREEN sensor switch is triggered sending Power to an XOR gate (this XOR gate will show its use later). The output runs from the XOR gate into an OR gate which triggers the 2nd piston into its extend motion.

Piston 2 begins extending.

http://ia.lbp.me/img/ft/55a5af92f694c0f144a7713c2822dcc061a4a57a.jpg
State 3. As the 2nd piston begins extending. The BLUE sensor triggers. Sending power into the NOT gate input, setting the AND gate powering the 1st piston into a negative state, cutting power from piston 1. This is important. As there is a gap between when the 2nd piston is triggered to move and the BLUE sensor triggering, cutting power from the 1st piston's circuit. This gap of a few milliseconds gradually throws off the synchronization between the 1st and 2nd piston time settings. even when they are set to be exactly in sink. I have tried playing with offsetting the timing settings on both pistons. This only makes it worse.

The second piston reaches its full extent.

http://i9.lbp.me/img/ft/0d930d076d41d64f248a9ff9e4113bf6732146ea.jpg
State 4. As the 2nd piston reaches its full extent the RED sensor is triggered. This does a number of things. Firstly it triggers the 2nd input on the XOR gate, setting the XOR gate's output into a negative state, cutting power from the 2nd piston. Secondly, The red sensor current is sent into a Countdown Timer Gate's RESET input (so every time the red sensor triggers, it in turn triggers the Countdown Timer Gate). Lastly, the RED sensor connects into an AND gate input, along with the output of the Count Down Timer Gate. The output of the AND gate is connected to the OR gate powering the 2nd piston.
So, The RED sensor Triggers the 2nd input on the XOR gate, cutting power to the 2nd piston, It also sends 1 of two inputs to an AND gate and triggers the countdown gate.

The countdown ends.

http://ic.lbp.me/img/ft/efc3a8c65d97a2ed77ae9560056c8d9b1f605afc.jpg
State 5. The Countdown Timer Gate triggers the 2nd input on the AND gate Sending a signal through the OR gate and back into the 2nd piston telling it to resume its up/down motion.

Notice, if you look closely the panel connected to the 2nd piston is slightly lower than in the picture of state 4. This is because the red sensor triggers the power cut to the 2nd piston's circuit slightly before it reaches its full extent. This detail may seem small but it too further adds to the gradual de-synchronization of the two pistons. I have played around with the sensor range and angle to quite an extent but i simply cannot get it to within enough of an exact measurement that the sensor triggers AS the piston reaches its full extent. No matter how close i get it, when the 2nd piston is triggered for the 2nd time it will always pause for a moment longer than it is supposed to, ending its down phase before beginning its up phase.

The 2nd piston pauses for 2 seconds at its fullest descent (both pistons are set to have a 2 second pause, this is needed to allow the pistons time to reach a fully closed or open state before the other piston begins to move) and begins to move back up.

The 2nd piston begins to detract.

http://id.lbp.me/img/ft/1bd9b982c846aeb2e9c337ec4b4ea7d35d483b8e.jpg
State 6. This is simply the same logic state as state 3 except now with the piston moving up instead of down. As the piston begins to move up, it turns off the RED sensor input, removing input from the AND gate and the XOR gate respectively. This simply switches the input to the 2nd piston from the red sensor back to the green sensor (through the OR gate), which is still active due to the 1st piston still being fully extended.

the 2nd Piston becomes fully detracted.

http://if.lbp.me/img/ft/9dfb89b30294fc2fe3167c4a6524443e4728784f.jpg
State 7. This is a problem state. I will explain. The 2nd piston reaches its fully detracted state causing the BLUE sensor to release input on the NOT gate. The NOT gate in turn triggers the 2nd input on the AND gate giving power back to the 1st piston. Here is the problem. Notice how both pistons at this point in time have power. This is because the 2nd piston will not loose power until the 1st piston begins detracting in turn triggering the GREEN sensor to switch off, stopping the 1 remaining input on the XOR gate and completely cutting power from that part of the circuit.

The Green sensor will turn off as soon as the 1st piston begins moving, but here is still a gap of a few milliseconds. Eventually, in this gap, due to the gradual de-synchronization between the two pistons due to faults in the logic (much like this one) that i have been describing throughout this post, The 2nd piston will eventually begin to try to move down just before the power is cut to its circuit as the 1st piston moves into range of the GREEN sensor. When this point hits, the 2nd piston will from then on think it needs to move up instead of down after the 1st piston has fully extended. This event horizon, as it were, throws the entire system of kilter, and from then on the process jars terribly.

The whole thing will work for a good few minutes up until this point, though i do not want to put something like this in a level due to the high possibility of it simply not working. It is too unstable for me to be happy using it in a level. Anyway. Moving on.

The final state.

http://i6.lbp.me/img/ft/20691deea7ad6606c46a0d2786b61f32cb1026ed.jpg
State 8. Here the logic is back in its initial state. This is for all intents and purposes the same as state 1. Here is a good place to highlight that the whole process will carry on automatically, indefinitely, well, until it jars up. I do not want it to carry on indefinitely.

What i would like help with:

firstly, i need help to possibly redesign how this works and get rid of the little gaps in the system that cause the gradual de-synchronization. I have thought quite a bit on how to do this and tried out many things along the way, ultimately culminating in me being at the point i am now. I simply cannot find a decent alternative to getting this logic to work the way i want it to. I understand the problem lies with cutting and giving power to the pistons by using sensor switches that move in/out of range via the movement of the opposing piston. There are moments when power is going to places it shouldn't, and so forth, but i state again, i really cannot find another way of doing this that works with power running to places, and not, exactly when it should and shouldn't do so. I know this is a big ask, but help on a whole redesign of this is my ultimate request.

Aside from that, my other big ask is to integrate some way of getting the gadgetry to run through all states, 1 through to 8 (or back to 1 depending on which way you look at it) and then stop dead until a manual input is triggered, through means of a sensor tag on a grab-able object or the likes that is pushed into a sensor zone triggering a single round of the logic process. That way the panel will open for 'x' seconds and the player will have to try to hit it enough times in the allotted time frame. If they fail they will have to, say, hit a switch again to emit another object with a sensor tag, re-place it in 'the zone' to open the panel and try again.

As it stands, once the switch has been triggered (2 way switch) the whole thing just keeps going. I need help on how to changes this aspect to my specifications.

So here it is folks. I hope this post has cleared up any confusion about the object in question and exactly what it is i'm looking for in respect to help. If i have missed anything out of this post that's obvious, or, of course, if you are willing to help me or know of anything logic wise (or other-wise) that will help me in my quest to solve this, you know where the reply button is

Thanks again in advance!

Peace out.
2011-01-26 07:24:00

Author:
Epicurean Dreamer
Posts: 224


I'm just getting into LBP so I'm not sure if this is too simple, but couldn't the problem be solved with a different type of sensor connected to several timers? You said that you want the item to be 'hit'; are you talking about being hit with the Paintinator, or something else? Because it seems like a pretty easy work-around that wouldn't require any logic would be

[Paintinator Sensor]
[Timer (0.1 seconds)] [how ever you're moving the piston, shows how much I know] *set once*
[Timer (3 seconds)] [retract] *set once*
[Timer (6 seconds)] [forward] *loop*
[Timer (9 seconds)] [retract] *loop*
[Emitter -stars- ]

Might need to add the .1 from the original timer in, I'm not sure.
2011-01-26 11:21:00

Author:
Riel
Posts: 6


I can help u out when I get home, I couldn't read the whole thing at work, but all u need is a sequence with toggle switches if ur trying to do what I think ur are2011-01-26 18:10:00

Author:
JStormz
Posts: 9


Ok I got some time, what you need to do is set up an "or" gate and output to piston 1, set another and output to piston 2, next set up a sequencer, open it and place a toggle switch at the very beginning, attach the toggle to the "or" gate input for piston 1, now grab another toggle switch and set it on the 4th column on the sequencer (by default a piston takes 4 seconds) now attach that to the "or" gate for piston 2. Now attach the what ever you want to trigger the sequencer. Make sure that you have your piston set to forwards//backwards they may also have to be reversed, I forget they're default. Now you have the first part done, next attach your hit markers to a counter, attach the counter to another sequencer that is identical to the other one except the outputs to the "or" gates will be reversed meaning piston 2 is activated first. U should have exactly what you're looking for2011-01-26 19:26:00

Author:
JStormz
Posts: 9


Ohhh, I haven't looked at sequencers at all yet bar the quite brisk tutorial on the object.

Thanks muchly for replying, your idea sounds pretty robust. I'll get to breaking down the steps you mentioned and fashion together what it is i think you are explaining.

Actually, reading your logic, are you referring to something that 'stays open' until the counter attached to the hit marker has been hit enough times? This is where it becomes tricky, I'm looking for something that closes regardless of hit counter. I really love the idea of getting the pistons to stay open using a sequencer with toggles though. OH what i could do is have the 2nd sequencer for the close action for the pistons set up to a timer that triggers when the 1st sequencer finishes.

thanks man you've put my theory down a whole other path. Definitely opened up some interesting avenues of experimentation. I'll get back soon and tell you how it went.
2011-01-27 02:17:00

Author:
Epicurean Dreamer
Posts: 224


It works, perfectly! well, I spent a long time playing about with the timings on the pistons, them things are so god dam fenickety. I've had to set the global sink timings to wierd things. I think one of them is something like 18.7 seconds?!

I've also taken your concept and adapted it a bit. What i've done is instead of using toggles I've used batteries on the sequencer set to 4 seconds with the pistons set to 8 seconds. Using toggles made the pistons turn on and run indefinitely which didn't work at all. I've also sinked up a battery at the end of the 1st sequencer to trigger a countdown timer which runs through (currently 10 seconds, but the point is its changeable.) its course which triggers the 2nd sequencer (and resets itself) The 2nd sequencer is a mirror of the first, closing the 2nd piston, then closing the 1st, then it all stops.

What i've also done is built a little tunnel of sorts in the background, i have a sensor tag on an emitted piece of glass that emits at the top of the tunnel when you hit a switch, the glass drops down a channel into the tunnel where you have to jump across a few gaps with dangerous stuff at the bottom and hit another button to trigger a piston that pushes the glass over into a sensor range which triggers the logic that opens the panel.

Now all i need to do is set up the hit sensor to a counter and link that up to the emitter that emits the platforms.... nearly done! Its been a mission. Thanks for the help! Epic stuff indeed.

by the way, this is the new logic:

http://ic.lbp.me/img/ft/cfcdd1616a53a40b2b357301b57a166663517d3c.jpg
2011-01-27 04:32:00

Author:
Epicurean Dreamer
Posts: 224


You still seem to be doing more work then u have to, the toggle will keep the piston fully extended till you choose to have another toggle to reset it, do you want the pistons to only do this motion 1 time or indefinitely2011-01-27 16:08:00

Author:
JStormz
Posts: 9


It depends on how you want to define 'indefinitely'. I want both pistons to extend then stop for an amount of time. Then both pistons to close back up and then stop 'indefinitely', until the logic is triggered again. Which theoretically is another form of indefinite. The whole process needs to be able to run its course an indefinite number of times, not just once you see.

Could you please explain to me how a toggle switch once triggered leaves the piston in an open state? I did play around with toggles on a sequencer, 1 toggle, once triggered starts the piston. The piston then simply attempts to run its open and close process until something interrupts the power flow.

As far as i know, and please prove me wrong because it would make what i'm trying to do a whole lot easier, there is no way to get a piston to treat its open phase as separate from its close phase. It appears it can only possibly see the process as a singular input and cannot define between the two movements. This is why i have had to devise ways of interrupting that process via other means at the specific point the pistons reach a completely open state. Yet it is possible to get a piston to completely open and then close, just once, but i have in no way seen any way of getting a piston to 'open', then stop, ready to close, without manually interrupting the power flow.

It seems to me a toggle simply triggers the input that moves the piston, from there the only way of further defining the process is by choosing which action the piston takes once it is powered ( on/off / 1 shot / flipper in/out e.t.c. ) Please explain to me how you have managed to get a piston to simply open by using a toggle.

Cheers for your help so far man, its very much appreciated
2011-01-27 20:24:00

Author:
Epicurean Dreamer
Posts: 224


I've been trying to follow this but am quite confused. Are you using the pistons solely for logic purposes or do they serve another function in the level. If they are just for logic, it seems that you could use timers and counters instead.

Without going into details of the logic, can you describe the effect that you want to achieve?

It seemed as if you just want a set of stairs to emit once someone triggers something x amount of times before a timer runs out, if the timer runs out the count resets?
2011-01-27 22:34:00

Author:
Osprey71
Posts: 93


It depends on how you want to define 'indefinitely'. I want both pistons to extend then stop for an amount of time. Then both pistons to close back up and then stop 'indefinitely', until the logic is triggered again. Which theoretically is another form of indefinite. The whole process needs to be able to run its course an indefinite number of times, not just once you see.

Could you please explain to me how a toggle switch once triggered leaves the piston in an open state? I did play around with toggles on a sequencer, 1 toggle, once triggered starts the piston. The piston then simply attempts to run its open and close process until something interrupts the power flow.

As far as i know, and please prove me wrong because it would make what i'm trying to do a whole lot easier, there is no way to get a piston to treat its open phase as separate from its close phase. It appears it can only possibly see the process as a singular input and cannot define between the two movements. This is why i have had to devise ways of interrupting that process via other means at the specific point the pistons reach a completely open state. Yet it is possible to get a piston to completely open and then close, just once, but i have in no way seen any way of getting a piston to 'open', then stop, ready to close, without manually interrupting the power flow.

It seems to me a toggle simply triggers the input that moves the piston, from there the only way of further defining the process is by choosing which action the piston takes once it is powered ( on/off / 1 shot / flipper in/out e.t.c. ) Please explain to me how you have managed to get a piston to simply open by using a toggle.

Cheers for your help so far man, its very much appreciated

It is indeed just as you have noted. The option within the piston tweak menu for INPUT ACTION should be FORWARD/BACKWARD, I believe (am at work, so I can't open it and check... may be IN/OUT). This is the same as sending a DIRECTIONAL signal from an old LBP1 switch. Once set to FORWARD/BACKWARD, then turning it on will open it and turning it off will close it (or vice-versa).
2011-01-27 23:01:00

Author:
v0rtex
Posts: 1878


Oh my. That should sure make a few things allot easier! I'll go play with it soon.

@Osprey. I'm purely using the pistons to move 2 little panels they are not involved in the logic. They were originally though, i was using them to trigger sensors, but then i learned a bit more about LBP2 logic
2011-01-29 10:19:00

Author:
Epicurean Dreamer
Posts: 224


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

Datenschutz
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.