Senior Member
Is there any way to repeat a set of 10 commands for 40 different objects in sequence, other than having 400 individual commands? It starts to have a huge performance hit after a certain point.
Would it help to have each command disabled, enable it just before it gets used, and disable it again after it runs? I'm kind of hesitant to disable anything by default, though, since the editor can sometimes get buggy and switch it back to enabled without telling you.
Impulse Delay Filters could do the job.
Hmm, I can't think of a way to do that. You can repeat the same code, but you can't make that code affect different objects, it'd just keep affecting the same objects whenever you repeat it. It would be possible if we could have a value object which functioned as a pointer to a specific object which events could use as target, but well, now I'm just saying stuff which isn't in the game so that isn't very helpful.
Edit: If you're okay with duplicating code, you could add a delay filter in between each code chunk like bob suggested, but that wouldn't prevent it from looking really ugly and becoming a huge hassle if you find out there's something you need to change with the code you duplicated.
Think it would be possible with the base code passing an impulse to an impulse splitter, which then passes the 40 impulses onwards. Using 2 filters (less than and greater than) on the driveline, you can set which event you want to trigger, and you'd get what you want to activate only when you are there.
Senior Member
well their are many ways to reduce code but it depends on your experience, how well you understand things and how they work and how smart you are
but in the end you might find the solution yourself and that can happen anywhere
maybe you can give a bit more information about the code
you could use a impulse filter to split the signal so its send to all objects
if the code doesn't depend on the object is tied too their is a way to reduce it
if the signal it send is different depending on the object its harder to split and ineeds to need have some code to make it independed that might make the code , its different for each situation
Hey nanner. It will take about 6 impulse splitters (five splitters to feed your instances and one splitter to branch off of your main source to feed the five splitters. Each only accommodates 8 outputs) , a generic filter for each required activation (40), a generic data source (the one that just holds a value), and a set-value event which is set to add (1). It's a lot of stuff, but still far less than duplicating all your instructions 40-times.
-- Pass the main signal to each of the impulse splitters.
-- Pass an impulse to each generic filter.
-- Tie each of the (value 1) slots on the generic filters to that same generic data source (the one that just holds a number).
-- Set all of the generic filters' conditionals to "equals" and set the (value 2 slot) to one number higher in each subsequent generic filter. (1,2,3,4... 40)
-- Tag each of the generic filters' (on True) impulses to their respective event triggers.
-- Tie the set-value event to the generic data source, then ensure that it gets an impulse with each event activation.
If you set this up right, every time the event gets triggered the generic data source is incremented +1, so that at every instance of activation a different gate passes an impulse while the others remain closed. You might have to send one extra impulse to the (set-value) event immediately after the end to ensure you don't get multiple activations on the final event in the chain.
Best of luck. I'm very much looking forward to whatever bit of craziness it is that you're cooking up!
Senior Member
I'm trying to make an array of object appear, one after the other, with a delay in-between each one.
I think I figured out what was slowing it down.
I was trying to do it this way:
[code:37lge3b6]Set VarDatSource_1 = 1
CustomCollision_1.PhysicsType = VarDatSource_1
Object_1.Visibility = True
Delay 5
Set VarDatSource_2 = 1
CustomCollision_2.PhysicsType = VarDatSource_2
Object_2.Visibility = True
Delay 5
'etc...
[/code:37lge3b6]
but I realized it's actually faster to just use an object position event.
[code:37lge3b6]
GlueGroup_1 = (Object_1 , CustomCollision_1)
GlueGroup_1.Position.Local = (0,0,50)
Delay 5
GlueGroup_2 = (Object_2 , CustomCollision_2)
GlueGroup_2.Position.Local = (0,0,50)
Delay 5
'etc...
[/code:37lge3b6]
I just wish I could do it like this:
[code:37lge3b6]
For n = 1 to 40
GlueGroup(n).Position.Local = (0,0,50)
Delay 5
Next n
[/code:37lge3b6]
Unfortunately, I don't think there's a way of changing event targets at runtime , so each object has to have its own position event.
Btw, grimm, I did use that impulse splitter method for something else, and I was surprised at how well it worked. I was able to send a single interval trigger to 32 simultaneous position events, each controlled by about a dozen filters and operations, without any noticeable lag.
Now I'm just wondering if it's better to use the object position event on a glued group, or split the objects up and select them as two targets.
I'm not completely certain, but glue seems to make everything a little more complicated for the game to process. I'd wager any time you can make your build function without it you'll get a little performance boost.Originally Posted by nannerdw
One editor peculiarity I've noticed is that anything but the simplest of visibility events generally causes a hit to the frame-rate. Especially if it happens close to the game-camera.
