These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Test Server Feedback

 
  • Topic is locked indefinitely.
 

Little things in Rubicon 1.3

First post
Author
Zappity
Aliastra
Gallente Federation
#121 - 2014-03-06 10:47:52 UTC
CCP karkur wrote:
Charlie Firpol wrote:
CCP karkur wrote:
Charlie Firpol wrote:
Jinn Aideron wrote:

Since you are here (Rab See, Charlie Firpol, everyone really) and interested, I thought I'd ask your input. Any creative solution on how to bring your ideas to fruition? And/or on the above?


Oh, I dont want any of that saveable, dropdown menu thingy stuff.

Atm on the test server there is that totally awesome range slider, which has several ranges saved, like 0km, 1 AU, 5 AU etc.

All I want is PLEASE add one more option to that bar! 200 000 km!

This alone would basically cut the time I have to spend messing with the dscan in half in factional warfare.

We just changed the lowest value on the slider to 100 000 km (can go lower with the km field), and changed it so a scan is performed on releasing the slider.


Wow you just posted while I was editing my post oO Thank you a lot!

I really dont want to be picky here but ehm...exactly 100 000km is too close. Some complexes have a distance between acceleration gate and the warp-in beacon of exactly 100 000km, so this would get some wacky results once whoever is inside slowboats a couple of kilometers away from that beacon in the wrong direction.

Oops, Fozzie just pointed out to me that I wrote the wrong distance... it's actually 1 million, which we think will cover those cases well. Would that work for your use case? And if it doesn't, why not?

Perfect.

Zappity's Adventures for a taste of lowsec and nullsec.

Open Graves
Rapid Withdrawal
Pen Is Out
#122 - 2014-03-07 19:47:32 UTC
Pud Li
Doomheim
#123 - 2014-03-07 20:31:17 UTC
CCP karkur wrote:
Amarisen Gream wrote:
I hope this isn't to late:

CCP Karkur and CCP Punkturis

Is it possible to add a column "watch list" style column to the overview.
Pros: Easier for logistic ships to see who or what needs healing. Would also reduce the number of windows on a persons screen.
Cons: Might be to easy for logistics to see peoples health. If it displays the health for everything on grid, could be a lot of information, so would need options to limit which groups are shown.
It's very expensive to send information about everyone's health to everyone on the grid and is not something we could now easily do without a risking performance. The watchlist only had max 10 people until 2 or so years ago because of that.


Could you amplify on that a bit? I assume that by performance you mean data rate from server to client -- And that real difficulty is staying within the download capabilities of 56K telephone modems. It seems to me that improved overviews are easily possible if coded smartly .

IdeaIdeaIdea Update only those health percentages that change and maybe limit the maximum rate of updates.

Server CPU load impact should be null given that the server processing fleet battles MUST already handle all health of ship on grid for fleet combat reasons. Plus the trivial CPU load for data transmission to clients task seems ideal for offload to separate process (and associated hardware) that simply pulls "public" grid data from the semiconductor data base grid objects and sends it to clients that are members of that grid. Cannot be client performance either given that overview processing is nonexistent compared to graphical and other UI computational tasks.

So it seems to me that in crudest terms you are talking about the impact of adding 6 health data fields for each ship to the client update stream (current and maximum health) As things stand now a brute force coding solution would require 2 bytes of data per field for ships with less than 64K real hits in shields, armor, and structure and 3 bytes to handle capitals etc with up to 16M real hits. (if you have absolute hits, clients could handle computing display in ehp terms relative to their current ammo loads if desired assuming you also transmitted resists). Updated continuously at maximum overview refresh rate this could be an enormous increase in data rates outbound from EVE servers to clients.

IdeaHowever brute force is very pessimistic. While the 56K data rate would be crossed it need not be enormously so. So Health in the overview might simply be a feature that is not available to people with older type internet connections (mainly remote-rural environment people or those on budget). Allowing a functional but downgraded experience for those with lesser equipment is a long established EVE tradition that allows the mainstream EVE group to move forward. I do understand that such increased data rates does affect the CCP expense (data transmission costs) vs profit model. So marketing effects vs existing and potential customers is the key consideration.


