It's good to see progress on these issues.
big_smile

227

(22 replies, posted in News and information)

Thank you for the update!
Keep 'em coming.

228

(9 replies, posted in Q & A)

Also, if you harvest any plant below (1) cycles it will die.
For nora this means the incubator on that tile also dies and will not grow back (as it is not naturally grown).

It is important to note, that other players may also be finding your plants, and accidentally (or intentionally!) killing them.

229

(51 replies, posted in Balancing)

This is a great discussion.

I do agree not all products should span the high variety of 2nd-level industry components.  But as a way to compromise the reduced variety with the possible result of super-cheap bots, is to increase the quantity.
This will also encourage industry characters to focus on one faction or another, host themselves on islands with requisite kernals and raw materials, and become a staple of their market suppliers. 

This will further segregate markets and centers of industry, which is something eve ironically has been trying to do to lessen the load on jita, and provide viable markets for non-maxed out indy characters.  (Less centralized, less competition, more room for margins).  [Edit: I forgot to highlight this would be BAD with current market density, we need a 'jita' to drive prices down as they are way inflated from undersupply, and new players that cant supply themselves.]

One thing that was a twist for me seeing this games industry material and processes: the prototypes and subsequent tiered item being required for the next tier item.
This is interesting, but seems to overwhelming result in one outcome: T1->T3 are more valuable as factory component than they are modules themselves.
To ville's comment, T2 should not just be a component to make t3, then t4, it should be a useful module in its own right.  However, purely by what the process is set up as, demand for them as products to produce the most valuable and highest margins will outweigh the potential new customer base that would be buying this extra performative T2 module.

