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

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

EVE Information Portal

 
  • Topic is locked indefinitely.
 

New dev blog: Your EVE client needs YOU!

First post First post
Author
Star Nove
Brutor Tribe
Minmatar Republic
#281 - 2012-01-24 12:14:36 UTC
As some people above have no doubt mentioned (i've not read the whole thread apologies if this is a dupe..) Titan Bridging is a nightmare.. An idea to improve that and perhaps improve the gameplay/realism of Eve as follows.


Make Mass have an impact on Jumping time.. Whether it's a jump bridge, a stargate or a titan/blops bridge. Add a timer to it that says for every X amount of mass add N milliseconds per LY of the Jump multiplied by the amount of other people using the same gate/bridge at the same time....

This way. when you do a titan bridge not everyone will hit jump at the same time. The system would be throwing small ships in first (battlecruisers logi's etc) with the Battleships following a few seconds later.. It woujld help us as the players have a better experience when bridging and help your servers cope by staggering the arrival of a load of new players on a new node..

For regular stargate travel, it will make a little more exciting if you are in a BS being chased by small ships and it takes you 2 seconds longer to travel from one constellation to the next and even longer from one region to the next...

You could maybe even then allow (non super) capital ships to use stargates in the future safe in the knowledge that it would probably take 10 minutes to get from one system to another that way and the more they jump through, the longer it will take... Obviously concord would deny them access to high sec . Whilst it would make it possible to get caps into a jammed system in nullsec you'd at least (with good intel) know they were coming and be able to defend...!
Cherry Stripe
Native Freshfood
Minmatar Republic
#282 - 2012-01-24 13:00:26 UTC
search function for evemail.

sorry if dupe couldn't stand everyone complaining about 5 seconds of lag...
Scrapyard Bob
EVE University
Ivy League
#283 - 2012-01-24 14:02:34 UTC
Cherry Stripe wrote:
search function for evemail.


Ah, that reminds me - more UI elements which present lists should have the little "filter" box like containers have.

- EVE Mail, let the little filter box quickly search subject lines & sender name, so it allows you to quickly filter down to just EVE mails from a particular person.

- People & Places, let me quickly filter contacts based on corp name, alliance name or player name. Same thing with agents. Bookmarks would need to be filterable based on either region / constellation / system or bookmark name.

- Science & Industry - Jobs List - quick filter on either the system, character, or item being produced name.

- S&I - Blueprints / Corp Blueprints - quick filter on the blueprint name

Pilk
Evolution
Northern Coalition.
#284 - 2012-01-24 14:08:12 UTC
Gilbaron wrote:
it takes several minutes to load ~250 bms from a container and move them to my own BMs

Can we move bookmarks fully client-side, albeit with a server-generated salted hash to guarantee authenticity? This would mean you can copy tens of thousands of bookmarks trivially from client to client, with zero load on the server. The hash, meanwhile, prevents someone from editing a bookmark's location and trying to use that; an edited bookmark wouldn't match its hash. This also allows some cool things like client-side programs to mass-rename or folder-ize bookmarks according to their properties. It also optionally allows all of your alts on a given account, regardless of corporation, alliance, etc., to share the same set of bookmarks.

To answer some likely responses:

  1. Under this proposal, it is not possible to create deep safes or similar actions simply by firing up a hex editor; even if given the complete hashing algorithm, without the server's secret salt, nobody can create or edit bookmarks outside of the game.
  2. This doesn't increase load on the server to verify all the hashes; instead, only when a bookmark is used is the hash verified.
  3. Yes, this will potentially cause people to share massive numbers of bookmarks. However, unlike now, there's no server-side cost for this. And in terms of balance, this does very little that the corporation bookmarks folder didn't already do. If anything, it allows for a corp bookmark folder that's alliance-wide. However, at least in its first iteration, corp bookmarks would likely remain on the server.
  4. Creating a bookmark voucher item in-game, suitable for transfer to someone else, would be essentially unchanged. This just adds another way to move bookmarks around.
  5. Even if you disagree with moving bookmarks between characters in this way, the only change needed to prevent that would be to add the CharacterID to the hash string. Then, bookmarks are still character-locked, but are nonetheless stored client-side.


--P
Pilk
Evolution
Northern Coalition.
#285 - 2012-01-24 14:14:46 UTC
Biggest annoyance for me: the default market "Details" tab view has incorrect column sorting. It should sort in the same way as the Group tab effectively does when selecting a sell order for its immediate buy order: by price, then by number of jumps, so that the lowest-priced item in the same station shows up first, even if there's an even lower-priced item ten jumps away. Buy orders would ideally be sorted by applicability, then by price, descending, but since there's not currently an applicability column (that is, a column that has a 1 if the buy order matches your current station and a 0 if it does not), simply by price would be an improvement over the current default.

Regardless, the idea is that, in most circumstances, the top order in each half of the details screen should be the one to which you are likely to sell or from which you are likely to buy--PoLA.

--P
Atum
Eclipse Industrials
Quantum Forge
#286 - 2012-01-24 14:49:36 UTC  |  Edited by: Atum
Star Nove wrote:
As some people above have no doubt mentioned (i've not read the whole thread apologies if this is a dupe..) Titan Bridging is a nightmare.. An idea to improve that and perhaps improve the gameplay/realism of Eve as follows.


Make Mass have an impact on Jumping time.. Whether it's a jump bridge, a stargate or a titan/blops bridge. Add a timer to it that says for every X amount of mass add N milliseconds per LY of the Jump multiplied by the amount of other people using the same gate/bridge at the same time....

This way. when you do a titan bridge not everyone will hit jump at the same time. The system would be throwing small ships in first (battlecruisers logi's etc) with the Battleships following a few seconds later.. It woujld help us as the players have a better experience when bridging and help your servers cope by staggering the arrival of a load of new players on a new node..

For regular stargate travel, it will make a little more exciting if you are in a BS being chased by small ships and it takes you 2 seconds longer to travel from one constellation to the next and even longer from one region to the next...

You could maybe even then allow (non super) capital ships to use stargates in the future safe in the knowledge that it would probably take 10 minutes to get from one system to another that way and the more they jump through, the longer it will take... Obviously concord would deny them access to high sec . Whilst it would make it possible to get caps into a jammed system in nullsec you'd at least (with good intel) know they were coming and be able to defend...!

A curious idea, possibly worthy of future consideration. However, I shudder to think what it would mean for career freighter pilots. It's bad enough already just waiting for the bastards to align and enter warp, but to add additional time delays while jumping between gates? ::cringe::
Witchking Angmar
Perkele.
#287 - 2012-01-24 15:47:16 UTC  |  Edited by: Witchking Angmar
When you forget your probes somewhere and when you finally realize 7 of your probes are missing you go back to the previous system you were in, try to reconnect, nothing happens because you're actually in the wrong system, then the reconnect button becomes greyed out and you can't get your probes back.

Edit: Also, for the love of god fix not being able to warp to things that are over 150km away. Bookmarks off gates for example.
Syratus
BioHazard International
#288 - 2012-01-24 18:10:18 UTC  |  Edited by: Syratus
Giving people different options to overheat is obviously a good idea - but sometimes lag is your enemy when you want to overheat a module and instantly use it, too. It results in you overheating a module (e.g. Shift+F1), directly followed by activation of the mod (e.g. F1), to see then... that the mod is either active, but non-overheated, or the other way round.

Thus, it would be great if you could assign a key/key+click combination that will overheat and instantly activate a module, too. Or remove the lag, but I assume it's not that easy ;)
Gorongo Frostfyr
#289 - 2012-01-24 20:37:35 UTC  |  Edited by: Gorongo Frostfyr
CCP Masheen
C C P
C C P Alliance
#290 - 2012-01-25 16:34:24 UTC
We've been watching this thread closely and have extracted the issues which have been reported. These issues have been filtered and are currently being tested and prioritised by CCP TomB, CCP Highlander and myself.

Some of the pressing issues that you have reported will be tackled by EVE teams such as the illustrious Team Gridlock. If you read the original Devblog carefully you may see that we were looking for a fairly specific type of performance issue, this was to help give Team Gridlock and other devs a big hint as to where they next needed to look in order to make your client run smoother than a cashmere codpiece!

However... a lot of issues reported in this thread did not fit Team Gridlock's mission or capabilities. Fear not! this is totally cool with us and we are working to distribute those issues to Feature or Foundation teams.

Thanks for participating spacebro's as your reports have helped us give our new mission a rocking kickstart Big smile

CCP Masheen (Team Synergy)

- EVE Online Quality Assurance -

Bloodpetal
Tir Capital Management Group
#291 - 2012-01-25 16:50:02 UTC  |  Edited by: Bloodpetal
I've been trying to think of things that are on your list of issues...


One of my corpmates reports a lot of delay when he closes a chat window out. Up to 1 second or more. Although his computer is somewhere between "Craptop" and "Laptop", it's something to look into for efficiency.

This is a good one

Here's one for you... When calculating a really long autopilot route, it will freeze. That needs to be looked into and stopped from a usability perspective. Allow me to cancel it, and maybe give me a progress bar (it should be pretty predictable to see how far the calculation is - since it's just an n-th to the power of whatever combinations there could be).


Seriously, this is the ONE

To apply to join an Alliance you have to LOAD that WHOLE alliance list and dig through and find the ONE ALLIANCE that you want out of thousands.

Seriously, this is the perfect intersection you're looking at between Performance and Interface that I think your team is supposed to handle. First of all it takes an age to load that Alliance list - and second, you need to go digging through a list of Thousands!

Whatever you choose to do to fix it... it can be many different things, please this is the one thing to fix. It makes no sense and is the kind of thing that leaves a bad taste in your mouth after you apply to an alliance because of the client.

I know this doesn't hit 300,000 users every day, but it's something that you don't forget after you've done it. A few times.


ANOTHER good one

Opening Agent Missions - I think the performance on this could be better. When I talk to an agent I get a big screen that shrinks down and then loads everything. It needs to be a smoother operation - preload it, put a "Fetching data" and then display properly. I don't know why it takes a few seconds to do this, but it can be better for sure.

Where I am.

Bloodpetal
Tir Capital Management Group
#292 - 2012-01-25 17:14:36 UTC  |  Edited by: Bloodpetal
When you dock and undock, there used to be a time and date where if you were typing in a chat buffer you wouldn't get kicked out of the chat buffer.

Now adays, when you undock you get booted from the chat buffer and have to manually go back in and select the buffer to keep typing.

Take us back to the old days of smooth operation!



At this point I'm just posting in here when I think something relevant comes up. Ugh

Where I am.

CCP Masheen
C C P
C C P Alliance
#293 - 2012-01-25 17:16:19 UTC
Bloodpetal wrote:
Seriously, this is the ONE

To apply to join an Alliance you have to LOAD that WHOLE alliance list and dig through and find the ONE ALLIANCE that you want out of thousands.

Seriously, this is the perfect intersection you're looking at between Performance and Interface that I think your team is supposed to handle. First of all it takes an age to load that Alliance list - and second, you need to go digging through a list of Thousands!

Whatever you choose to do to fix it... it can be many different things, please this is the one thing to fix. It makes no sense and is the kind of thing that leaves a bad taste in your mouth after you apply to an alliance because of the client.

I know this doesn't hit 300,000 users every day, but it's something that you don't forget after you've done it. A few times.


ANOTHER good one

Opening Agent Missions - I think the performance on this could be better. When I talk to an agent I get a big screen that shrinks down and then loads everything. It needs to be a smoother operation - preload it, put a "Fetching data" and then display properly. I don't know why it takes a few seconds to do this, but it can be better for sure.


I like and agree with you on the alliance joining, this is clearly from a time before usability and I can think of a couple ways in which we can handle this better. I see what you mean about the agent convo loading up. Once we have established with UI Design a standard for loading notification we can consider extending it to UI windows such as this.

- EVE Online Quality Assurance -

Bloodpetal
Tir Capital Management Group
#294 - 2012-01-25 17:37:15 UTC


Bear for being a cool CCPer.

Where I am.

Liu Ellens
Sebiestor Tribe
Minmatar Republic
#295 - 2012-01-25 18:02:46 UTC
Have a station vault (or similar) and more than a handful items in it (30 should be enough). Select them. Press the mouse button for the context menu. Wait many (many!) seconds. Context menu finally shows up and includes the sought after "lock" or "unlock" menu items.

And that on a AMD Phenom II X6 3.2 GHz, 16GB RAM, Win7

Is the context menu running a query to the server for each one of these items whether it is locked, to provide a (to me absolutely unclear) number in the brackets after the lock/unlock menu items?

Well, they oughta know what to do with them hogs out there for shure.

Bienator II
madmen of the skies
#296 - 2012-01-25 18:14:00 UTC
what would be quite epic if you could collapse the windows with a single click on the window titlebar (or a small dedicated arrow button). Expand already works with a single click

Of course you would have to make that configurable to defend yourself from bittervet troll terrorist style forum warefare.

how to fix eve: 1) remove ECM 2) rename dampeners to ECM 3) add new anti-drone ewar for caldari 4) give offgrid boosters ongrid combat value

