Archive: 7 posts

---

I am making an enemy that starts off on a Motion Recorder animation loop that speeds up as the player gets closer to a certain sensor that is on the ground. But if the player gets within 5 meters of the enemy itself then the enemy switches to a follower and goes after the player. I got that working fine. But I'm interested to know what logic people are using to do more complex branching behaviors, like maybe switching to a different movinator pattern if the following has led the enemy to a certain other area, or perhaps an enemy that cycles randomly between various Motion Recorder routines? Thanks

2013-04-24 22:42:00 Author: vitamin_arrr Posts: 10

---

No answers yet, eh? Let me be more specific: I want to make an object move to a certain spot via an animation (anim_1), then start a new animation (anim_2) if a certain condition (a) is met. This might take it to a new location where another condition (b) would be checked for, in which case it would do yet another animation (anim_2) or just loop anim_2 until (a) is no longer true (in which case it would switch back to anim_1). But there are some weirdnesses that I've encountered... and discovered some other interesting things in my testing so far... read on! If you record an animation with Motion Recorder (or with the touch controls on Vita), it has a starting point that can actually move around as the animation loops. This is BAD for what I am trying to do, so here's how to avoid the animation's starting point moving: if your animation is set to back-and-forth playback, then the start position will remain protected. (It might also work to record with a "return to start" option (by pressing X during recording, but I find it awkward to record that way. I'll try to test this and get back to y'all.) What I mean by "protected" is that as the animation loops, the object won't migrate all over the dang map. It will always stay in the same spot. Now, I also found it's good to set the object and any scene objects that in might ram into to "indestructible," since if the thing tries to go through something it will either disintegrate itself or the thing it's hitting. Even if you set it to "indestructible," you can still destroy on purpose it with a "destroyer" on the microchip (set to trigger on projectile impacts for example). OK, so now you have a looping Motion Recorder animation, that's basic stuff. But here's where it gets interesting. If your object switches to another movement-based behavior (for example, Follower), then switches back to the Motion Recorder, there are THREE different possible outcomes that can happen: 1) If there is any time (even a single frame) when both the Follower and Motion Recorder are OFF, then when the Motion Recorder becomes active again, its starting point will have migrated. 2) If there is any time when BOTH the Follower and Motion Recorder are active, they mess each other up. I'm not sure how it affects the starting point, but I would just say, avoid this outcome. 3) If your logic successfully switches perfectly between the Motion Recorder and Follower with no gaps or overlap, then when the Follower deactivates the Motion Recorder will instantly reactivate on the very next frame, calling the object back to the animation's starting position (and the object will fly back to that spot super-fast and with great force, even if it's a slow animation!!). Now I also found this holds true if you're switching between different Motion Recorder animations on the same chip, as in the case of using a randomizer to cycle between several of them. But there can be weirdness where the starting positions reset if certain things happen... I'm still not sure what causes this, but I do know that capturing the object to your goodies bag preserves the starting points. Placing the object back into the world from the goodies bag will not reset the starting positions. Emitter emitting the object won't reset it either. The starting position is relative to the object's position at the time of capture, not a global position, though once it's placed, now it's fixed in global unless a reset occurs or there's a dead frame. Now if you get an animation/follower switch working like this, now you can capture that object, and have an emitter keep 'em coming. Will post more later, gotta work.

2013-04-26 17:04:00 Author: vitamin_arrr Posts: 10

---

Vitamin, I think you are overcomplicating by trying to record the whole animation, while you could give your sackbot some AI to just follow a routine, like running on the right, jumping for 0.5 secs when he mets a certain tag, etc. Unless you really have something to record, you should get a look at these tutorials on basic sackbot AI/acting: basic acting (http://www.youtube.com/watch?v=IBYx49PaykM) sackbot automation (I think that's what you need there) (http://www.youtube.com/watch?v=JFVazXuQ1bc) sackbot AI (http://www.youtube.com/watch?v=5bDTsD29o-I) Hoping that helps you! Edit by proofreading: I'm not familiar with the movinator, so I'm not sure my answer qualifies.

2013-04-28 14:02:00 Author: Djibees Posts: 189

---

aand BOOM link http://www.youtube.com/watch?v=5bDTsD29o-I I'm pretty sure this is what you're talking about. Keep in mind I'm pretty sure you're not using sackbots which is alright. The main focus is the player sensors, the selector, and all that jazz. However, since you have your non sackbot enemy, you should focus on making several different interactions. Be creative!

2013-04-28 20:05:00 Author: megaextremist Posts: 221

---

They're not sackbots... I am not using sackbots. EDIT: aand BOOM link http://www.youtube.com/watch?v=5bDTsD29o-I I'm pretty sure this is what you're talking about. Keep in mind I'm pretty sure you're not using sackbots which is alright. The main focus is the player sensors, the selector, and all that jazz. However, since you have your non sackbot enemy, you should focus on making several different interactions. Be creative! Thanks, I'll check it out.

2013-04-29 06:06:00 Author: vitamin_arrr Posts: 10

---

The benefit of Selector is to avoid having two Motion Recorders playing back simultaneously. I also found I can use Tags in a Sequencer to fire off Tag Sensors connected to independent Motion Recorders, causing them to fire for a brief time, which cannot be changed and seems relative to the Sequencer based on each Tag's unchangeable width (a Battery on the Sequencer connected to a Tag on a Microchip could get around this). If the Tags don't overlap then the Motion Recorders each play a segment of their recording in sequence with each other. That said, this was done with Anti-Gravity at 100% and Dampening at 0%. One caveat to using Tags on a Sequencer like this is that if no Tags are active, therefore no Motion Recorder is active, and the object will simply continue along the vector of the last impulse it received from the last Motion Recorder to have been active just prior to when all Motion Recorders became inactive. Unless that is the desired behavior, you must wire each Tag Sensor not only to its Motion Recorders but also through a Not Gate that is wired to an Anti-Gravity Tweaker set to 100% anti-gravity and 100% dampening. You must also set up your circuit with an And Gate such that when 100% dampening is active, the other Anti-Gravity Tweaker that has 0% dampening (necessary for the Motion Recorder playback to work) becomes active. The way I did this was by wiring a Battery to one input of the And Gate, and then each Tag Sensor's output goes into the other input of the And Gate (through a funneling series of Or Gates), then wiring the And Gate's output to the 0% dampening Anti-Gravity Tweaker, so that whenever a Motion Recorder is active, then object can move. Then when the And Gate's output is Off, that deactivates the 0% dampening and simultaneously causes a Not Gate to turn on, which in turn activates the 100% dampening Anti-Gravity Tweaker. This allowed me to have a Sequencer that causes four different Motion Recorder loops to playback in sequence, 1 second at a time, for example. This can have some weird effects but looping back to the original start still seems to work if it's done correctly. I'm still experimenting on what some of the weird effects of this might be, since I've found that when you deactivate a Motion Recorder in the middle of its loop, then use some other Mover (like a Follower) to then move the object some distance away from where the loop originally began, then when you reactivate the Motion Recorder that was in the middle of its loop when it stopped, the object will violently try to return to the point in the map where it was when that animation loop had stopped, and won't resume the animation along a new set of coordinates as one might expect! However if there is any point in time when a Mover is not active, then the game's physics engine becomes responsible for determining the object's coordinates and vector of motion; in this ever happens, then when a Motion Recorder that was stopped in a loop becomes active again, its path may now have moved somewhat. The path can also move if the object is on a continuous loop and something impacts it, I suspect, but it seems to maintain its path's position perfectly if it is on a forwards/backwards type of loop. Just some observations, I will try to post more detail later.

2013-05-07 18:34:00 Author: vitamin_arrr Posts: 10

---

Not familiar with the motion recorder stuff, but I never use anti-gravity tweakers in moving objects....I use a mover with the speed set to 0, or if using an advanced mover i activate a battery with 0% strength No need for all that confusing complex logic...And also objects with anti-gravity tweakers can't rotate, but objects with movers set to 0 can.

2013-05-07 19:58:00 Author: dragonboy269 Posts: 172

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.