What then? you may ask. Since each tier requires effectively the module(embedded with the module's material composition) plus another load of the same materials + another type(increasing in rarity/price).  Why not supplant the required lower tier item with its material-demand instead?

Prototypes will still be needed to make the CT, and maybe for this the lower tier item is still needed (since this would once per some 100 modules).  But the CT will not have a requirement for the tier before! [Maybe its optional? That however feels like something that might not be ready to implement code-wise]

This would result in the T2 and T3 modules becoming their own end-products, sought out for their own benefits balanced against price! 
Again, as ville said, they need to be useful and perhaps uniquely so, versus the other tiers.  Lower fitting for T2 is good, but maybe extra effectiveness (just a smidge).  T3 maybe only boosts 1/2 of the modules different effects... maybe this opens up a whole variety of different Tier variations that can exist before the 'maxed-out' T4.

230

(392 replies, posted in Bugs)

Blocker wrote:
DEV Zoom wrote:

We have sent new data and download statistics to them today, we'll see what they say.

I for one appreciate you staying on the case and trying to get to the bottom of it..

+1

231

(149 replies, posted in Balancing)

+1 to most of what Burial has been posting.

Also, have we considered creating a factor for modifying locktime between bot classes(maybe based on surface area.. or some other attribute)?
I might be reading into the intentions behind the patch and some of the other discussion, but if you want to make light and assaults more viable on the battlefield: why not make them harder to lock onto?
Yes this is right out of Eve but it works really well at giving smaller bots to land hits/lay down ewar before getting popped. 

It could be a modifier on current locktime so two bots of the same class (or srf. area, or mass, or ...) will have F=1.0 to each-other.  Whereas lets say a small ewar bot against some heavy mech might have F=0.5, and the H.Mech will only have F=1.5.  With both locktimes at 10s, the light bot could lock the heavy with 10s before the heavy locks back.  Keep in mind this is in addition to range, extensions that modify locktime directly, etc. etc.
(This being the extreme ends of the spectrum.)

What this helps with is fleet composition variety and encourages even squads that are mostly mechs to also include the smaller tacklers, ewar, and counter-small bot assaults.  This exists to some degree, but the solution of patching up lights and assaults with more armor or range, etc, makes them perhaps more powerful singularly than their class was intended.  Nerfing others down to match doesn't make sense.  So maybe the solution is a game mechanic or bot attribute that levels this out between classes. 

With faster lock times, light bots are guaranteed (under 1:1 circumstances) to land 'hits' against larger bot classes.

Yes, this too can grow into a whole set of modules and extensions.  Improve your locktime, lock-modifier, ability for others to lock you, ability to lock others etc. etc. You get the idea.

As for affecting PVE, I don't see it being an issue.  If anything it makes the player want to fit an equivalently sized bot for the assignment to maximize speed and turnaround time (Adding risk! and Excitement!  Oh Ah!).  And makes grinding with mechs slower (oh no, potential whining, oh noo), but no less effective (Whining averted! Huzzah!)

TL;DR
Modifier on Lock-time based (mostly) on bot class differentials.

232

(149 replies, posted in Balancing)

First, the fact that this thread exists is fantastic. +1
Maybe it should have come sooner, perhaps immediately following deploying the current patch to the test server.

One goal mentioned was to help diversify fittings of bots.
Integrating a Stacking Penalty would help this considerably.  Fits would be less about filling head slots with the same tuner, but more different tunings, and other mods, because at some point the same tuner would be worth less to have than some other type of module.
Now the thing to keep in mind is this diminishes maximum-possible DPS/EW/mine-yield/accum/etc.   
(This is why integrating some quick-fix solutions to one issue can result in imbalancing another.)

I heard mentioned that stacking currently acts more like a 'bonus' (modifying the modified value, instead of the base)  [Base*1.05*1.05...] > [Base+ (Base*0.05)+(Base*0.05)+...]  for some 5% tuning boost for example.
So changing to linear (second one) makes sense, but this still may not be enough to help 'encourage' the player behavior and fittings you would like to see fielded as viable and frequently used in the game.  There may need to be a diminishing return.  I would caution tacking on a penalty to some other attribute, instead of penalizing the bonus directly.  (Reason why was quickly addressed a page back or so).

I'm sure this isn't new, but allow it to be a +1 vote to getting it in the next patch to help with your goals of incentivizing  more diverse bot fitting strategies.

233

(33 replies, posted in News and information)

Don't skip on documentation, please?
smile

234

(12 replies, posted in Feature discussion and requests)

Players and Devs discussing algorithm design on a public forum to improve the game weighing both space-time complexity and ease of implementation. 
Well done.
+1

235

(3 replies, posted in Balancing)

A lot of the complaints about the balance patch seem to revolve around the ability for a bot with more slots to 'out-gun' another bot in their 'Role' or intended use.

TL;DR Incorporate a non-level based 'bonus' that is the same regardless of players extension levels, and ensures the Role of the bot is sufficiently biased.
*Feel free to debate what 'sufficient' means with respect to balancing. 

So a Seth can fit more Enwar modules, and more tunings, therefore increasing overall neuting capability beyond what 1 ictus could achieve, (with the same extension levels.)
Whether or not this good is debated.  Should the Ictus be able to out-neut All bots, or just bots of its class and smaller? 

Either way, this example and similar issues with the disruption of the overall bonus amount decrease has lessened the bonus system's ability to strongly-bias a bot's particular usage.
The goal of this patch was to reduce the total delta of level-based bonuses, therefore making the effective-gap between two different leveled players in the same bot.  Also reducing overall effectiveness of what could be maximally achieved (bonus at lv10).  This too, is debated as to whether this was intended or incidental.

My proposal is a Static Bonus, a Role Bonus, to boost the bot's specialties by increasing the performance of some modules, or whatever, but not have the bonus increase with any extension level. 
This way, a base-level pilot will have the same intrinsic boost as a fully leveled pilot.  Of course the other +3% per level in X skill will remain.  This way the gap between these two pilots is the same (same delta) but both are piloting the most effective bot in that Role given their skills. 

If you still don't know what I am talking about, look at Eve ship descriptions:
https://wiki.eveonline.com/en/wiki/Talos
Scroll down about half way for the 2nd block of text where it shows the Skill-based vs Role bonus(es).

Implementation seems simple, though I see no current precedent for this in game. 
It also seems like this could satisfy not only the goals of the Dev's with this recent balance, but also the issues it caused with how the game was previously being played. 

Thoughts? big_smile

236

(71 replies, posted in General discussion)

Again, just a noob here:

What if they incorporated a 'Role Bonus' for each bot?
The Role bonus of course ensures that the particular bot is the best in its class for some particular task by a static bonus to some module(s) effectiveness.
This bonus would not be effected by Extension levels.(!)

Haven't seen this suggested yet, but seems like it might address the issues most are raising over the recent balance patch.

What do you think?

237

(23 replies, posted in General discussion)

Inda, I wasn't counting the most recent robot re-balancing post because at the bottom in italics it is said that it is not a monthly report and that will come later.
http://blog.perpetuum-online.com/posts/ … balancing/
"ps. This isn't the monthly report, that's still coming."  It had plenty of content to count, but I was hoping this line was suggesting one blog post would still be forthcoming for this month (November).

Once a month is better.  The quotation I pulled from the September blog, as I remember, was after community members demanded more communication from the Devs after having none over the summer.  I would like to see something monthly, even if its an inch of progress on the same path as previously announced.  I think most of us understand things take time.  But if the evaluation is that progress does not warrant a post, that's fine.  I perhaps misunderstood the premise of the monthly report as it resulted from the discussions last summer.

238

(23 replies, posted in General discussion)

You are right, I misinterpreted your previous statement in a blog.
"That’s all for now, and I’ll try to make these reports a monthly thing, promised." -Sept. 2014 blog
I take it at your word that you will try.  However, it is likely others will not.

I honestly didn't mean for this to be another thread of airing grievances.  I literally just wanted to see a blog with stuff to get optimistic about.
Then perhaps others would have hope for future features, rather than dwelling in dissatisfaction with the current ones, or most recent.
I get the PR-sword can cut both ways if you promise too much, but its better than nothing.  It should be an opportunity to control the dialog about where the game is going.  It seems the community, when left to their own devices, post images of sinking ships (not attractive for new or returning players).

239

(23 replies, posted in General discussion)

I think many members of the community, vets and new cats alike, have emphasized and demonstrated through precedents and your competitors how important Dev blogs are.  The ways in which they are effective at maintaining a strong player base, even with slow development cycles.  Because in those cases, the players at least know where on the roadmap you are, and can understand the progress being made in context.

I understand how it can be that things like this get shuffled to the bottom.  As a programmer, dealing with 'humans' can be silly and frustrating.  However in this case, your end-product is highly dependent on the participation and continued involvement of many users.  Also in that list is probably marketing.  In a way the Dev blog is a marketing tool to tell your users you are still around, still working, build hype, get feedback, and attention.  So think of this as getting 2 birds with 1 stone. 
However don't forget once you get a solid PvE, assignments, and other QoL features revamped, real marketing investments should not be overlooked.

A monthly blog was promised. 
Don't break promises.

Many thanks,
-A concerned citizen

Hopefully someone is keeping a list of some of these obvious QOL features to be implemented..
Maybe that should go in the next Dev blog!! (Which we will see in the next 4 days as promised)

For this feature request:
-Either a string based search/filter, or a menu of options to selectively view things like :Market fees/tax, mass production charges, transfers, item sales, purchases, etc..
-Get rid of the by-day paging and replace with adjustable # of result per page.

Right now its difficult to sift through personal transactions, or corporation accounting records to see these things mixed in with a bunch of other transactions in the same day. 

Also the limit of results per page and by-day is also very limiting.  On top of that, showing days with no results as separate empty pages is also just slowing things down for the user.  Limiting to a maximum is important for performance issues, but automatically breaking each page by day if we have timestamps is redundant, and just populates more pages to scroll through.

241

(30 replies, posted in General discussion)

+1
Hunter, you are right. 
Alpha general markets need to be supplied.  Market density has been cited for a number of negative reviews.  I know in-corp markets are a valuable feature, but ultimately defeat a public market which affects only newer players. 
I would also append to your list in saying all aspects of early experiences in-game are subject to scrutiny.
For the players: being positive and Patient with new players (especially in Help Chan) is crucial.  This seems to be fine, most are understanding in chat.  However, I don't think we should self-censor in all in-game media for the sake of putting on a facade.  Many have been here for years and are justifiably bitter in some regards.  Their* perspective is still valuable, and Devs should feel the pressure to improve their game.  However, perhaps the positive and constructive voices should make more of an effort to make themselves present in the game/forums(ones perhaps we have never heard).

http://steamcommunity.com/app/223410/di … 969421023/
Steam post citing similar issues, and the review status as being detrimental to future growth of the game.

Also, I don't know if we can reset the game 'status' to EA, wipe reviews and let the Devs have a round#2 release of the game when it is really ready. (Assignments, Pve, Indy balance, Combat balance/specialization, etc.)

*Some, not all.

242

(8 replies, posted in Feature discussion and requests)

+10^10

243

(22 replies, posted in General discussion)

Well, the individual hasn't let off the negative PR campaign.  And honestly, kudos to those that are doing their best to provide honest and direct answers and responses to his attacks and misconceptions. 
His script to scrape chat logs for activity is interesting, and perhaps points to reporting realtime player data officially rather then letting him control the discussion and make it out to be some intentional PR move by the Devs to mislead the players or potential players.  This data, of course he may doctor with no way for us to prove or say otherwise, which logically he will do.

I post here to say to those that are responding to him: don't!  Just let him say whatever, say your side of the story but don't feed the troll.  Don't address him, address the question from the community and move on.

Steam does have rules and report mechanisms.  So perhaps it might be worth looking into: http://store.steampowered.com/online_conduct/

The only answer I have to people that are dissatisfied with the 'product' is that its categorized as an Indie-MMO, gauge expectations accordingly.  All the people ranting about buying under false pretenses are just cases of impulsive decision making. 

I think it does well considering this, and its price point/no sub.  But these are all opinions after all.

Sorry I don't mean to dredge things up, nor make this bigger than it needs to be.  Hopefully he moves on to slandering another indie game, because you know those greedy deceitful indie companies...

244

(10 replies, posted in Feature discussion and requests)

I agree, the speed bonus, the surrounding environment, quickness of animation and camera perspective, and the bug-like light/assaults paired with the very directly anthropomorphic mech proportions all give the feeling of smaller droid-like robots, and less so 'Mech' as has been traditionally understood.
As an aside, this is perhaps what some people with the recent launch react to most violently, is the sheer disappointment that the robots seem small and playful, and less lumbering and ominous.   

The question then is, do the devs pander to this, or try to push for their own sci-fi internet-space-robot aesthetic?

245

(32 replies, posted in Feature discussion and requests)

So to summarize what I gather here:
Some like the additional cover/pathing confusion they provide (hence a dis-advantage for one side or another).
Some want them removed altogether, or revert to how it was before.
One guy likes em.
Another would like to see variety.
Everyone hates lag.

So its clear, as it stands it is perhaps excessive and could be more strategically implemented.  And perhaps as a bonus: more variety/complexity of plant life. 

Cool, so hotfix tomorrow or what? lol
But seriously is there a process for fielding things beyond this forum?

246

(10 replies, posted in Feature discussion and requests)

+1 for Bear-medics

247

(32 replies, posted in Feature discussion and requests)

So I've seen a number of posts/threads about the new forest clusters of low tree-like, non harvest-able, plants. 

Quoted from patch notes with the change:
"A lot of plants have been reduced in size to combat the perceived feeling of small robots. We have also changed the way they are growing, so they will now more likely gather in colonies and form forests. If you experience reduced client performance because of this, try to reduce the "draw distance" slider in the options. "

This manifests issues with impassibility, auto-pilots path-solver, client performance, and I would guess server performance given they are all unique objects. 

So my humble, ill-informed, nooby-ridden suggestion tackles issue of performance, but also aesthetics with respect to the point brought up in the quote.

Let there be trees, but as large, maybe just tall, maybe multiple tiles, but fewer in number.   Similar to perhaps how it was before the patch ironically. 

This addresses the number of objects that are instanced and loaded when players cross the grid lines, thereby reducing load client side.  Having singular larger objects will allow for the same use of cover, and restrict motion for strategic dis/advantage.  Perhaps some are still low-lying for ballistic fire, while some are higher and provide cover from missile volleys. 
Also, having larger convex objects will make autopilot pathing solve more effectively through these forests (I think according to how I've seen it operate).

The second point is on the aesthetic justification, which I don't agree with as stated in the quote above.  Sure, maybe we should have large lumbering robot/mechs to play more towards the MechWarrior crowd.  But the camera perspective already diminishes the scale, as does the landscape, and infrastructure.  So to remain consistent and allow you, the devs and designers, to really sculpt visually and spatially appealing places to explore, uncover, or exploit, taller tree-life will augment this. 
Without taller trees, the landscape feels kind of bald, you can see very far on the horizon, and nothing feels 'hidden'.  Why not allow for things to be obscured? Why can't alien plant life dwarf our bots? 
Perhaps even the tree of the forest can have growth in size and height over its maturation. 

So I offer this compromise to the forest idea:
Less in number, larger in size (of each object).

Long time listener; first time poster.
Now this might be something that exists, or did exist, but was altered for the steam release and non-gamma world npc/pve balancing.  However I am worried there is an oversight of the potential of the following:

The idea:
*Add red npc's to Alpha-2, maybe even areas in 1.(!)
Details:
-Make them really low-level npc's.  akin to the drones around alpha-1 terminals, dumb ai, weak dps, no ewar, slow..etc (scale up to create a gradient of difficulty in particular areas/islands)
-If they roam: reduce their max speed or give them inefficient navigation mechanics.
-Ambush squads off the highways! Roaming gangs in the wilderness! Oh the possibilities!
-etc. etc. you get the idea.

Why:
The idea of risk needs to be introduced and at a scale small that is somewhere between future beta/gamma pvp experience and the current alpha risk factor (0). 

Force haulers and miners alike to at least fit for some defensive or offensive tactics to combat the red-npc rats.
This will at least begin to have miner-types cross train to fit a gun and repair modules.  Whatever the rat composition, it should be possible to fend them off easily should a miner/harvester at least taken this into consideration.

Now at least miners have some choice, they can fit to solo tank the reds (sacrificing nic/hr), or squad-up and get some combat support. (Encouraging player interaction?! - or multiboxing..)

I am not saying that these reds should be able to pop every Scarab that is autopiloting, but maybe the ones that didn't fit a shield...  Balancing will be tricky, but limiting the alpha-red npc ai, or fittings should be able to modulate the risk factor.

Add a bit of a challenge to those that choose to reside in alpha.  As the game becomes more populated alpha-sourced materials will over-saturate the market.   Reds will at least add interference and therefore value to the activity.

Inda made a good point about not neglecting those who choose not to pvp.
[http://forums.perpetuum-online.com/topi … experience]  (specifically post #14)
This doesn't mean their experience with pve/mining/harvesting/hauling should not be met without a challenge.


Yes, this is not a new idea, but I am curious as to why its not present. 

TL;DR
Non-pvp islands should have a gradient of risk induced through strategic pve content (red-npcs) that does not exceed the capacity of indy-players to contend with.

Your thoughts?