1

(30 replies, posted in General discussion)

Norrdec wrote:

Every internet game has ways to give the illusion that there is no lag, so there is a movement prediction done on every bot you see around. The walking in walls thing is exactly that, not sure about the jumping bot smile But yes, the latter is connected with the follower going faster. big_smile

Easier than it used to be.  Game's always had an auto-forward key, so you can use that and just steer multiple clients in a window. Until recently though, bots would stop at 'random' (lag/desync/stop running) while trying to autorun.  If you're good/on drugs, you can use autorun to drive 2 or more clients at once.  Expect that to go very wrong in a combat situation though, unless you use more drugs than I'm comfortable with. cool

My previous attempts to dualbox RR and combat have not gone well.

with careful camera rotation and clicking, you can mine under most structures no problem.  makes for a fun mining minigame xD

3

(22 replies, posted in Balancing)

I could be wrong, but I would guess that only giving the remote RR extension a bonus to rep cycle time was a conscious design decision, so as to encourage group work.

4

(1 replies, posted in Balancing)

Different nexus mods have different boosts per level, in accordance with the magnitude of the effect in game.  Considering the ammount of effect even a small speed difference makes in combat, the 0.5% I think it is per level in Nexus - Navigation you get is appropriate.

5

(26 replies, posted in Feature discussion and requests)

Adom wrote:

Not cool, since modules is only thing you afraid to lose (bot insured). I prefer to respawn at kara and equip fitted seth then running there 20min to equip something.

In this case, the idea isnt to prevent losses, its to have the ability to sacrifice modules to close speed to a target if the speed difference is low enough and you want the kill bad enough.

6

(26 replies, posted in Feature discussion and requests)

You mean such that the tradeoff is useless for its stated purpose?

edit: hurf durf, mixed threads

Anyways, I'm thinking a one-way field trade off, like being able to fit a 'jettision' system in some mod slot that enables module ejection to reduce mass.  I.e. specifically usable (while maybe not a good idea), in mid-fight.  Getting frozen doing that would just be silly I think.

7

(14 replies, posted in Balancing)

Assaults are kinda broken anyway, maybe they need their own topic?

T1 standard medium transfers are broken, or pre-nerfed, only transferring 30 instead of 200 AP, as seems to be intended from looking at the other tiers of modules.  I believe I've seen this mentioned in a post on another thread, but the stat breakage here should have its own thread for indexing purposes probably.

9

(26 replies, posted in Feature discussion and requests)

The ability to make tactical/short-term 'strategic' changes on the battlefield would be a great takeaway from this thread IMO.  As it is too many fights are determined beforehand IMO by spy work and intel management.  Thats not necessarily a bad thing, but it means most fights are won and lost before a shot is fired, sometimes even before leaving the terminal.  This does detract from the on-the-field gameplay element, I think.

Actually, give it only 1k HP, but 90-95% resists.  You want the container destructible, with time, but you want it easily RRd if someone wants it to stay alive.

You are forgetting to consider other factors in mechanical design, such as engineering for loads.  Given a sequer's visual design and stated purpose, I would expect its rated (equipment screen) performance to apply for a full cargo load, not an empty hull.  Its optimized to be a hauler, not a combat bot.  If anything, I would expect it to be *faster* than rated for an empty hull, though this would be a limited due to the tradeoffs involved in engineering and gearing a torque-heavy drivetrain to support the 80U cargo load.

12

(2 replies, posted in Resolved bugs and features)

There is a longer path accesible by assaults, at least.

Addendum to #3: This is really only an issue in conjunction with point 2.  Perhaps only allow container destruction at some interval after its deployer leaves the terrain.

Saw a very clever idea implemented today.  Park a non-flagged sequer with a field can. 
You can now kill people and be secure in the fact that you will not lose your loot, effectively allowing for PVP with no risk of loot loss.  Bonus points if you deploy the setup at a teleporter with a safezone around it.

Suggested fixes, threefold:

1. Disallow field container access if PVP flagged.  Allow an access attempt to reset the container's timer still.

