I have noticed a common argument amongst hauler pilots and people out hunting in general, that they never have enough cargo space.

I have also noticed that there is a mod called Lightweight Frame, that lightens your bot and makes it faster (as well as make it a bit less protected).


Well, what i propose is this: a Load-Bearing Frame mod.

It would be basically the opposite of the lightweight frame in terms of function, however adding the addition of extra cargo space as a % per tier of the item. It would add mass to your bot, it could either leave hit points alone or slightly reduce them, and it would be limited to ONE per bot, like LWFs are, so that they arent "overpowered" or abusable. Like LWFs they would be leg slot items, and have roughly the same cpu and reactor usage per tier.

The design i propose (specifications flexible and open for discussion):

Cpu/Reactor usage: Same as LWF.
Armour hit points: 0-5% bonus, due to reinforcement of the bot frame (it's sturdier)
Demob resistance: 0-5% bonus, due to it being bulkier (harder to demobilise)

Slots: pasive/legs

Cargo space bonus: 5-10% depending on tier. The better engineered they are, the more you can store within your bot. (i.e. the higher tier, the better the bonus. 10% (T4) gives 24U to a lithus, and another 8 to a sequer, for example, at the cost of being slower, and a bit more succeptible to demob)

Mass specific penalty: 20%  Look at it like this; more shelving, more storage area, bulkier frames.. they're gonna add some weight.

Bonuses cannot be modified by any skill extensions.

Feel free to discuss or come up with better stat suggestions, but try to keep the criticism constructive or relevant, please smile


edit: increased mass penalty, switched demob penaly to a bonus, due to not understanding the theory behind demobilisation properly.

DEV Zoom wrote:

There will be a possible fix for the npc disconnect bug tomorrow. We're not 100% sure we have found the exact issue, but it's worth a shot.

trying something is much better to trying nothing! thanks for looking it up and trying to fix it big_smile

Mark Zima wrote:

NPC shooting disconnects look like a game bug, not a connectivity issue.
(Props to Mephiston for highlighting those "fastqueue parse errors", I never noticed them before).


should i make a seperate thread? i only put them in here because they seemed to possibly coincide with lag (because my connection is shocking), which is a connection issue

Annihilator wrote:

that robots continue cycling their modules is intentional - imagine you lose your robot because your repair module stops when you disconnect. they will stop when you log back in and get syndicate protection (i hate this btw)

Alpha strike will trigger up to 6 chance2hit calculations, and then for the succesfull ones each a seperate LoS caclulation + Damage dealt. The client needs to know about each of those steps immediately...

Nice, i thought something similar might have been the case. Glad to know i'm not totally mad and dreaming things up, and its nice to see there is an actual explanation as to what i witnessed.

As for the second part that could serve to reinforce my theory that it is simply spamming the client with instructions (los calculation, reload status, cooldowns, etc) and causing a disconnection when there is a parity error between the client and what the server expects from the client. I figure it would make sense if its effectively hitting the chassis slot all at once, rather than one command to set them all off, on top of the aforementioned calculations.

Like i said before, i'm just guessing on the possible cause, since i'm not really aware how everything works, but it seems to make sense.

I have been getting ping spikes well over 4k, an average ping of around 350-400ms, and constant disconnections during combat.

your username: Mephiston
your current IP address: 60.240.162.42
name of ISP and country: TPG Internet, Australia
the bandwidth (e.g. 15 Mbit down / 1 Mbit up): Advertised maximum: 8000kbit down / 384kbit up, Actual (see speedtest results)
the kind of service you are using: ADSL1
- the results of a recent speedtest.net run: http://www.speedtest.net/result/1492020044.png


Instead of pingplotter results, I offer a somewhat tested theory:  (SUMMARY AT THE BOTTOM)

My main issue is the constant disconnects during combat. I know that my ping is rather high, and i'm used to this, but having my bot nearly blow up a few times due to the reason i suspect is somewhat frustrating.

I began noticing a common occurrence every time i disconnected; the fact that it happend right after i hit an alpha strike (pressed spacebar) to launch all my weapons.

Now, without knowing or seeing the game code for myself, i am unable to back this up, but maybe the devs can use this information to their advantage. What i suspect, is that Alpha strike was added in to accommodate people not having to press the chassis slot buttons one at a time. For those that dont understand what im on about, each weapon slot can be fired individually (i'm sure you've all utilised it a few times, when a weapon was reloading and you needed to fire another one), and alpha strike was added in so that all available weapons can be fired at once.

How i suspect the game does this, is that it essentially presses every weapon/chassis slot button at the same time. This is opposed to the game engine being told to fire all weapon slots at once (thus avoiding the "spamming" of commands at the same time). 

I would also assume that the game has some kind of command flood prevention measures to stop people spamming or macroing high volumes of commands all at once, thus why i believe this is triggering properly, although it could also be due to the commands having a disparity between being sent from the client and being received by the server (which may be lag related)

The reason i suspect this is seemingly confirmed when i take a look at my perpetuum.log file, when i notice the following codes ALMOST IDENTIALLY surrounding a disconnection:

[11:43:05] [fastqueue] <1AD7A1E0> Parse error (command: 32)
[11:43:05] Disconnecting (reconnect: true)...
[11:43:36] Connecting...
[11:43:36] Connection successful...

and here again much later / on another day:

[14:44:36] [fastqueue] <4F1585E8> Parse error (command: 32)
[14:44:37] Disconnecting (reconnect: true)...
[14:44:43] Connecting...

And an example of everybody's favourite, the double disconnect (which was actually a triple by the looks of it):

[11:29:28] [fastqueue] <39ED29A8> Parse error (command: 32)
[11:29:30] Disconnecting (reconnect: true)...
[11:29:34] Connecting...
[11:29:34] Connection successful...
[11:29:39] Update successful...
[11:29:39] Loading layouts...
[11:29:40] Initializing sound engine...
[11:29:40] Loading dictionary...
[11:29:40] Init done...
[11:29:40] Init successful...
[11:29:40] Connection valid...
[11:30:17] [fastqueue] <27820560> Parse error (command: 32)
[11:30:17] [weather] Setting weather type 0 set to: curr: 0.687160 next: 0.745098 delay: 309847
[11:30:17] [weather] Weather variable new, adding
[11:30:17] [weather] new values: 0.687160 (0.687160) 0.745098 5080235 5390082
[11:30:19] Disconnecting (reconnect: true)...
[11:30:42] Connecting...
[11:30:42] Connection successful...
[11:30:47] Update successful...
[11:30:47] Loading layouts...
[11:30:47] Initializing sound engine...
[11:30:47] Loading dictionary...
[11:30:47] Init done...
[11:30:47] Init successful...
[11:30:47] Connection valid...
[11:31:22] [weather] Setting weather type 0 set to: curr: 0.699359 next: 0.745098 delay: 244609
[11:31:22] [weather] Weather variable new, adding
[11:31:22] [weather] new values: 0.699359 (0.699359) 0.745098 5145225 5389834
[11:31:55] [fastqueue] <27820870> Parse error (command: 32)
[11:31:56] Disconnecting (reconnect: true)...
[11:32:26] Connecting...
[11:32:27] Connection successful...

Now, regarding that last part. I'm not entirely sure why, if i am correct at all, would it continue to issue alpha strikes while it is offline. I can only surmise that it is because it has not 1) finished attacking the target, 2) has not received any further input or contact from the player and 3) the player has not timed out yet (which is the reason why we currently get the double disconnects.. the player's 'avatar' has not unloaded/pinged out from the world yet).

I noticed, however, that the bot affected does indeed continue to keep proceeding through whichever commands it was last issued earlier when i was emptying a loot can with my sequer which was parked right next to my combat robot. My combat robot then proceeded to disconnect after i had hit alpha strike, but my sequer remained connected to the game server, and i watched my bot continue to pump volley after volley of shots into the same bot, then stand around for a while while it timed out (and while i tried to reconnect), after it had destroyed its target.




For those of you who do not wish to comb through this entire post i offer you a TL;DR summary of my theory:

Lag(possibly) + Alpha Strike + the way in which the server code is written(also possibly, impossible for me to verify without looking at the game code somehow) = Game client disconnecting due to unforseen command errors, which in turn = Account taking a while to ping out, due to not being disconnected properly (which leads to the whole double / triple disconnect issue, where the game kicks you out if you try to log back in immediately).

Phew.. that was a long post. Hopefully this helps shed some light on the situation.