contact
November 19, 2017, 03:43:40 PM

Author Topic: Design Flaw  (Read 3368 times)

0 Members and 1 Guest are viewing this topic.

Offline phatboy83

  • Member
  • Posts: 279
    • View Profile
Re: Design Flaw
« Reply #30 on: November 13, 2014, 04:43:25 PM »
I remember you removing the cap on the mines and n or N on the terrys and npcs but thats not what I mean by capping them.

what I'm saying is instead of them getting bigger and bigger as they currently are just cap the amount of ships/defense on them to stop the game from crashing. Then players that want loads more res will have to hit more targets. Then the fleet should stop getting students in mid flight and people will not need to moan about it


Offline kru

  • Member
  • Posts: 239
    • View Profile
Re: Design Flaw
« Reply #31 on: November 13, 2014, 05:24:13 PM »
I remember you removing the cap on the mines and n or N on the terrys and npcs but thats not what I mean by capping them.

what I'm saying is instead of them getting bigger and bigger as they currently are just cap the amount of ships/defense on them to stop the game from crashing. Then players that want loads more res will have to hit more targets. Then the fleet should stop getting students in mid flight and people will not need to moan about it

I think he means an RSP cap, so that NPCs no longer grow in line with the players RSP....

This would place some limit to the games freezing i suppose but wouldn't prevent it....and i am sure that by doing this some players would complain at that lol..

personally, i don't have these issues very issues, only in regards to wormhole attacks freezing up.....Never yet to have an NPC attack freeze
gT brn b Th rk

Offline The Real Highlander

  • Member
  • Posts: 161
    • View Profile
Re: Design Flaw
« Reply #32 on: November 13, 2014, 06:49:25 PM »
I would be okay with the NPC being capped. At least I would not have to continue to build ships to keep up with their growth. The same could be said about the territories. If they stopped growing the fleet required to hold them would quit growing. Both produce more than enough resources to get stuff built.

Offline sgt tj hooker

  • Member
  • Posts: 167
    • View Profile
Re: Design Flaw
« Reply #33 on: November 14, 2014, 04:26:20 AM »
no. it is not the npc that is related to capping. it is a processing data size associated with targets and attackers. not sure exactly what matt means by cap, but to use big int, you now store bits with an potential absolute value equa| to 2^64 (64 bits!) now imagine the log table and that each row in that table stores nothing but the bigint, just the bigint identity value. you can't just use any amount of bits, which is probably what matt was referring to once you decide to start using bigint. you have to use those 64 bits for every value you process and there are either ones or zeros in those bits. so processing a newb with one atlas takes 64 bits. processing kru takes 64 bits. on the log table, the fixed row size is two bytes for the status bits, two bytes for the null bitmap pointer, eight bytes (64 bits) for the bigint value, two bytes for the null bitmap column count and a single byte for the null bitmap itself. total is 15 bytes.  then two bytes for the offset array. the header takes up 96 bytes, leaving an 8096k body, including the record offset array on a 8KB page. 17 bytes per record gives you 476 records per page. 476*9Q = almost 150 petabytes. the SQL Server database size limit is 524TB. oops right? so just keep flushing...?

thats why allocating about 100 million new keys a second would give you about 6000 years to run out instead of keeping all that crap. just delete it. now all you need is a table that allocates 100 million keys a second. should be cheap. right?

for exact values, we have some where near 9 quintillion negative to 9 quintillion positive [-9,223,372,036,854,775,807dec] to [9,223,372,036,854,775,807dec] for a total of about 18.4 quintillion values possible. thats a lot of lines, something like 67 million terabytes. not sure what matt pays for storage, but even a dollar a terra...

its 64 bits of storage for each transaction. the target, and the attacker. think about how many targets there are, and they all need identifiers. identifiers, yes, but also to be processed using the ship count on that specific target...(to be fair). they could be lumped, but then you get a crapshoot, and everyone would scream foul. you can start translating, but now you have tables bigger than the storage. and the throughput is quite impressive. I was thinking maybe a preprocessing, assuming the target makes it, or not, then push the result depending on the land or no land...at least then you could get away from the throughput requirement...you have 9 hours to calculate zeese results. there are a lot of solutions, but they all take quite a bit of coding and maintenance, and anyone who can code algorithms capable of decreasing bandwidth and storage are going to cost as much as physical storage and bandwidth, perhaps more.

