Author Topic: Redo  (Read 8602 times)

Seems Epic Legendary
I think Floating Bricks should be removed. They have been removed everywhere else.

That's why it's not approved on RTB, but people decide that the best thing to do is post their broken stuff here where we can't remove it or stop all of you downloading it.

That's their problem, as long as RTB doesn't take the heat for distributing broken stuff then I honestly don't care!  :cookieMonster:

Well, I'm making it so when a floating brick is being planted, it pushes that bricks info back one until it can be planted.

I'm just going to work on Multi Redo because that would get rid of floating bricks. I have an idea for it too.

I'll take down the download for now =/

One or the other.

I'm currently working on the redo-all-at-once-thing and I have found an unorthadox way to get all bricks killed in a Chainkill without inaccurate radius searches.
« Last Edit: August 08, 2009, 08:42:51 PM by AGlass0fMilk »

I have found an unorthadox way to get all bricks killed in a Chainkill without inaccurate radius searches.

It better be getNumUpBricks() and getUpBrick(%i)...

That might be unreliable, it could return bricks that wouldn't get chainkilled by the destruction of one brick.

And for some reason when I use getNumUpBricks, it always returns 1
« Last Edit: August 08, 2009, 10:02:59 PM by AGlass0fMilk »

That might be unreliable, it could return bricks that wouldn't get chainkilled by the destruction of one brick.

And for some reason when I use getNumUpBricks, it always returns 1

You'd use that and its downBricks equivalent instead of radius searches to check for path to ground.

The only thing I would need this for is large builds :/

I have multi Redo working, but I have to fix some bugs with it. It lags when you redo big builds, like the duplicator. I don't know if I should put a limit on it or not.

Hah! I could do it >:C

I have reduced the amount of lag by removing a feature from the MultiRedo. The regular redo still has the feature. It is a loop that for every brick created it loops through the entire RedoStack replacing the old Brick ID with the new Brick ID so you can repaint/whatever it with Redo. Taking it out of multi redo considerably reduces the lag.

When redoing Demo house (~140 Bricks) it would lag ~4 or 5 seconds. Now it does it instantly.

I'll release it later, once the Multi redo bugs are worked out, but I'm not going to put that functionality back in for latency's sake. I'll let you guys have fun with it, but if you want it put back in, I'll put it back in.
« Last Edit: August 08, 2009, 11:24:25 PM by AGlass0fMilk »

It lags when you redo big builds, like the duplicator. I don't know if I should put a limit on it or not.
make a RTB Preference, like the duplicator has

Rather than pasting everything all at once, paste them in blocks of (settable amount) bricks every (settable delay) milliseconds like the duplicator should.

This gives people on my server Invalid Packets.

Finally, I've been waiting for something like this for... (looks at watch) ever since I read this topic.

You've got high hopes for this milk guy haha

Also:

It seems you still don't considering the number of times you had to post in Coding Help to even get this far, and apparently its still broken and missing important features?
Ephi You need to learn how not to be such a richard, If he were here as long as you have been here he would probobly be twice as good as you if not more

Ephi You need to learn how not to be such a richard, If he were here as long as you have been here he would probobly be twice as good as you if not more

That was a pretty richardish post Ephi made.