what if you didnt need to deploy equipment to use it? say if you fit nanohives on your suit, if you wanted to give ammo to someone you would just run up to them and stand near them. if you fitted a dropuplink your squadmates would simply spawn near you.

and if you wanted to use explosives...
jk, you still need to deploy those lol

not having to deploy nanohives means if your squad sticks together then they wont run out of ammo as long as someone has one.

a scout can carry uplinks and suddenly he becomes a powerful asset. staying off scan and alowing his squad to deploy near objectives or take advantage of weak defenses.

and the best part is that theres no equipment spam! which means no/less frame rate drops.

Why even transmit the location of equipment regularly?

Why not only when equipment is laid down or is removed? It doesn't move. It doesn't change orientation. Just cache it locally on the PS3 and let the system handle display. If the PS3 can't handle the display, simplify it.

It's not like server interaction is needed unless the merc is requesting supply from a hive.

Evidence-to-date in DUST's development history indicates that is a bad idea.

The risk of a band-aid patch here is high, and it would only come back to haunt us later. There needs to be voices in these threads telling CCP that the desired course of action is to address the underlying issues.

Speaking only for myself, ofc, that is the desired course of action.

The suggestions going around that the equipment spam is related to an audio issue is a perfect example; disabling the audio effect for uplinks and nanohives would have zero real effect on gameplay. I would gladly give up a little immersion to make the game more playable.

None of the proposed restrictions would solve the frame rate issue and all would reduce options and fun.

Team wide restrictions? People could still dump everything in one pile.

Individual restrictions? People could still dump everything in one pile.

Proximity restrictions? One type of equipment could lock out all others within a useable radius. Someone drops an RE and it locks out uplinks and hives? This gets worse when we get deployable shield bubbles and other types.

Why even transmit the location of equipment regularly?

Why not only when equipment is laid down or is removed? It doesn't move. It doesn't change orientation. Just cache it locally on the PS3 and let the system handle display. If the PS3 can't handle the display, simplify it.

It's not like server interaction is needed unless the merc is requesting supply from a hive.

What do you think about the triage and ammo types?

Maybe change the skill that for each level you can maintain 1 hive, this will have a maximum of 5 hives active at all times.

That's like 3 gauged and 2 triages, that's all I need for my team (spread out).

I guess a team will still be able to spam them if everyone does it.

God I wish I was in more games where people spammed nano hives, because I'm always out of ammo when I don't carry hives myself :P.

An active way of support still sounds like more fun, what do you think about that?

imo logis dont need a light weapon. if theyre doing their job, then theyll be too busy to shoot anything. logis should just have a side arm

I have multipule jobs, none of which involve becoming your slave and sitting in the back repping and resupplying people 24/7.

Also, while we are talking about being limited to their jobs, why can Assaults and Commandos carry equipment?

Support's not their job, so let's remove it.

Yeah because the current mechanics on how equipment and support works don't contribute to the problems you wrote down in your first post...I guess we can't discuss that and stick to same old crappy system .

I don't understand this statement.

I don't know Dust's engine in detail, but from general digital sound knowledge, I would assume that if equipment sound is causing lag, it's most likely to be reverb related.

Ie: the calculations needed to apply a reverb effect (make audio sound like it's in an actual room or hallway) are very processor-intensive, compared to just playing an audio clip. Grab any DAW and loop some sound while applying a reverb effect. Watch CPU load rise as you increase decay time of the effect. Add more sound sources to the same reverb and the load might increase exponentially, depending on how the sound mixing is done. Reverb effects that simulate smaller rooms or rooms with highly reflective walls might also be more resource intensive, since they have to calculate how the sound bounces of walls multiple times.

In any case, limiting the sound emitted from equipment in some way could only be good anyway, even if the sound isn't creating any lag at all - the sound of 5+ nanohives tighly clustered together in a small room is just a headache inducing, useless sensory overload anyway. Voice comms are impossible when in the middle of that racket.

I think nanohives should have their audio muted if they're closer to a nanohive from the same team than, say, 6 or 7 meters. Or at the very least, the combined volume of multiple hives should be lowered to a more tolerable threshold, and only a few of them should be routed to the reverb effect.

Wait, lets think about this.
Is to much equipment the problem?
Should we limit them or expire them after a set period?
Should raise the fitting cost on them?
Should we limit the ability to change fits at a depot?

I say no to all this! Lets think about it not in a cause and effect issue but as a game issue.
Problem: All these spawn points and nano hives make it so the frame rate is so bad it give me a headache and everything is so jittery that I can't even walk around without bumping into walls and falling off buildings.

The real problem is not the spawn points or nano hives but the frame rate, so lets not nerf the equipment but fix the frame rate. How might that be done?
1) Fix the data flow between server and user, if a player is not in the area where all the equipment is then don't send his ps3 that data so then he is not effected by the links and hives.
2) Add more server processing to handle the rendering.
3) Add more band width to handle the transport.
4) Set a thresh hold for when frame rate drops below a point, then lower resolution is deployed to increase frame rate (I think we all would agree that lower resolution is preferred to choppy game play).

These 4 solutions are all viable solutions to a problem and should be looked at first instead of a knee jerk reaction of modifying equipment or user use of equipment to increase frame rate.