its a real problem, and not just bfg's. a key transaction might be a better solution rather than more biggerer numbers. you might kick the can down the road again, but inevitably it will come back. making a transactionable key for each target, and having liquid keys for players based on techs and specific total values would be one way to manage the processing flow, and then process it enroute, encountering a pay or no pay result upon landing. this would at least widen the bottleneck a little for a while. each landing would be more like a tiny pop (ticket?) than a massive thundering short circuit of sparks.

this key and that key have this result whether you run it enroute or at the impact. your ship count will not change from a certain point in the flight, unless a probe is added...but that would be cruel to dos bfg by adding probes to every attack...

yup, im going with preprocesing as a short term solution. you're welcome.

Offline The Real Highlander

  • Member
  • Posts: 161
    • View Profile
Re: Design Flaw
« Reply #34 on: November 15, 2014, 07:42:42 PM »
Lost out on my 6th attack today because of this design flaw. Lost 2ST Ore and 1ST Crystal. Total I have lost out on about 8ST Ore and 4ST Crystal. At least BFG is giving me I hydro back when this happens.

Offline Boss

  • Member
  • Posts: 54
    • View Profile
Re: Design Flaw
« Reply #35 on: November 15, 2014, 08:14:20 PM »
Why bother playing the NPC's if you're having problems with it freezing? Move onto something else, like, attacking players!

Offline The Real Highlander

  • Member
  • Posts: 161
    • View Profile
Re: Design Flaw
« Reply #36 on: November 15, 2014, 08:48:24 PM »
Can't attack players with Zeus, too damn slow. It cost hydro to build and fly the other ships and I am not putting anymore money in this game. Also and the main reason I don't like the attention the game needs to track and attack players. This is why I am a farmer.

I am just thankful it is not happening every attack. I did about 7 attacks between this time and last time it froze.

Offline Deadeye

  • Member
  • Posts: 329
    • Skype - JacobSteeden-Nokes
    • View Profile
Re: Design Flaw
« Reply #37 on: November 15, 2014, 09:32:28 PM »
highlander just start smashing moons ahaha
You will all bow down to ME!

Offline silly_me

  • Member
  • Posts: 62
    • Skype - elvis.perlsly
    • View Profile
Re: Design Flaw
« Reply #38 on: November 17, 2014, 04:45:13 PM »
there has to be a way of predicting this crash before it happens... too many ships/defenses on it?

on our end, if battlementat would predict that BFG would crash, but would have to know exactly what is triggering the event, and on BFG end, they should be able to auto-delete any NPC that would cause a crash or hang to in game processes with a simple code check.  that's not a permanent fix, just a work-around, which is generally the first response you have in the software world to a bug.


elvis perlsly
(not elvis presley)

Offline Pantin

  • Member
  • Posts: 832
    • View Profile
Re: Design Flaw
« Reply #39 on: November 17, 2014, 05:08:23 PM »

Offline kru

  • Member
  • Posts: 239
    • View Profile
Re: Design Flaw
« Reply #40 on: November 17, 2014, 05:18:46 PM »
and i gotta say, conquest is the fastest universe and zeus are much quicker to use and turn around
gT brn b Th rk

Offline Ali Baba

  • Member
  • Posts: 296
    • View Profile
Re: Design Flaw
« Reply #41 on: November 17, 2014, 05:35:43 PM »
Just open up a new conquest uni. Add new stuff cap old stuff give it a new name and watch the players migrate over I know I would love it. Also add more ships and defences and elderon.

And most importantly set a end date for conquest and kill it before it kills you...i don't mean that  literally I mean it figuratively.

Bam..........just solved your problem feel free to give me a small token has a reward

Offline Ali Baba

  • Member
  • Posts: 296
    • View Profile
Re: Design Flaw
« Reply #42 on: November 17, 2014, 05:36:31 PM »
Also what platboy said more npcs not bigger ones would be a great work around

Offline The Real Highlander

  • Member
  • Posts: 161
    • View Profile
Re: Design Flaw
« Reply #43 on: November 26, 2014, 05:04:18 PM »
Its still broke. I am up to 10 failed attacks. About 55 hours of attacks wasted and about 14ST Ore and 8ST Crystal lost. BUT I AM NOT BITTER!!!!!!!!

Offline Mr_C

  • Member
  • Posts: 20
    • View Profile
Re: Design Flaw
« Reply #44 on: November 27, 2014, 12:48:28 PM »
@ Highlander .... heres a novel thought.. try building ships other than zeus  ???!