FxShapeReplicator Idea: Drop Objects

#1 Sounds grand, except that you then lose the reason behind the shape replicator. You see, the replicator only sends a few parameters over the net to save bandwidth. If you had to transmit all of the objects created with it, it would take ages to load a mission. The way the replicator works is to send a random seed to the client so that it generates the same objects, the same way, everytime using a consistent algorithm.

You could make a small packet updater that adjusts individual objects after replication is complete, but that would be an extreme amount of hassle.

- Brett

#2 Well then if you could select a shape and drop that as an object, so that you can tweak it means you still have both the replicator for most of the general mass, and then the tweaked objects that go into a simgroup.

Toby.

#3 A cool idea; you should implement it! :)

#4 Err... I'm not that certain about the benefits of the replicators in terms of mission loading. We have a massive mission (over 1MB), with several dozens of replicators, and the loading progress stalls for quite a while after the loading bar has reached 100% (while"startServerReplication" and "startCientReplication" are taking place). The load time might be a bit faster than placing each object individually, but it doesn't fell like that since the loading bar hangs up for too long after it was supposed to be done.

And there's a bit more to it. In our new project, we forgot to tell to the new mapper about the replicators, and the poor buy placed tons of trees and fences by hand. The performance is clearly higher than in our current project, that uses replicators for anything that repeats more than 3 times (we added extra replication "modes" so we could replicate stuff in straight lines, for fences and other linear-repeating stuff, as example). So there might be something strange going on in there, but we didn't have much time to look into it right now.

Whenever I get the time, I might post the extra replication modes, maybe they're of some use for someone. At least, it introduces the required changes to add more replication modes (we still have plans for a replicate-on-path mode).

#5 Yes, in the case of many replicators you're trading (essentially) in-load bandwidth for post-load processing time.

#6 What you REALLY need when it coms to replicators is replaction caching. So you can have a seperate replicator cache file that stores all the replications.

#7 Manoel, I hope you do post those changes sometime. The replicate along a line would be nice, and, if you ever get the ona path working, that would be extremely helpful.