IdeaThe brute force rate can be cut in half by caching maximum health stats for each ship on grid - only requiring updates only if modules change offline/online status or somehow are destroyed prior to ship destruction. Current health can also be cached until it changes ...a relatively small percentage of ship are under fire at any given moment when there is good fleet control with FC primaries. Additionally the rate of health status updates should probably be limited - probably to once per 0.5 second at CCP maximum or whatever the normal overview rate is (actually that should be user controlled within a 0.5-3 second range so that its readable and not a blur). Clients could specify even lower rates of update based upon their connection speeds and user preferences. The length of current health fields can be shortened to the number of bits needed based on maximum health or compressed. Absolute hits for maximum health can be standardized to ship type is extenders and plates effects are handled like resistance modules and bulkheads (structure improvement modules) ...percentage effect on base hull points. Thus hull type already transmitted to overview would cover maximum health points and server would compute current health from damages after all percentage adjustments.

Idea Finally there is a big question as to whether percentages or absolute hits for other ships should be available. I think percentages of health (three 7 bit fields) should be the standard available for ships that cannot be in your watchlist -- unless you have a ship scanner locked on that specific ship.

As a player I can see that providing absolute hits without a ship scanner would be a tremendous GIFT to pirates and killmail whores. Just sort by total hits remaining and start shooting. The only thing better would be to be able to select auto-targeting behavior to shoot ships based on hits remaining in ascending order.
Pud Li
Doomheim
#124 - 2014-03-07 21:00:31 UTC  |  Edited by: Pud Li
CCP karkur wrote:
Amarisen Gream wrote:
I hope this isn't to late:

CCP Karkur and CCP Punkturis

Is it possible to add a column "watch list" style column to the overview.
Pros: Easier for logistic ships to see who or what needs healing. Would also reduce the number of windows on a persons screen.
Cons: Might be to easy for logistics to see peoples health. If it displays the health for everything on grid, could be a lot of information, so would need options to limit which groups are shown.
It's very expensive to send information about everyone's health to everyone on the grid and is not something we could now easily do without a risking performance. The watchlist only had max 10 people until 2 or so years ago because of that.


Overall my guess is that any change that increases demand for continual data updates runs into TWO problems. (I cannot see this as a true CPU load question as all the data is already required for resolving grid battles -- only transmission to requesting clients is required)

The lesser problem is bumping off users with old fashion 56K modems. EVE is at times fairly close to the maximum download rate that can be sustained (actually more like 28.8K due to varying line quality). This might be acceptable If the feature can be made optional to functional play (normally low impact or there is a easy work around like following FC commands instead of cherry picking your own targets).

The BIGGER long term practical problem is that data increases impact fixed CCP operational costs for data connections. In poor economic performance times CCP can delay software and hardware upgrades and expansion. But CCP MUST pay its data costs for the game to continue.

So features resulting in increased data expenses can be justified in only two ways -- increased player fees or as part of marketing expenses, that is attracting or holding significantly more players (i.e. better volume business). Unfortunately increases to data rate useage from the standard UI setup (e.g. overview and other normally constantly open features) are the hardest to justify without player fee increases. Features that demand high rate increases but only at rare moments (e.g. download ship data for new ship type) are much easier to justify as marketing expenses as they average out to near zero data rate increase over a month. Plus if necessary CCP can cut expenses by ceasing new use of those momentary features without impacting the EVE UI user experience.

So I really cannot see CCP improving the interactive dynamic client display features until world data cost decrease significantly. But I can see more and more elaborate pre-programmed graphic objects and effects on screen (fixed sequences the client can display based on previous one time downloads). Perhaps the number of options and operational features of EVE ships can increase as long as the data interchange boils down to the same number of bytes for commands and to kick off showing end effects.
Jinn Aideron
#125 - 2014-03-07 23:00:05 UTC  |  Edited by: Jinn Aideron
Pud Li wrote:
... expensive...
It'd remain a greater than linear impact anywhere it'd have to pass-thru.

Stealth deletes are bad.

Amarisen Gream
Pleasant Peninsula Productions
Digital Vendetta
#126 - 2014-03-08 15:39:27 UTC
Pud Li wrote:
CCP karkur wrote:
Amarisen Gream wrote:
I hope this isn't to late:

CCP Karkur and CCP Punkturis

Is it possible to add a column "watch list" style column to the overview.
Pros: Easier for logistic ships to see who or what needs healing. Would also reduce the number of windows on a persons screen.
Cons: Might be to easy for logistics to see peoples health. If it displays the health for everything on grid, could be a lot of information, so would need options to limit which groups are shown.
It's very expensive to send information about everyone's health to everyone on the grid and is not something we could now easily do without a risking performance. The watchlist only had max 10 people until 2 or so years ago because of that.


