Frontier, since 3.0 is not soon, pls put module, and material limits up now, thx.

Changing mat limit from 1000 to say 4000 and data from 500 to 2000 surely isn't a client update. The OP isn't asking for 3.0 right now, just increased limits.

We don't need per mat storage right now, just increase the existing limits. Give a reason for some to play up to the 3.0 launch.
 
Last edited:
Changing mat limit from 1000 to say 4000 and data from 500 to 2000 surely isn't a client update. The OP isn't asking for 3.0 right now, just increased limits.

We don't need per mat storage right now, just increase the existing limits. Give a reason for some to play up to the 3.0 launch.

No its a client update, the UI changes too.
 
I guess FDev might decide to be nice about it but it seems like updating the mat' & module storage without updating the way engineering works would provide a gigantic opportunity for players which FDev probably don't intend for people to have.

Upgrading mat's would obviously mean people could stockpile high-tier mat's and collect sufficient low-tier mat's to carry out all their intended upgrades.
Let's be honest here, a lot of people (including myself) are stockpiling G5 mat's to use as "engineering currency" and it does make it awkward to collect sufficient other mat's as well.

Which brings me to module storage.
Given twice the module storage, a lot of people are just going to spam G5 module upgrades in order to avoid the rank-grind that will come with 3.0

Additional storage space will be nice whenever it comes but providing it before 3.0 goes live almost certainly means it'd be used to undermine the efficacy of 3.0 itself.
 
Correct me if I'm wrong but isn't the limit going from - limit of total materials - to - limit of each material?

This would require new code.

sorry, i did reply in context of the opening post, not the threat title:
why do we have to wait, you know your going to do it, the module storage is just changing some number in a database from 60 to 120 or whatever. i really wish we could get more incremental upgrades than 1 big one every quarter of a year.

there is no word of material storage in there
 
sorry, i did reply in context of the opening post, not the threat title:


there is no word of material storage in there

Edit:
Bah, misread your post.


Anywhere, it seems to me that putting the module limit count on the server side means that the client has to ping the server and request the limit value. That would be a ridiculous way to go about it, when you can just store the value on the client. You could do the lookup once on startup, rather than every time, but it's still much more complex than doing it client-side.
 
Last edited:
Edit:
Bah, misread your post.


Anywhere, it seems to me that putting the module limit count on the server side means that the client has to ping the server and request the limit value. That would be a ridiculous way to go about it, when you can just store the value on the client. You could do the lookup once on startup, rather than every time, but it's still much more complex than doing it client-side.

Then you’d have people writing trainers to increase or remove the material cap on the client after the initial lookup.
 
Changing mat limit from 1000 to say 4000 and data from 500 to 2000 surely isn't a client update. The OP isn't asking for 3.0 right now, just increased limits.

We don't need per mat storage right now, just increase the existing limits. Give a reason for some to play up to the 3.0 launch.

And then you could get 4000 of level 5 mats (which you will be allowed to keep on 3.0) and use the mat broker to get other mats, exploiting the system.
 
What makes you think that there are not already such tools?

1 - Information is stored server side
2 - Stands to reason values are sanitised and checked before writing to the database
3 - If there was an exploit because #2 was not implemented correctly, we would know about it by now
 
The curse of a developer is that if they do their job well enough, it looks easy to the customer and they begin to make demands that aren't actually as easy as they appear.

I know it happens to me. I've been told as much as late as last week even.
 

dayrth

Volunteer Moderator
Jira is only a tool for logging bugs and features requests, it's not the cause of the bugs - they have programmers for that :D ( just like every software house ).

As a programmer ( not in gaming ) I blame the QA team :)

I blame the customers. My code work fine until they get hold of it.

(oh, hang on... for ED the customer would be me. No, defenitly not the customers fault :p)
 
Last edited:
The curse of a developer is that if they do their job well enough, it looks easy to the customer and they begin to make demands that aren't actually as easy as they appear.

I know it happens to me. I've been told as much as late as last week even.

A game develper some time ago told me, if you tell a coder that there is a bug, problem or anything he could change about his "product",
he will go through the 5 stages of grief:
1. Denial and isolation; 2. Anger; 3. Bargaining; 4. Depression; 5. Acceptance.

:p
 
Back
Top Bottom