I like battlesuits

[Spiney]

.

[Tremulant]

Whenever i play UBP i find that aliens, unless outclassed by a human team containing a couple of players who aren't totally inept(bearing in mind the kind of people who find UBP entertaining, severe levels of ineptitude are to be expected), and assuming standard trem maps rather than some of the hilariously poor ones that are often in rotation on these lolservers, will turn around and completely decimate the human turret spam at SD, if not before, marazap, and a bit of sniping where necessary, really makes it quite straightforward.
Attempting to balance ubp is a total waste of time, as is playing the thing, both teams build and feed until SD, then camp hard until their bases are whittled away to nothing, simply horrible.
On seconds thoughts, yes, do make such a mod, anything that slows down the building process has the potential to make UBP fans lose interest and play the sims instead.

[Spiney]

.

[/dev/humancontroller]

Another example is this: on Niveus aliens grab window and spam it with ****loads of hives at S3. When a human walks through the door suddenly all the entities need to get loaded into memory which causes a delay clientside, but not serverside.

wrong.

[Spiney]

.

[/dev/humancontroller]

Then how does it come when I enter the room it is empty? And the second the stuff shows up I'm already dead?

first, as you know, the engine sends entities only to relevant clients (as defined by visibility and entity properties).
when the server sends an entity state to a client, the full state is sent in the "first" packet. in the following packets, the server sends only state differences. this is called delta-compression. this method is bandwidth-effective if the entity states change only partially in most cases. for example, in case of stationary buildables, only their animation changes often. in case of players, only their position, animation, events, and class change. but technically, a newly seen entity is interpreted as a big state change from the null state to the actual state. as a result, sending an entity state for the first time costs a lot of bandwidth, but minimal bandwidth afterwards. also, a little bandwidth is also consumed when the state doesn't change at all.
the less bandwidth the server has, and the more entities there are packed in tight spots, the more the display (of the entities, of client frames) will lag when the server sends all of those entities to your client.
we could change the design to constantly keep sending entity states (even if the client is far from the entity), but then you would receive additional lag all the time.
this design can actually be improved by improved by slowly sending updates to entities that are out of sight (altering so-called baselines).