Overall my guess is that any change that increases demand for continual data updates runs into TWO problems. (I cannot see this as a true CPU load question as all the data is already required for resolving grid battles -- only transmission to requesting clients is required)

The lesser problem is bumping off users with old fashion 56K modems. EVE is at times fairly close to the maximum download rate that can be sustained (actually more like 28.8K due to varying line quality). This might be acceptable If the feature can be made optional to functional play (normally low impact or there is a easy work around like following FC commands instead of cherry picking your own targets).

The BIGGER long term practical problem is that data increases impact fixed CCP operational costs for data connections. In poor economic performance times CCP can delay software and hardware upgrades and expansion. But CCP MUST pay its data costs for the game to continue.

So features resulting in increased data expenses can be justified in only two ways -- increased player fees or as part of marketing expenses, that is attracting or holding significantly more players (i.e. better volume business). Unfortunately increases to data rate useage from the standard UI setup (e.g. overview and other normally constantly open features) are the hardest to justify without player fee increases. Features that demand high rate increases but only at rare moments (e.g. download ship data for new ship type) are much easier to justify as marketing expenses as they average out to near zero data rate increase over a month. Plus if necessary CCP can cut expenses by ceasing new use of those momentary features without impacting the EVE UI user experience.

So I really cannot see CCP improving the interactive dynamic client display features until world data cost decrease significantly. But I can see more and more elaborate pre-programmed graphic objects and effects on screen (fixed sequences the client can display based on previous one time downloads). Perhaps the number of options and operational features of EVE ships can increase as long as the data interchange boils down to the same number of bytes for commands and to kick off showing end effects.



I didn't even realize how much this short request had continued on. I am grateful for all the feed back. Now, I'm not the smartest rock in the box. But if I understand 1.2, CCP had the players download most of the DB right to our computers, where it used to be handled via the server (right/wrong) This would have decreased their effective internet footprint. The other option would be to remove the "watch list" window and integrate it to the Overview, but limit to the ships you selected in fleet or default it to your squad/wing. This would limit it to say ether 10 or 50 (current is 15). I'm sure some of those drone fleets are more intensive for data cost than this would be if properly limited.

Anyway > I feel the feedback is great, and maybe will inspire CCP to try some new things.

Plus, for some reason CCP Karkur and Punkturis just make me feel all warm and fuzzy inside, unlike some of the other Devs who just **** me off with ideas, which i would relate to a bake sell, but with all the baked goods still in their most basic form. i.e. flour, salt. water etc.

"The Lord loosed upon them his fierce anger All of his fury and rage. He dispatched against them a band of Avenging Angels" - The Scriptures, Book II, Apocalypse 10:1

#NPCLivesMatter #Freetheboobs

Jinn Aideron
#127 - 2014-03-08 17:24:50 UTC
@Amarisen Gream: Take this illustration:
You have a room. And every person in this room shakes hands with everybody else. For starters, there are only 2 people. Then 10. Then maybe 100. -- Now compare the amount of extra work imposed by sending in 1 additional person at a) 2 people inside, and at b) 100 people inside.

It's in the nature of the problem itself that for every new person the amount of total work goes up ever so much faster. You can, and people do, categorize problems by how they behave in this manner (for increasing numbers e.g.). In this case, it behaves badly. Smile

If everyone had only to shake hands with bride and groom at the doorway, it were quite different. Can you see it? A different category of problem, so to speak.

Naturally, there are many other considerations on top of this. What if your room only holds so many people? If you can then do the maximum number of handshakes in an acceptable time, that could be fine. For now. Next year, you are going to invite more people though (allow larger fleets or any other kind of extension), and this concession will come back with a vengeance!

The above is one of a number of things that could make this change expensive. Something that scales up badly is something to be very wary about. You cannot get passed the fundamental problem that every new piece of information here needs to be relayed to everybody else that came before. Add to that all the aggravating implementation specific caveats that are going to punch you in the face if you try regardless.

---
Amarison Gream wrote:
Plus, for some reason CCP Karkur and Punkturis just make me feel all warm and fuzzy inside,
Because they are nice people; and you haven't yet had a chance to realize the other devs are too.