mkint
#297 - 2012-01-25 18:44:05 UTC
CCP Masheen wrote:
Bloodpetal wrote:
Seriously, this is the ONE

To apply to join an Alliance you have to LOAD that WHOLE alliance list and dig through and find the ONE ALLIANCE that you want out of thousands.

Seriously, this is the perfect intersection you're looking at between Performance and Interface that I think your team is supposed to handle. First of all it takes an age to load that Alliance list - and second, you need to go digging through a list of Thousands!

Whatever you choose to do to fix it... it can be many different things, please this is the one thing to fix. It makes no sense and is the kind of thing that leaves a bad taste in your mouth after you apply to an alliance because of the client.

I know this doesn't hit 300,000 users every day, but it's something that you don't forget after you've done it. A few times.


ANOTHER good one

Opening Agent Missions - I think the performance on this could be better. When I talk to an agent I get a big screen that shrinks down and then loads everything. It needs to be a smoother operation - preload it, put a "Fetching data" and then display properly. I don't know why it takes a few seconds to do this, but it can be better for sure.


I like and agree with you on the alliance joining, this is clearly from a time before usability and I can think of a couple ways in which we can handle this better. I see what you mean about the agent convo loading up. Once we have established with UI Design a standard for loading notification we can consider extending it to UI windows such as this.

