| Pages: 1 [2] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
darkmancer
   |
Posted - 2008.07.11 20:20:00 -
[31]
 Originally by: Pwett
Originally by: darkmancer
It'd save tons of work for the server, but you'd almost never get 8 wreakings :)
Little fix, probabilities will bite you in the ass sometimes.
Sorry i misexplained things - i'll try again.
Rough approximation of the current system:
server works out % chance if the shot hits or misses, server rolls to see if the shot hits, if it hits there's a dice roll to work out the hit type (well aimed, wrecking, etc) then it applys the hit type to (turrets damage modifier x ammo damage).
Now it'd go though this for every shot fired.
Now lets propose an alternate system:
n = number of matching turrets.
dam = Damage type modifier from (n-1 x poor hits + 1 decent) to (n-1 good hits +(1 wreaking x ((Percentage to wreck ^n /100)+1)
server works out % chance if the shot hits or misses, server rolls to see how what % shots hit then multiplies by dam x ammo.
Old system 8 calcs, new 1 calc (damage is worked out when each turret is online.
Dam is worked out whenever a turret is onlined/offlined (ie out of battle). The new system only saves calculations when two or more turrets of the exact same type are used (most people tend to use as many of the same type as possible), but doesn't lose anything other the old system if different turrets are used.
There's probobly a few holes in there but a variation of this system could save tons of server work for turrets lanchers and drones especially.
---------------------------------
There's a simple solution to every problem. It is always invariably wrong |
Windjammer
|
Posted - 2008.07.11 20:20:00 -
[32]
Not that I'm an expert on this, but wouldn't it be a higher load to a server to send multiple commands one at time, i.e. one command per gun, than to issue one command for all the guns?
Regards,
Windjammer
|
NetMage
|
Posted - 2008.07.13 05:45:00 -
[33]
Since I'm PVE, I'd be happy with a load all command that just worked when docked.
|
Gavin Darklighter
THE FINAL STAND
|
Posted - 2008.07.13 17:12:00 -
[34]
Edited by: Gavin Darklighter on 13/07/2008 17:15:25
I really like the idea of being able to group all the guns into one big gun, but the biggest issue I see is how to apply damage from overheating. The server could easily calculate the damgae applied to each gun, but if the "grouped weapons" appear as a single icon in the modules area, the player will not be able to see what the damage level is for each gun.
What I would do is make it so that the first weapon in the "weapon group" shows as an "active module" with all of the ammo from each gun combined (I.E. an 8x 800mm II autocannon group would show 480 ammo loaded on the active gun). Then the weapons that got grouped into the first weapon would show up as passive modules that can be overheated and would show their damage state and if they are online or not. Each gun that gets overheated would increase the weapon group's damage modifier by the appropriate ammount. Missiles might need to be changed to an overheat bonus of damage instead of ROF to accomodate such a system.
As for damage and to hit calculations, I think they will need to be handled differently from the way normal damage calculations are applied. When you fire 8 guns and half miss, you still do half damage. But when you fire one gun and it misses or hits, you are dealing full or no damage. Also when you get a wrecking hit with one gun out of eight the extra damage is nice but not that great. If you get a wreck with an eight-gun group, it would be absolutely devestating. So instead of calculating if a weapon group misses or hits once, it will either have to:
A. Calculate whatever the tracking, optimal, signiture modifiers are once and then use those figures to "roll the dice" each individual gun, or..
B. Make the damage not random but based on a curve so that the weapon group does x% of full damage based on the modifiers mentioned above.
The last thing that I see as an issue to grouping weapons is what happens when your target is almost dead and you fire a shot that does twice as much damage as you need to finish it off. With ungrouped guns you would be able to immediatly fire the un-used weapons on another target. If we went with option "A" from above where each gun has its damage computed individualy, then it would be easy to figure out how many of the guns in the group were needed to kill the target. Once you know that the server could reduce the damage modifier to compenstate for the guns that are still cycling and let you fire the remaining weapons.
|
csebal
HUN Corp.
HUN Reloaded
|
Posted - 2008.07.18 15:32:00 -
[35]
Well, its freightening how unimaginative CCP is.
You tell them "change all" and whats their first idea? Do it really all at once.
Hell noone said that. People merely want to save themselves the chore of having to click through each turred and select the proper ammo to reload. Then reload the guns where they misclicked again.
Instead you could just create a simple option, that does this for them ON THE CLIENT SIDE. It will not generate more anything, than what the player alone would have generated. It would merely save your customers some time they could spend working around all the other issues there are with the UI.
My post does not represent the general or official opinion of anyone else besides me. No matter what YOU believe.
Phear the arrows of the HUNs >>----> |
Tarminic
24th Imperial Crusade
|
Posted - 2008.07.19 02:02:00 -
[36]
Originally by: CCP Wrangler
CCP said that this issue has been brought up in the past, but has been rejected due to performance reasons. Moving items around causes a heavy load on the servers and making guns easier to reload might encourage players to do it even more frequently. There are concerns that during large fleet battles, all ammunition will be changed at the call of a fleet commander, which would cause an enormous spike on the servers.
Interesting, I had no idea that simply shifting contents from the hangar to guns could cause such large amounts of lag.
I would love a more technical explanation of why this is so and what can (or can't) be done to fix it. I'm guessing this is just an issue of lag being caused when any generic item is moved from one container to another. Though this would be a bit of a hack, why not give weapons an "ammo_quantity" attribute and an "ammo_type" attribute, where the "ammo_type" attribute references a singleton entity that provides the damage types and modifiers.
Calling a function on a singleton object might be significantly faster than moving items between containers.
----------------
Play EVE: Downtime Madness v0.83 (Updated 7/3) |
Tarminic
24th Imperial Crusade
|
Posted - 2008.07.19 02:04:00 -
[37]
Originally by: Windjammer
Not that I'm an expert on this, but wouldn't it be a higher load to a server to send multiple commands one at time, i.e. one command per gun, than to issue one command for all the guns?
Yes and no.
Making multiple commands increases the network load because you're sending "change X ammo" eight times instead of "change 8X ammo." From the server's perspective, the fact that the commands come in sequentially lets it process the requests as they arrive instead of being slammed by all of them at once. I'm guessing that the server cycles are a greater bottleneck then network bandwidth.
----------------
Play EVE: Downtime Madness v0.83 (Updated 7/3) |
Deldrac
Bat Country
Aegis Militia
|
Posted - 2008.07.19 14:33:00 -
[38]
Biggest problem I have with CCP is that they are far to quick to focus on new shiny at the expense of getting the core gameplay right.
I have a really hard time believing that fixing the server load problem they describe is harder than, for instance, introducing a pointless walking-in-stations module.
Support the original request, don't support this nonsense response from CCP.
|
Trojanman190
D00M.
Triumvirate.
|
Posted - 2008.07.22 15:30:00 -
[39]
So if I thumbs up here it means I'm NOT supporting getting a reload all or switch all ammo button?
Where do I go for that?
|
Mister Xerox
|
Posted - 2008.07.22 15:40:00 -
[40]
I endorse this, but perhaps with some modifications.
Someone once suggested linking weapons into Weapon Groups that could be loaded and unloaded as a single unit. They would also fire as a single unit linked to a single F key.
This would reduce the server calls from 8 individual weapons down to 1 or 2.
|
|
|
Rogerano
Minmatar
Einherjar Rising
Cry Havoc.
|
Posted - 2008.09.29 01:37:00 -
[41]
Now that we have this awesome new stacklessIO technology, concerns about server load are no longer relevant, right?
---
Not happy with something in EVE? An emo whine will doubtless help your cause. |
Padanemi
|
Posted - 2008.10.08 10:40:00 -
[42]
Originally by: Mister Xerox
Someone once suggested linking weapons into Weapon Groups that could be loaded and unloaded as a single unit. They would also fire as a single unit linked to a single F key.
This would reduce the server calls from 8 individual weapons down to 1 or 2.
WOW! Amazing suggestion/feature!!! Not to mention it would reduce the calls to db FOR EACH ACTIVATION/DEACTIVATION if implemented properly.
Originally by: Rogerano
Now that we have this awesome new stacklessIO technology, concerns about server load are no longer relevant, right?
True.
Up.
|
LaVista Vista
Conservative Shenanigans Party
|
Posted - 2008.10.08 11:19:00 -
[43]
I can see your logic about Stackless IO reducing lag, thus making it less of a concern.
But I don't think just because we have had such an awesome improvement, that it means we can just throw DB calls all over the place.
We could re-raise this issue, but you will get the response much sooner if you ask a dev during a Q&A session at fanfest.
|
Another Forum'Alt
|
Posted - 2008.10.08 12:07:00 -
[44]
People regularly change ammo type anyway. A way to do it in less clicks won't affect what is already done regularly.
If you really want to complain about lag, just set a limit e.g. you can only change ammo for every weapon every 1 min or whatever/
This is not part of my sig.
...Or is it? |
Darwin's Market
|
Posted - 2008.10.08 15:16:00 -
[45]
Ok, how about it only working while in station.
|
Aarin Wrath
Caldari
|
Posted - 2008.10.08 20:30:00 -
[46]
Edited by: Aarin Wrath on 08/10/2008 20:34:40
1. How is this different than CTRL-R ?
Your doing a "reload all weapons with avaiable ammo" command there...
2. Could you not just setup a client side macro disguised as a reload all with ammo X button?
This macro would reload all turrets with the new ammo using a sequential, time delayed, command.
i.e
->send commands to reload Turret 1 with ammo X
->wait
->send commands to reload Turret 2 with ammo X
->wait
You could even make the delay longer that a human's manual reload time, thereby decreasing the command spikes on the server.
Edit: phrasing
|
Blastil
|
Posted - 2008.10.08 22:13:00 -
[47]
Edited by: Blastil on 08/10/2008 22:14:43
How about having it automatically stagared? So when you hit reload all you get an in-game macro that unloads one gun, loads it, unloads the next gun, loads it, etc. hell, if you time it right, you might even reduce lag.
|
Liranan
M'8'S
Frontal Impact
|
Posted - 2008.10.09 11:16:00 -
[48]
CCP's ignorance is sometimes unbelievable. Amarr swap ammo immediately and have the best snipe ships in EVE. How many Amarr only fleets participate in fights? CCP should stop pretending the CSM mean anything and admit the CSM are just a veil hung before our eyes in the hope we won't get even more angry with them for being blind and not playing the game.
Until CCP start listening to what we want rather than what they think we should want the CSM and all proposals are a joke. CCP should rename to Sony v. II and simply admit the nonsense that goes on in the game.
Farjung is my God |
Vio Geraci
GoonFleet
GoonSwarm
|
Posted - 2008.10.09 23:24:00 -
[49]
Consider allowing fire-linking of turrets or launchers of the same type.
Have your seven tachyon laser turret act like a single turret that does x7 damage, and when you load it, it takes x7 of the ammo. I dunno, it might be a way to reduce DB calls. |
|
|
| |
|
| Pages: 1 [2] :: one page |
| First page | Previous page | Next page | Last page |