2. To dissuade camping the safe zones in such a manner, have syndicate protection decay on a timer equal to the length of time it takes a disconnected bot to despawn from terrain.  If a player allows their timer to run out in such a fashon, reactivate their materialization timer.

3. Field containers need to be destructible on the beta islands.  -- there can be problems with griefing with this point, i am uncertain how to solve these.  I suppose you could give the cans a large amount of HP  (say, 10000), and/or the costs of cans should be significantly increased.

Your toughts, trolls and trollettes?

15

(49 replies, posted in Recruitment forum)

These games are awfully cutthroat, we accept that, but you can go a long way by not being a ***.

16

(62 replies, posted in General discussion)

Perhaps it hasn't affected us because we took the time to understand how the system works, as opposed to going OOH CLICKY BUTTONS BUTTONS. lol

It's just a correlation that most of those who took the time to understand the system also started a couple weeks earlier.  Correlation is not causation.

17

(41 replies, posted in Services and Discussion)

Mininum order increments are an established tenet of free markets.  Working as intended?

This tactic is a proper and established tradition of military operation.  Many (most?) SOPs specify that if you know you're ***, then to destroy everything of value that you can before you go down.  Its awfully artificial to expect that to not be the case.

If your goal is really to recover loots and mined ore, bring enough alpha to one-shot the miner/farmer.

... wine client works fine for me, dualboxing even.

make sure you emulate a desktop via wine explorer /desktop=1,1024x768 Perpetuum.exe or some such similar invocation.

20

(2 replies, posted in Feature discussion and requests)

Leave 4 digits, flag pvp on bad access.  Hilarity will ensue.

21

(10 replies, posted in Balancing)

My math is a bit wrong I suspect, but I think that means you're saying that after demob the 1000M away squad should be able to have something like an 88% speed difference to the demobbed target. 

The problem I see with this is that I think it will discourage fights, because I dont think 53 seconds will be a reasonable amount of time for a hypothetical rescue squad to deploy and get to our hypothetical demobbed guy.  I suspect such a mechanic would merely discourage small fights, as you would have to write off someone caught at any distance as a unrecoverable loss.

IMO, demobs should enable one to force commitment to a fight, but not to make it hopless to try to rescue someone thats demobbed.

As such I would propose a mechanic that results in double demob on someone thats doubleplated to result in the doubleplated fellow to be at say -30-50% speed, and not -70% speed.

In my limited experience, I would believe this to be a better balance between forcing fights and just providing gank targets.  From the PVP (very little, I admit) I've been in so far, it seems safe to say that 2-3km is a reasonable travel distance.  For 2KM, even a lightweight squad averaging 75kph (im not going to say sillyfit to 100kph even though I could see a lolintaktecm squad doing that) will take about a minute and a half to join the fight. So IMO, a time difference of 53 seconds is not enough I think.

As neoxx said, being able to fit passively to mitigate any demob attempt is kinda silly, but neither do I belive they should be something like a 'lolnano' button, for lack of a better descriptive term.  Allow demobs to force a fight, but dont make them so powerful that the plated+demobbed guy has no chance to be rescued.

Balance to encourage uncertainty, which I think encourages small group combat, and less blobban.

22

(10 replies, posted in Balancing)

Well, you already pay a speed penalty when you plate up.  The question I have is the resolution to this situation:  You are in a bot which has 2 medium plates equipped, and you get double-demobbed.  How quickly should a squad of equal-sized bots, same equipment, but 1000M away be able to catch up to you?

23

(29 replies, posted in General discussion)

PVP flagging on code failure would be an excellent solution here IMO, along with a slight ui enhancement such that it is clear to the hacker that they will PVP flag if the code they enter is incorrect.

If we go down that path, a good question is: if a player is already PVP flagged, should a code failure reset their timer?

Wont take a year... I'd give at say 3 months and I bet the price will stabilize at around 250-280k as generic middle-end miners increase yield and factory characters start being able to do max run factory jobs.

As it is, the marginal price of producing a lite bot is still 300K+ IMO.

Also for cheapish PVP, ewar bots is the way to go right now.

The containers will deploy but not spawn when within a certain distance (500m? 1km?) of a teleport or outpost it seems.