I'm not sure why ALL the UI has loading issues. It's freakin' 2 freakin' D. 2D computer graphics wer mastered in the 1980's. At least by the rest of the industry. Seriously... it's not an issue of needing "loading notification" it's an issue of the software being bad.

Maxim 6. If violence wasn’t your last resort, you failed to resort to enough of it.

Camios
Sebiestor Tribe
Minmatar Republic
#298 - 2012-01-25 19:33:24 UTC
I really don't care if I have to wait 3 seconds to load market data, or to look into a cargohold.
I care about seconds when I'm being shot by someone else.


Example: in some situations the overview does update too slowly. Think of orbiting an hurricane manually with an interceptor. You want to keep your distance beyond 13 km but you don't want to go far away because he'll track you better. When doing such things, I keep an eye on distance, angular and radial velocity and his speed but those data aren't reliable since they are updated once every second (or less but anyway it's too slow). That's really painful and can get you killed; things are even worse if you are trying to kite a fast ship.

Possibly physical data should be fetched by the instance of Destiny that is running on my computer, at a rate that I can set (in small gang/solo situation I need really fast update, while on big engagements there's little point in this).
I would like to see digits moving fast like in the locking timer, changing fluidly.

On a side note: in such situations I should even be able not to look at the overview, and have ALL the relevant combat data in a little zone of the screen, or have that data in a bigger, easier to read format).
Bloodpetal
Tir Capital Management Group
#299 - 2012-01-25 20:58:40 UTC

