Those values are not computed when you change speed/direction. They are computed each time your turret fires a round. Therefore how often you change speed/direction is irrelevant, how often your turrets fire is what counts. Besides computing them is actually pretty cheap computationally.

Attributes in Perpetuum do not work the way they work(ed) in EvE. In EvE rising an attribute has a 'diminishing returns' effect. In Perpetuum it does the opposite: each new attribute point gives you more saving than the previous.

Therefore, if you are an industrial, no matter how slow your combat training is, if you were given a chance to boost an attribute, it should be your highest attribute (probably an industrial one).

Of course if they give us the possibility to boost ALL attributes, then we do want to do exactly that: boost them all. But given a limited choice, the highest one is the one to boost. Unless you know for sure you are never ever going to train anything with that attribute any more (not even the extensions that do not yet exist in the game at the moment).

Besides the fact that I play on a Mac therefore my "game folder" is nothing like what you think it is, I do not think it's the gbf file. It's not systematic. It looks pretty much like a pointer getting the wrong value.

I do suspect it to be an unrelated problem because the main crashes seem to be due to an out of memory condition while the background bug of the radar seems to be something wrong within a shader or some other GPU code. But I do not have sufficient knowledge of the game code to judge for sure.

It may or may not be related. The fact that the offered items eventually appear in the other hangar may in fact impact the ability of the code to distinguish objects that exist and those that do not.

I'm having frequent (at least once an hour) crashes. Not doing anything special: I'm a noob and have never been on any beta yet (not even on the new alfas!).

Most of the crashes happen wen zoning (docking, undocking, teleporting) or when there's a map or radar related activity (open or zoom the map or the radar).

I think that the map/radar crashes and the zoning crashes are separate problems, however.

A few times (but this happens rarely) the radar background behaves erratically. When this happens the dynamic info is allright but the background isn't. Sometimes it'all white, some other times it shows random bitmap data. Zooming out generally fixes it. But zooming back in triggers the problem again (sometimes showing different random bitmap data but eventually ending up with a white background).

Here's an example of the bugged radar showing random bitmap data as background.

It's not hard. Just not guaranteed to work.

For best chances you want to use a cheap item that has very low market activity overall and also do the trade in an off-hand station with very little market activity. Only the selling (main) character needs to be there (in fact if it has trading skills it doesn't even need to be in that station as long as the item itself is there), the trial character can be anywhere in the same region (even in space).

It is doable. But there's no guarantee it'll work as anyone could screw your trick by buying out your sell order or undercutting it. If you are trading a few hundreds of millions of isk, that's not a problem. But would you take the risk for, say, 50 billions?

The problem is if the trial is being used to launder money or do RMT. Normal gameplay within the 14 days time limit will not impact the economy. The limitations are not supposed to make money transfer impossible, just to make them slightly unreliable so that the risk is not worth it if the amount is huge.

More info, please.

As far as I understand it, it is in place, but not the way you think it is. In other words it's not based on "tracking" and the (angular) speed of the opponent.

1) we are not talking of synchronizing the game (nearly impossible due to lag and jitter), but of synchronizing clocks (possible up to the 1/2 of the systematic difference between up and down packet routing times).

2) to solve the problem the OP has seen we do not need exact synchronization. All that is needed is that the server clock on the client is guaranteed not to be ahead of the actual server clock (and this is the easiest thing to do when handling remote clocks, you do not even need a synchronization formula or protocol).

Yep. It is somewhat synchronized, but it's not über precise. Anyway as long as they change the client to update the available EPs according to the server clock and they make sure the server clock, as kept by the client, is not ahead of the real server clock things will be allright. Small differences between the server clocks of different clients are not a problem, as long as they are all are behind or identical to the real server clock.

Client lagging has nothing to do with clock drifting. Clock drifting on modern hardware should be absolutely negligible even over a long playing session. In any case it can be measured and corrected for. Also re-syncing requires such a small number of bytes on the net that they could just re-do it periodically.

Anyway I just noticed that the client actually does get the server time already, but it increments the "available" EP count on the minute of the client clock, not on the minute of the server clock, so this is actually a bug and it should be pretty easy to fix as the server clock is already available to the client.

Extra hint: intentionally offset the server clock value, as kept on the client, by one second (or a fraction thereof) and update the EP count on this offsetted clock minute instead of using the client clock as is currently the case. There'll never be this problem any more, you do not even need to care too much of precise syncing, jitter, systematic bias due to differing forward and backward routing, drifting etc. etc.

Maybe you should have done the redirect the other way around and used perpetuum.hu or perpetuum.eu as the main site.