I've checked this with Helioptris plants only: It is possible for two ppl to harvest the same plant. This shouldn't be possible because it opens the chance to gank ppl with less developed extensions.

Say a highly developed player deploys a field container next to a bunch of plants. Then because these plants are the next to a terminal/outpost, someone who just got a Laird arrives and respectfully targets a plant which the other doesn't. Chances are that the high level harvester claims these plants for himself so he starts to always target the plants which the low level harvester does. This of course to drive him away. He will eventually succeed because the high level harvester has probably double the cycle time so the low level harvester will hardly be able to fill his cargo. The situation gets even worse as groups of Helioptris plants get rare.

The problem is similar to multitagging, but the solution is different. Of course, if harvesting the same plant was impossible, the one with the lowest locking time wins. But as plants aren't being tagged, the low level harvester has a chance to lock a plant the high level player doesn't expect.

The same would apply (haven't checked this) to ore/liquid fields although it isn't that much of a problem because these fields are mostly very large. Still it is possible piss off low level players.

If this gets serious, you will have people leaving with one thing in mind: "What a *** comunity".

when i took a better look at my sequer, i noticed the cubic shaped block at it's back. the second thought i had was that this would be a nice trailer coupling. so why not add trailers instead of big haulers?

lets see, what changes/properties would be needed:

i guess there should be a new kind of slot in the bot's equip window. preferably right of the leg slots. this new slot would be the trailer coupling in which you would have to put an trailer-item. this way it would be possbile and necessary to define which bot would be able to add a trailer, because it would look ridiculous to add a sequer-sized trailer to an arkhe. i guess it would make sense to add couplings to mechs and above?

should trailers themselves have their own couplings? i'd say yes. as their weight should slow down the main bot, you won't run into having to deal with an endless train. of course the number of trailers could aswell be hard-limited by a certain number. maybe add a "drag force" like attribute to the bots so bigger bots could drag more trailers. some new extensions could be introduced to increase the drag force of a bot. if each trailer required some cpu usage of the main bot, an additional control method could be added to limit the number of trailers you can drag.

how much capacity should they have? at first glance maybe about 50U? this suggestion is due to the data consoles of level 4 transport missions that have 50U. of course there could be different kinds of trailers with different capacity: smaller ones, bigger ones, some with no engine (bigger drag) and some with an engine (lower drag). and maybe level 1 and level 2 trailer couplings? i guess the limit is your imagination.

so how should they be connected to your bot? i think a system of levers would be difficult for the graphics (movement). so i would suggest some energy connection. this could be a hint for some additional reactor usage and another control method to limit too long bot/trailer-trains.

now to the question why i would prefer trailers rather than big haulers:

i think it is a bit boring if big haulers were added. it would mean big bots with good shields and maybe some defensive weaponry. so they would be hard to kill. additionally they would require huge amounts of resources and a long time to build. trailers on the other hand would need less resources and time. and most important they add additional items to the manufacture system. so they would support crafters (diversity) more than big haulers.

there isn't much to say if you use them on the alpha islands only. the only advantage would be that you could move between the field containers and the terminals/outposts less often. as for the pvp part of the game, i think they would add some additional fun:

trailers would need to be separate entities like bots so you can destroy them separately. there should be additional entries in the landmarks? window. something like "player", "player trailer 1", "player trailer 2", ... so you can target and destroy them. it would be irritating at first if a bot/trailer-train would pass by as the landmarks window might be flooded with these entries. but this should give a good show-off-effect

as they are separate entities, the biggest weakness of these bot/trailer-trains should be the first trailer. once the first trailer is destroyed, the connection between the bot and the remaining trailers is lost so all remaining trailers should stay where they are. this way they could easily be destroyed one by one which improves the loot chance of 50% per bot. so people would have to organize some escort. maybe add some possibility to reconnect the remaining trailers?

as they would be too easy to kill, trailers should have their own reactor/cpu. and this is where it gets tricky to implement. the equip window would need some tabs for each trailer. the hp/accumulator window and the modules window would have to be extended aswell and this won't be an easy thing to do. the advantage would be to have some slots per trailer to add shields and maybe defensive weaponry. it would be so sweet to watch a line of shield bubbles to pass by. but of course it would suffice to add non-slot-trailers at first.

so what do you think?

http://img593.imageshack.us/img593/9008 … ailure.jpg

i have tried to sell a single sequer using the sell-button. i've had a packed and an unpacked sequer in my private storage. when i tried to sell one, the following message appeared: "Item has to be packed first!"

to work around this bug, i had to empty and then pack the sequer i usually use for myself.

i wasn't able to find this bug on the forums (old and new), although i know that i have posted this before in the old forums.

so we have a FPS indicator (open console and enter "showfps 2"). Maybe this should be turned on by default? In that case an additional option to show/hide the FPS indicator. That is because i don't think the console commands are published somewhere. this would help to distinguish whether one really has lag (low connection speed to the server) or if ones hardware is just too old.

i don't know how the client is implemented, but i hope that data and graphics processing is separated. if that is the case, it should be rather easy to add an option with which you can reduce the frame rate. the reason is that it makes hardly any sense to have a maximum frame rate when you are mining and almost nothing changes in your vicinity.

this could mean less electricity costs, so more to spend on perpetuum. more important is that the hardware requirements are less high so i could run two clients on the same machine without having to buy a top notch computer.

EDIT: modified so people can easily calculate their cycle time.
* Thanks to Recognizer for finding the solution *

I use a Standard small miner module (default cycle time): 18s. The cycle time according to the information window (equipped with Stermonit charges) is: 14.63s.
When mining Stermonit, I use 20 charges in approximately 292 seconds and thus the cycle time is approx 14.60s. = no problem/bug here.
With normal percentage calculation, this would be a decrease of (1 - 14.63/18) ~ 18.72%.

Now my bonuses with an effect on the cycle time of miner modules:
Argano cycle time bonus 5%
basic robotics 4 (bonus of 4*5% = 20%)
basic intensive mining 3 (bonus of 3*1% = 3%)
advanced extensive mining 0 (requires basic 4)
expert intensive mining 0 (requires advanced 5)
intensive stermonit mining 0 (requires basic 5)

What one might expect is a cycle time of 18-23% = 18*(1-0,23) = 13,86.

But as it turns out, the formula being used is as follows:
cycle-time = base-time / (1 + bonus)

e.g. cycle-time = 18 / 1.23 ~ 14.63