I agree that anything that helps the overview run smoother.

As a PVP Pilot I actually tell myself i'm 1-2km "ahead" of where I'm being told I am, both for reaction time but also because the overview update isn't very accurate in those situations.




Camios wrote:
I really don't care if I have to wait 3 seconds to load market data, or to look into a cargohold.
I care about seconds when I'm being shot by someone else.


Example: in some situations the overview does update too slowly. Think of orbiting an hurricane manually with an interceptor. You want to keep your distance beyond 13 km but you don't want to go far away because he'll track you better. When doing such things, I keep an eye on distance, angular and radial velocity and his speed but those data aren't reliable since they are updated once every second (or less but anyway it's too slow). That's really painful and can get you killed; things are even worse if you are trying to kite a fast ship.

Possibly physical data should be fetched by the instance of Destiny that is running on my computer, at a rate that I can set (in small gang/solo situation I need really fast update, while on big engagements there's little point in this).
I would like to see digits moving fast like in the locking timer, changing fluidly.

On a side note: in such situations I should even be able not to look at the overview, and have ALL the relevant combat data in a little zone of the screen, or have that data in a bigger, easier to read format).

Where I am.

Riffix
Synergistic Arbitrage
#300 - 2012-01-25 23:32:10 UTC
Apologies for being late to the party in this thread.

A lot of people have asked for ways to export settings to files for consistency across multiple clients, but I feel like there is a better solution.

I'd really rather ANYTHING that is a user-configured setting be stored server-side with a local cache. You log in, client checks local settings file modify date against server file date, if client is not up to date it downloads file and uses. Anytime settings are saved out, write to cache and server.

Can anyone tell me why this wouldn't be the best/easiest/most user-friendly thing to do? What?

Lead, Follow, or Get the #@$!@ Out of the Way.