[Enzo Ildari]

Citation :

Ce n'est toujours pas un exploit.
Par contre ça a toujours été reconnu par CCP comme une utilisation non-prévue d'un mécanisme sans pour autant sanctionner son utilisation. Ils ont mis longtemps à corriger cela (très certainement parce que ça n'a jamais atteint auparavant le haut de la To Do List), comprendre faire en sorte que ça ne soit plus possible de détourner le mécanisme.
Vu que certains bug ou mécanismes foireux sont là depuis des années au final quand on en corrige un ça peut passer pour un nerf (d'où le nom du DevBlog à mon avis) vu que c'est devenu pour les joueurs un mécanisme "légitime".

Si je résume bien :

- Ce n'est pas un exploit.
- C'est une utilisation non-prévue du point de vue de CCP.
- CCP corrige afin "que ça ne soit plus possible de détourner le mécanisme" (autrement dit c'est la définition d'un exploit soit-dit en passant).
- Vu que certains bugs foireux sont là depuis des années, c'est devenu légitime comme mécanisme pour les joueurs.

Mon point du vue ?

- C'est un exploit.
- CCP aurait-du sanctionner et corriger bien plus tôt.

Bonne chose donc.

[Eored]

On refait le coup de la feature qui est un bug exploit tout en étant unfair?

J'espère que les ajustements ne concerneront que les déplacements des items/vaisseaux à la distance limite.

[Kuldar]

Dans le genre mécanisme utilisé d'une manière extrême je préférais le PoS-bowling. Plus spectaculaire.

[Ethann F.]

Cool, 300 gus dans un système non renforcé seront maintenant complètement intouchables, merci CCP.

Ils sont complètement à l'ouest.

[Johnny Baby]

Citation :

Publié par Ethann F.

Cool, 300 gus dans un système non renforcé seront maintenant complètement intouchables, merci CCP.

Ils sont complètement à l'ouest.

Mais cette mesure fait peut être justement parti du "patch antilag" sur lequel ils taffent depuis un moment.

Mettre une limite de taille sur un système permettra surement de mieux combattre / étudier le lag à l'intérieur de celui-ci.

Si après cela le lag est toujours aussi infâme dès qu'on dépasse 300 joueurs dans un système, on pourra leur cracher joyeusement à la figure .

Mais pour l'instant, "wait & see" avant de montrer les dents Il faut bien qu'ils mettent en place des actions pour régler le problème !

[Tessen]

La base du problème n'est elle pas due à une faille dans le client ?
A savoir la façon dont sont fait ces Deep Safe.
Si la manière de gérer un warp d'urgence n'était pas foireuse, il ne serait pas possible de créer des deep aussi "facilement".

CCP n'a jamais prévu qu'il soit possible de créer des Deep car aucune mécanique du jeu n'est prévue pour : c'est seulement l'exploitation d'une faille qui le permet.

Perso, je pense également, qu'il s'agisse d'une technique non prévue qui permet de prendre un avantage sur ses adversaires sans contre mesure possible.
En ce sens, c'est un exploit ou au minimum quelque chose qui doit être corrigé.

Et ce n'est pas parce que des joueurs ont pris l'habitude de l'utiliser à grande échelle qu'on ne devrait pas le supprimer.
CCP à toujours eut une politique de tolérance (ou d'aveuglement volontaire) tant qu'un exploit reste cantonné à quelques uns : ont laisse faire. Mais dès que cela commence à s'étendre à grande échelle, CCP corrige.
A mon avis, la politique est bonne car cela laisse un certain degré de liberté aux joueurs qui se creusent la tête à trouver des failles dans le jeu. CCP fait ce ces joueurs des bugs hunters involontaire.
Il en a toujours été ainsi exemple : les POS de minage sans fin qui ont subsisté pendant des années tant que cela restait à petite échelle mais qui se sont pris un ban sans merci quand le phénomène s'est répandu à grande échelle au point de déséquilibrer le market.

Exploit => sanction

Planquer son Titan sans alt sans risque de le perdre = exploit => sanction (destruction)
Moi je trouve ça normal. Après tout, rien n'empêche ce vaisseau de succomber au vent solaire ou une "catastrophe" sidérale qui provoquerait la perte du matériel.

Si CCP agit maintenant, c'est sûrement qu'ils estiment que les Deep ont un impacte néfaste sur le game play. Et que ce qui avant avait un impact négligeable n'est à ce jour plus aussi anodin.

[Kuldar]

Sincèrement, je pense que ce changement est juste arrivé en haut de la liste des trucs à modifier.

[Elm'o]

Solution toute bête : Mettre des limites aux systèmes du style :

Limite = Rayon soleil-objet le plus éloigné x2.

Ça laisse le loisir de faire des deepsafe, mais les deepsafe sont plus du tout aussi profonds.


Nan parce que la méthode de deepsafe, si elle est virée, autant virer aussi toutes les méthodes liées au logoff.
Du style jump a une gate et logoff derrière, logoff en plein warp quand on voit un campgate au scan, faire jumper un cap et logoff pour le rendre invulnérable etc. etc.

Il y a tellement d'abus liés au logoff que ne virer que celui ci, alors qu'il a une utilité de régulation du lag et laisser les autres c'est du bon foutage de gueule..

[Eored]

le logoff pendant le warp a déjà été modifié, maintenant on arrivera à la destination prévue à la reco.

[Kuldar]

Le changement du logoff:

Citation :

Your ship will warp to where it was warping to and then do an emergency warp from there.

Ceux qui ne seront pas au courant du changement vont avoir une surprise en croyant éviter un camp en se déconnectant.

[Greldi]

ce qu'il veut dire c'est que les DSS permettent actuellement a des envahisseurs d'apporter une fleet dans un systeme sans se faire oneshot au pop par les 300+ campeurs.

ce qui quelquepart permet +de fun.

mais comme c'est assez lame d'avoir autant de temps et de personnes qu'on veut dans un pt éloigné du systeme sans que la défense puisse localiser ou aie le temps de warper.
c'est comme si les alliés avaient débarqué en normandie avec les champs de force de starwars, pas cool pour la défense !

Il est donc normal de retirer ces dss...
avec des cyno cloak, des cyno normaux et des titans on peut déja faire jumper du monde derrière les défenses, sauf que bien sur, faudra se battre dans les premières minutes cette fois ci.


Et pour les assets, meme si l'espace est infini et qu'on concoit qu'on puisse planquer du stuff partout, c'est pas cool du tout pour les attaquants qui ont le droit a leur prix, et ca enleve pas mal d'interet aux pos, outpost et station...
donc c'est aussi normal en terme de gameplay de virer les cachettes secretes...pour les mêmes raisons que les etats font la chasse aux paradis fiscaux !

[zurtan]

Citation :

Publié par Greldi

Il est donc normal de retirer ces dss...
avec des cyno cloak, des cyno normaux et des titans on peut déja faire jumper du monde derrière les défenses, sauf que bien sur, faudra se battre dans les premières minutes cette fois ci.

Le problême n'est pas de se battre dans les premières minutes, il est que toute la flotte entrante va mettre 10+ minutes à loader le grid.

Si le lag ne s'arrange pas, on ne verras que beaucoup moins les supercaps sur le front je pense, ou alors devoir trouver d'autres moyen de pouvoir bridger in avec une certaine latence pour ne pas simplement partir au suicide dans la bonne humeur.

[Tessen]

Réduire la taille des flottes ?

Après tout il n'y a que les mega blocs qui se plaignent de lag infâme

[Selty]

Citation :

Publié par Tessen

Après tout il n'y a que les mega blocs qui se plaignent de lag infâme

Et ceux qui se retrouvent à l'autre bout de l'univers mais malheureusement apparemment sur le même node. \o/

[niahoo]

Citation :

Le problême n'est pas de se battre dans les premières minutes, il est que toute la flotte entrante va mettre 10+ minutes à loader le grid.

faudrait alors justement un champ de force à la starwars qui ne pourrait se placer que à 2 AU minimum de tout objet, activable une seule fois dans un systeme par alliance / jour et qui ne pourrait durer que 10 minutes ^..

[Rhum]

Oula ça fait pas mal de changements d'un seul coup. o_o

[Greldi]

Citation :

Publié par niahoo

faudrait alors justement un champ de force à la starwars qui ne pourrait se placer que à 2 AU minimum de tout objet, activable une seule fois dans un systeme par alliance / jour et qui ne pourrait durer que 10 minutes ^..

pas con, et ce module on le mettrait sur un mothership

[Farel]

Ca me rappelle l'une des propositions de Scagga pour le 2nd CSM : permettre le probing des ships cloakés, comme demandé par beaucoup, mais permettre aussi aux vaisseaux de devenir indétectables s'ils le souhaitent. Ceci fonctionnerait par paliers : la sensor strenght du ship baisse à chaque palier franchi. En clair, le pilote décide de désactiver l'énergie de son vaisseau et de le passer en standby. Le premier palier consisterait à désactiver les moteurs et à les faire passer à froid, ce qui demanderait par exemple une minute. Le second consisterait à désactiver l'armement, le capa et les senseurs, puis le 3e par exemple, tout l'électronique interne sauf les systèmes de survie. Plus la procédure avance, plus le ship est handicapé (plus de moteurs, puis plus de défenses, puis plus rien), mais plus il est difficile à détecter (du genre on passerait de 15 de sensor strenght à 3, puis à 0,6, puis à 0 -> division par 5 à chaque palier, par exemple). A la fin, le ship serait indétectable, au bout d'une procédure de désactivation de plusieurs minutes. Il faudrait également plusieurs minutes, peut-être même plus longtemps, pour le remettre online.

J'avais aimé l'idée. Pas forcément super utile quand on cherche juste à échapper à quelqu'un en warpant de safe en safe (même avec un ship cloaké qui serait du coup détectable quand même, même si ce serait plus difficile), mais utile quand on cherche à se planquer sous le sable. Evidemment, ça demanderait pas mal de tweak au niveau du logoff inspace.

[Irannia Amarthalion]

Ca a été modifié :

Citation :

tl;dr EVERYTHING HAS CHANGED. No more deletions! Things will be moved at some point!

So... what happened?

A defect reared its ugly head right at the end of last year, detailing a way to "overshoot" a warp, thus allowing you to travel a fairly arbitrary distance in a given direction under certain circumstances. This was fixed by software and marked for deployment in Tyrannis.

Once the actual defect was fixed, we realized that it would also make sense to clear up all the extra bookmarks created as a result of this defect - and, by the by, all the other deep safe bookmarks created by various no-longer-functional legitimate and illegitimate mechanics over the years.

The neatest solution would be to move all affected objects in a given system closer to the sun. However, EVE Development's resident DB guys were booked pretty solid for Tyrannis production, so the quickest solution was to instead make a few code changes to render deep-safe locations effectively inaccessible. Early in this process we committed to informing pilots about this as soon as possible in order to give proper prep time, which in turn focused us on finding a satisfactory solution as quickly as possible: the "quick" solution.

In the rapid process of defining this "quick" solution, we discovered a series of issues with the basic plan, which we fixed with further "quick" additions prior to writing the first blog. Player feedback to this initial bookmark blog identified further issues that we hadn't considered, which would make the "quick" solution even less quick to implement properly. We quickly decided that the "neat" solution was absolutely necessary.

To that end, one of our Ops DB guys has volunteered to find some time in his schedule to write and tune a "move script", allowing us to implement the clean solution without disrupting any of EVE Software's plans for final development of Tyrannis.

We can't 100% commit to this being tested in time for Tyrannis, but we're committing to implementing a full and proper solution on this issue: the move script will be deployed when it's ready, likely either in Tyrannis itself on May 18th, or in a release shortly afterwards.

Thanks to everyone who raised warning flags once the blog went out - we've caught our mistake with plenty of time to spare and we're implementing a better solution instead.



What's the new plan?

Here are two things that we're doing right now:

1) Getting ready to deploy the fix for the original defect with Tyrannis.

2) Testing a move script to move the old deep-safe bookmarks and all items in deep space.

The move script will locate all items (physical objects including ships, cans and structures - anything you can collide with is an item) and bookmarks that are more than 20AU further from the sun than the furthest celestial. It will then move them towards the sun until they are exactly on the 20AU boundary for that system. No physical items will be deleted. No restrictions will be made on warping, module activation etc.



If you have any further comments then, as always, please let us know in the comments thread.



The fun bit at the end

There are around 2,300 items outside the 20AU boundary
Around 60% of these items are ships
Around 25% of these ships are unpiloted
There are around 430,000 bookmarks outside the 20AU boundary
The furthest bookmark is 5,900,000,000 AU (95,000 light years) from its sun. This is roughly the same distance as the diameter of the milky way
(These statistics courtesy of Ops being awesome)

Source

[Karnac'h Ec'honder]

Rhoo mais ça va être le curée !!
Oyé Oyé ! Gros vaisseaux et matos en tout genre en libre service !!
/em va faire un contrôle technique de ses sondes.

[Farel]

Ahaha, oui, en effet. =)

Citation :

The furthest bookmark is 5,900,000,000 AU (95,000 light years) from its sun. This is roughly the same distance as the diameter of the milky way

"lul"

[Arland]

Ah oui quand même 95 000 al ! doit y avoir des trucs marrant dans celui-là

[Elm'o]

5,9b AU... Yen a un qui a légèrement abusé sur le deepsafe là...

[b_z]

Petite application numérique :

Avec un ship à 20Au/sec (covops riggée), il faut pour y arriver... 9 ans et 4 mois.

Sans compter les rades de capa x)

[LPA]

Comment que c'est possible ? Je suis même pas sur que d'un bout à l'autre de carte d'Eve il y'ai une telle distance Oo