Stealth deletes are bad.

Amarisen Gream
Pleasant Peninsula Productions
Digital Vendetta
#128 - 2014-03-08 23:09:47 UTC
Jinn Aideron wrote:
@Amarisen Gream: Take this illustration:
You have a room. And every person in this room shakes hands with everybody else. For starters, there are only 2 people. Then 10. Then maybe 100. -- Now compare the amount of extra work imposed by sending in 1 additional person at a) 2 people inside, and at b) 100 people inside.

It's in the nature of the problem itself that for every new person the amount of total work goes up ever so much faster. You can, and people do, categorize problems by how they behave in this manner (for increasing numbers e.g.). In this case, it behaves badly. Smile

If everyone had only to shake hands with bride and groom at the doorway, it were quite different. Can you see it? A different category of problem, so to speak.

Naturally, there are many other considerations on top of this. What if your room only holds so many people? If you can then do the maximum number of handshakes in an acceptable time, that could be fine. For now. Next year, you are going to invite more people though (allow larger fleets or any other kind of extension), and this concession will come back with a vengeance!

The above is one of a number of things that could make this change expensive. Something that scales up badly is something to be very wary about. You cannot get passed the fundamental problem that every new piece of information here needs to be relayed to everybody else that came before. Add to that all the aggravating implementation specific caveats that are going to punch you in the face if you try regardless.

---
Amarison Gream wrote:
Plus, for some reason CCP Karkur and Punkturis just make me feel all warm and fuzzy inside,
Because they are nice people; and you haven't yet had a chance to realize the other devs are too.



I know what you mean by all the hand shaking. The more people the more shaking.
I'm not a person you likes to say "Okay, you can't do it. thats fine"
I understand the cost both in hardware, data, and $.
My thing is. I don't stand for any excuses of saying "We can't do this!"
I am fine when the Devs go "We like your idea, but with the current way the game works, its impossible."

I played WoW for 5+ years. I enjoyed the game. I hadn't used the default UI in like 3 years. All the UI that was default felt bulky and a massive waste of space. + many of the features the players (from what I felt), the response was. "We can't do that. It's impossible." And nothing more. Then 6 months, a year, 2 years later. They are adding those things to the game.

CCPs Devs are at least nice enough to talk back and explain the whys and the why nots...

+ your right about me not knowing the other ones as well yet! I'm just a little upset at the "greedy" method of the new pilot paint program. Then again I shouldn't, b/c it seems to be a move for more novelty items, which I enjoy, but don't have the funds to spend on them.

"The Lord loosed upon them his fierce anger All of his fury and rage. He dispatched against them a band of Avenging Angels" - The Scriptures, Book II, Apocalypse 10:1

#NPCLivesMatter #Freetheboobs

Jinn Aideron
#129 - 2014-03-09 13:35:09 UTC  |  Edited by: Jinn Aideron
@Amarisen Gream:
It's not only more shaking, it's the difference between the blue plot and the other for increasing player numbers. Proposed change being the blue: It just explodes the higher you go, doesn't grow controllably.

If you look at this from a cost benefit perspective (and I don't even mean money here, just costs the game vs benefits the game), there are changes that demand a lot of concessions from other parts of the game, e.g. network and cpu resources, to make them happen, and other changes that just don't. I'm certain you can agree that the first would've to be a very helpful change to justify itself, while the latter, because it doesn't cost a lot, maybe just needs to be ok.

The fundamental properties of the 'send everyone's health to everyone else' make it an expensive change. That is all what was stated in this thread by a dev.

If this one was to make or break a game, it would happen, even though expensive! But if this one is a convenience change, with the potential to break the game for very many people because of lag, network failures, and node crashes, it probably shouldn't, no?

At its heart doing this type of thing is costly because of the way it behaves when scaling up, no matter which game, no matter which application, no matter the current codebase. As such I don't think you can suggest anyone is 'not looking beyond the current state of code, just because we are stuck in this way of thinking'. That would be a little unfair. Smile

Maybe there is something similar that could be done instead without being quite as resource hungry?

Stealth deletes are bad.

Strockhov
The Shire
#130 - 2014-05-19 16:26:57 UTC
Suggestion: Add right click menu option to move multiple bookmarks to a folder.
Keywords: ui, bookmarks
Note: When bookmarks is selected in places, add a right click menu option to move all to a folder.