Improvement in the performance of the server and greater reason to buy the monthly card

[saberbholt]

Improvement in the performance of the server and greater reason to buy the monthly card (and more number of players who use it).
Does it seem too good?

Actually the concept is very simple:
Eliminate all the girls' counters (which reduced the server's workload by almost 30% or less from the current load) and leave only one general girl counter in a common pool where the cash would be for pick it up (instead of 1 in 1 with your counter).
For example: it would happen to have 75 girls with 75 different counters with payments between 595 to 5000 to be a single accountant with 140,000).

But how would this re-launch monthly card sales?
Simply making the monthly card if activated automatically pick up the pool.

But would not people stop coming in?
Yes and no, remember that every 30 minutes there is refreshment in the PvP matches, so even if they did not have to enter every 10 minutes to collect cash from the girls there would still be traffic of people and the connection would be less saturated by not having to be pending every connected time

So for the change in the collection of the pool automatically ?.
It's simple, it would give you more freedom and flexibility when playing, without losing cash while you sleep, work, study or just prefer to go to the movies or watch a movie.

What do you think of the idea?

[Romeo Arturia]

8 minutes ago, saberbholt said:

So for the change in the collection of the pool automatically ?.
It's simple, it would give you more freedom and flexibility when playing, without losing cash while you sleep, work, study or just prefer to go to the movies or watch a movie.

What do you think of the idea?

Feels like it'd eliminate the purpose of playing the game, kinda like sending a bot to play for you.
Plus you'd still have to leave your computer turned on, which means waste of electricity & higher bills pretty much.

Sincerely

[Romeo Arturia]

I know of another much more viable idea.
Every time all girls give money, there could be implemented a history of the total amount of money you'd gotten
while being offline, then you could collect all at once after getting back online.
Not a bad idea at all if I say so myself.
What about others' opinions on this?

Sincerely

[saberbholt]

20 minutes ago, Romeo Arturia said:

Plus you'd still have to leave your computer turned on, which means waste of electricity & higher bills pretty much.

in reality you would not need to have the computer on, the server would know if you have activated the monthly card and collect the pool, obviously if you have a card not only would not do it but as now by not collecting cash from a girl, the timer is not restart (it is not a cumulative pool)

 

 

the idea is not having all the money in cash (except obviously pay for the monthly card) is more to have a reason to buy it and eliminate the chronometers that use a lot of server work (going from 79 timers to 5 with 75 girls is a lot of calculations less, imagine that for each player when working the server)

Imagine the midle of players have is 50 girls, with that systen of only 5 timers (pool cash, batle, energy, shop and pvp change of enemy) the server can be x45 times the number of players actualy with the some work charge and have one more reason give the monthly card (monetitation of the game) with no impact in the players.

Edited June 6, 2018 by saberbholt

[Habi]

i don't believe this would increase server side performance. the server doesn't start timers to track something. the server just has a timestamp stored. the tracking/counting is done purely on the client. and when you push the collect button the timestamp on the server is updated.

this is also the reason why calling the latest patch a performance improvement can just be an excuse for something they hide from us.

[ClubNutte]

16 hours ago, saberbholt said:

...

(which reduced the server's workload by almost 30% or less from the current load)

...

Just being curious: what's your source for the 30%?

[saberbholt]

the code in execution always is make the timers for all users, one for pvp change of players, one for change of items in the shop, one for recarge energy, one for the recharge of combat points and onme for every girl have in his harem for the pay. That is always for all player are or not conected make the calculs and the code for make wait conections of players. the code for load  dates of database for players only work when a player is conected and is checked every time refresh screen or change of screen (if you see for any changes need to change to one or other screen: buy item, play pachingo, make combat) are in this moment the server make comprobations and change dates or upload new dates.

For that the code for execution primary (the timers) make a down of work from 80 timers in only one user to 5 with that system, multiply for every player who have more than 1 girl in this harem and you see the number of timers the server don't need to calculate. Really is more than 30% the new charge of work but i put that number because think in backup data of the database and all the server system in second plane.

[saberbholt]

15 hours ago, Habi said:

i don't believe this would increase server side performance. the server doesn't start timers to track something. the server just has a timestamp stored. the tracking/counting is done purely on the client. and when you push the collect button the timestamp on the server is updated.

this is also the reason why calling the latest patch a performance improvement can just be an excuse for something they hide from us.

thats not correct and can verify that easy, when you reconect in 10 or 50 minuts the timers of the girls was not stoped or reset, the only think for that was is:

A) your computer make the calculs, but that not posible because you don't have a client software and if you shutdown the computer the timers of the girls run. Until the only think is option b.

B) the server make calculs of all the timers of all the girls ever are you or not conect, and thats is consumition of clock processor cicles.

I now the conection and refresh of an acount and search in database is one of the thinks less use make to a processor. A lot os leess than calculs of timers. For make an idea, the conecton of user with database the most problematic is the speed to search in hard drive dates in query, the rest of operations are so fast (move to variable, asignation of memory, sent to screen...) and when data of user is charrged or compare the conection with the database is closed and reopened when change of screen (for compare if are or not changes in the tables of the database). But allways the processor are calculatin the countdown of all the players girls (and the other timers form shop, etc).

 

If like to make a sense of that problem with timers only need to make a simple proyect in any programing lenguaje some visual basic. when more timers have so much cicles need the procesador.

Edited June 7, 2018 by saberbholt

[Habi]

10 hours ago, saberbholt said:

thats not correct and can verify that easy, when you reconect in 10 or 50 minuts the timers of the girls was not stoped or reset, the only think for that was is:

A) your computer make the calculs, but that not posible because you don't have a client software and if you shutdown the computer the timers of the girls run. Until the only think is option b.

B) the server make calculs of all the timers of all the girls ever are you or not conect, and thats is consumition of clock processor cicles.

I now the conection and refresh of an acount and search in database is one of the thinks less use make to a processor. A lot os leess than calculs of timers. For make an idea, the conecton of user with database the most problematic is the speed to search in hard drive dates in query, the rest of operations are so fast (move to variable, asignation of memory, sent to screen...) and when data of user is charrged or compare the conection with the database is closed and reopened when change of screen (for compare if are or not changes in the tables of the database). But allways the processor are calculatin the countdown of all the players girls (and the other timers form shop, etc).

 

If like to make a sense of that problem with timers only need to make a simple proyect in any programing lenguaje some visual basic. when more timers have so much cicles need the procesador.

that is still just wrong. it is as i said. i can guarantee you that.

a little calculation here imagining the server really does the timers himself: every timer runs in an own thread. so lets say a player has 50 girls on average and with all the other stuff it's about 60 timers per player. so 60 threads per player. according to tof there are about 1 mil players. that makes 60 mil threads in addition to everything else that runs on the server. while big enough server clusters can handle that do you really think kinkoids servers are large enough? i guarantee you it is not.

and don't forget: this example was just to illustrate how ridiculous this approach would be. the better argument is still what i said above.

Edited June 8, 2018 by Habi

[ClubNutte]

Hi saberbolt,

thx for your reply. I thought, you might have actually seen the code, but i seems, you are guessing as well.

There is a flaw in your theory: as long, as the server doesn't push the data at a specified time, there is absolutely no need to use timers on the server side.

I go along with Habi on this one, let me elaborate:

In the bottom third of the html is some js-code with your girls' required data. I'll take Red Battler as an example...

'pay_time' is the absolute amount of secs it takes to refill the girl's purse, 'pay_in' the remaining secs until you can cash (0, Red Battler is due...).

girls['7'] = new Girl({"id_girl":"7","level":"90","graded":4,"Name":"Red Battler","salary":4042,"pay_time":5820,"pay_in":0});

Pushing the 'Collect'-button triggers this XHR:

The response's 'time' replaces 'pay_in', the client starts counting down...

[end of proven facts]

The 'collect'-requests timestamp + 'pay_time' is stored on the server (I'll call it 'due_time').

The timestamp of the next request (request_time)  is checked against due_time':

if request_time > due_time:  'pay_in' = 0

if request_time < 'due_time: pay_in' = due_time - request_time

Et voilà, simple and cheap.... admittedly this is just a guess, but it appear quite feasible to me

[Chthugha]

My guess is that the game checks your local clock once you login to determine the timers, and compare it with a timestamp saved on the server.

This would also explain why it takes a while to load the harem page when you login after a while.

Anyway, I am not really interested in how things are coded in games

[saberbholt]

4 hours ago, Habi said:

that is still just wrong. it is as i said. i can guarantee you that.

a little calculation here imagining the server really does the timers himself: every timer runs in an own thread. so lets say a player has 50 girls on average and with all the other stuff it's about 60 timers per player. so 60 threads per player. according to tof there are about 1 mil players. that makes 60 mil threads in addition to everything else that runs on the server. while big enough server clusters can handle that do you really think kinkoids servers are large enough? i guarantee you it is not.

and don't forget: this example was just to illustrate how ridiculous this approach would be. the better argument is still what i said above.

I think you confuse threads with clock cycles, a timer usually uses 20 clock cycles more or less, each processor in a 3.5 ghz i7 has 3.5 x 10 raised to 9 in each kernel, roughly: i7 of 6 cores would have 18,000,000,000 cycles in total, the threads refer more to the number of simultaneous programs, but here we talk about all the timers are in a single program next to the system of connection to the database and login. You should not confuse the number of processes in a system with the number of parallel calculations of a process, for example when executing a raytrace in a render the number of calculations for incidence of light particles and rebounds are calculated individually although they are calculations that require many more CPU cycles to be executed than a simple timer

Edited June 8, 2018 by saberbholt

[saberbholt]

3 hours ago, Harem Krishna said:

In the bottom third of the html is some js-code with your girls' required data. I'll take Red Battler as an example...

i think is the load data from database for display in your html screen,. Don't see any code for make operations and more important, if code works how you think, you can cheat from your side the code for change timers, payments, lvl an all of the game, thats one of the things because all calculs are from server side.

Is more a Object-oriented programming, your side buttons make unchain the code in server side for make changes in your account of the database and change your visualitation variables in your side for see the changes.

I make a easy probe for that, change the computer hour and reopen game, if work unyil you think making the timers in your pc and compare marks time the girls are in time to pay and not, the clocks are in the some time  and more importnt i change the time with the game open and not have efect, don't crash, don't update timer, simply done, for that questions i am sure is the server who make the calculs in his side.

Edited June 8, 2018 by saberbholt

[saberbholt]

2 hours ago, Chthugha said:

Anyway, I am not really interested in how things are coded in games

jajaja I understand you, but in my case it is because of my work experience and my type of work as a database and management programmer as well as the experience in mmo games (where there are calculations and many on the client side for which bots can be created or cheat players with external programs)

[saberbholt]

they could be using another system for the timer which is basically the same but with small pauses, I explain when a timer reaches zero and the timer is not picked up, it stops in terms of calculs, also they can make that when you disconnect you save the time and calculate it when reconnecting making the difference and updating the time of the timer (is the wayI would have used), that would have less timer running on the server while the user is not connected, but that does not free the server from having to work with all the timers of the connected users and As we have seen, they are not few.

Edited June 8, 2018 by saberbholt

[ClubNutte]

19 minutes ago, saberbholt said:

i think is the load data from database for display in your html screen,. Don't see any code for make operations and more important, if code works how you think, you can cheat from your side the code for change timers, payments, lvl an all of the game, thats one of the things because all calculs are from server side.

Is more a Object-oriented programming, your side buttons make unchain the code in server side for make changes in your account of the database and change your visualitation variables in your side for see the changes.

I make a easy probe for that, change the computer hour and reopen game, if work unyil you think making the timers in your pc and compare marks time the girls are in time to pay and not, the clocks are in the some time  and more importnt i change the time with the game open and not have efect, don't crash, don't update timer, simply done, for that questions i am sure is the server who make the calculs in his side.

Look, I don't insist, that they are doing it this way, but the data they submit from the server and the lack of data they submit to the server strongly suggest (at least in my eyes) that they (should) handle it somehow like this. The only parameters the server gets are action & class for the request-handler and the girl's id (to find her on the server - whether in a database or some serialised sessions is utterly irrelevant)

I agree with you that the embedded javascript is mainly for display purposes but also initializes the timer on the client (but the server couldn't care less about the clients timer)

/**
 * This is pseudo-code! And yes, it's neither complete nor good style!
 **/
// We're on the server, harem.html has been requested and $due_time is initialised with the girl's cashing-timestamp
$delta = $due_time - $_SERVER['REQUEST_TIME']; // or time(); if you prefer to use the moment of code execution
$pay_in = ($delta < 0) ? 0 : $delta;
// serve the page...

Client timer is 0 (either decremented or manipulated), button gets activated. Let's press it immediatly:

// back on the server, we evaluate the POST-request...
//   ...json_decode($postdata), switch($action), getGirlBy($who), blah...
// ... ok, the guy wants money from girl $who
if($_SERVER['REQUEST_TIME'] < $due_date) {  // behold the lack of client influence, the client merely unlocks the button
	deleteAndBanForever($playerAccount);
	showMessage('You, Sir, are a bloody cheater! Begone!');
} else {
	$due_time = $_SERVER['REQUEST_TIME'] + $theSomewhereElseConfiguredRefillTime;
	// pay...
}

Staaaarike! Rocket-Science at it's best! Caught the perp red-handed...

In short, without sarcasm: the client merely decides when you may ask for the money, the server alone decides, if your entitled to it.

P.S.: I'm curious, the louder I'm boasting, the bigger is my embarrassment if I'm proven wrong...

[saberbholt]

55 minutes ago, Harem Krishna said:

the client merely decides when you may ask for the money, the server alone decides, if your entitled to it.

It does not matter, you are really right in the client code but it is something conceptual that has escaped you: the client shows and indicates the activated button as you say and checks with the server if it has a right, or if it is correct the button is active and pick up the paago. But what escapes you is the concept "if the server decides it is valid", at this point to know the server if your counter is correct, is delayed by lag or you have the right or not to charge, you can only do it in 2 ways : running a timer to zero or doing the differential calculation between server time stamp for next payment and current time on the server.

For practical purposes, a timer will be used or an infinite loop of verification of the button will be used (since it always checks) so that this does not happen, a 2 step check is done if desired; a timer that reaches zero + when the time stamp check reaches zero.
Of course with the timer the other is not really necessary in this situation and I would only add more calculations and code, that's why I am convinced of the use of timers in the server.

(Don't worry for if are or not wrong, is the most interessant responses in a thread i read in time ago ^^ )

Edited June 8, 2018 by saberbholt

[HaremHero]

@saberbholt

does this means free users has to click 1 by 1. while members has all the girl timer combine? (thus click only 1)

[ClubNutte]

2 hours ago, saberbholt said:

It does not matter, you are really right in the client code but it is something conceptual that has escaped you: the client shows and indicates the activated button as you say and checks with the server if it has a right, or if it is correct the button is active and pick up the paago. But what escapes you is the concept "if the server decides it is valid", at this point to know the server if your counter is correct, is delayed by lag or you have the right or not to charge, you can only do it in 2 ways : running a timer to zero or doing the differential calculation between server time stamp for next payment and current time on the server.

For practical purposes, a timer will be used or an infinite loop of verification of the button will be used (since it always checks) so that this does not happen, a 2 step check is done if desired; a timer that reaches zero + when the time stamp check reaches zero.
Of course with the timer the other is not really necessary in this situation and I would only add more calculations and code, that's why I am convinced of the use of timers in the server.

(Don't worry for if are or not wrong, is the most interessant responses in a thread i read in time ago ^^ )

Glad your not offended. I didn't have any sleep tonight, lots of coffee today, my own project doesn't really work out and even under normal circumstances, I tend to overreact

If you would only let go the idea of server-side timers

You say it yourself:

Quote

you can only do it in 2 ways : running a timer to zero or doing the differential calculation between server time stamp for next payment and current time on the server.

'server time stamp for next payment' = $due_time

'current time on the server' = $_SERVER['REQUEST_TIME']

'differential calculation' = $delta

(->my last posting)

When you get a new girl, the 'collect'-button is enabled, pushing it, triggers the ajax_call (initializing 'current time on the server'). That's all it needs, since this is the only info, that the server lacked to initialize the 'server time stamp for next payment' (and the girl's id, of course, but lets imply that for the sake of brevity). Request time plus the girl's 'pay_time' make the 'server time stamp for next payment'.

Quote

But what escapes you is the concept "if the server decides it is valid", at this point to know the server if your counter is correct

Again, the server couldn't care less about the client's counter. To the server, it's a bloody boolean, not an integer. It's not 'you're exactly 42 seconds to early' or 'by the way, you could have asked half an hour earlier'. The counter simply unlocks the button. If there's a lag: doesn't matter. There's only a problem, if the client's clock is significantly faster than the server's. And even then, the transfer rate and the server's tardiness are working for you, for it doesn't matter, when you send the request, but when the server processes it.

Short: the server doesn't need to count, as it doesn't need to work unless requested. On request, a quick comparison of the two timestamps is sufficient, to either serve or deny the request.

Quote

the client shows and indicates the activated button as you say and checks with the server if it has a right, or if it is correct the button is active and pick up the paago

There aren't any checks or negotiations between the client and the server, it's 'swim or sink', t&e.

 

I agree, checks and more info are a nice to have, but this is not Cupertino, it's a <whisper>cheap</whisper> browser-game with finite resources, focused on ROI (where investment is written lowercase and RETURN - but enough of that).

Cheers & KISS

Edit: it's 'two' timestamps, not 'to'

Edited June 8, 2018 by Harem Krishna

[Habi]

9 hours ago, saberbholt said:

I think you confuse threads with clock cycles, a timer usually uses 20 clock cycles more or less, each processor in a 3.5 ghz i7 has 3.5 x 10 raised to 9 in each kernel, roughly: i7 of 6 cores would have 18,000,000,000 cycles in total, the threads refer more to the number of simultaneous programs, but here we talk about all the timers are in a single program next to the system of connection to the database and login. You should not confuse the number of processes in a system with the number of parallel calculations of a process, for example when executing a raytrace in a render the number of calculations for incidence of light particles and rebounds are calculated individually although they are calculations that require many more CPU cycles to be executed than a simple timer

no i don't.

if you think further what you started here you come to the conclusion that i was right from the start. also listen to @Harem Krishna. i couldn't explain it in this level of detail earlier because i was just on my mobile phone. but he is absolutely right. i couldn't have explained it better myself.

[_shal_]

9 hours ago, Harem Krishna said:

In short, without sarcasm: the client merely decides when you may ask for the money, the server alone decides, if your entitled to it.

I can confirm that from experience. Occasionally the money pick-up button appears up to 2 seconds too early for me on the front page (i.e. when the currently active counter is still showing 0:02). Clicking it immediately results in...no money being credited, and the button for the same girl's pick-up amount appearing once again after those 2 seconds, now working as intended.

[saberbholt]

On 8/6/2018 at 6:12 PM, Harem Krishna said:

I agree, checks and more info are a nice to have, but this is not Cupertino, it's a <whisper>cheap</whisper> browser-game with finite resources, focused on ROI (where investment is written lowercase and RETURN - but enough of that).

ufff if it could work by timestamps of the server seen as you indicate that it is not a large company with finite resources, and if so I hope you do not give too many problems the automatic change of summer and winter time in Europe.
In the companies where we work, we would never leave charges like this for readings and comparison from the database for performance issues (ram vs hdd or solid state) and for sure use processor of clients without his knowledge with all completly specified in a clear document. Although as you say is a small bussines and doubt that it has 2,000 queries at a time or 200 :-P 

until that typr of filosopy im the code the only think for make the pool of pay was relauch the monthly card 

Edited June 10, 2018 by saberbholt

[ClubNutte]

On 6/10/2018 at 3:30 AM, saberbholt said:

ufff if it could work by timestamps of the server seen as you indicate that it is not a large company with finite resources, and if so I hope you do not give too many problems the automatic change of summer and winter time in Europe.
In the companies where we work, we would never leave charges like this for readings and comparison from the database for performance issues (ram vs hdd or solid state) and for sure use processor of clients without his knowledge with all completly specified in a clear document. Although as you say is a small bussines and doubt that it has 2,000 queries at a time or 200 :-P 

until that typr of filosopy im the code the only think for make the pool of pay was relauch the monthly card 

No, it could not work by timestamps, it does! Maybe HH is not a good example for a POC, but I daresay that its kind of common practice. DST is not a problem at all. Based on the server's location you either need some minor calculations twice a year ($dst_switching_timestamp, I won't go into detail here, its trivial) or simply do nothing (if the server is not affected). I hope, we don't need to discuss the utter irrelevance of the clients' time...

Concerning the company: I don't know its size or wealth. They could be filthy rich. I was talking about the resources (made) available to the project (here: HentaiHeroes). Since I love metaphors, here we go again: They are riding a horse until it dies. Then they continue riding it, until the flesh drops from its bones and there's no one left they can convince to give them money to feed the poor beast. And then they take its little sister, paint it pink, mount a dildo on its forehead and in no time, you see them riding through town again - this time on an Unicorn After the starting period, they won't groom the horse anymore - unless people are throwing bags of gold at them.

Let's see, whether we can apply this picture:

• rising amount of unfixed bugs / autistic behavior towards requests and complaints: bones shining through the hide / carrion-like odour
• absurd frequency of events: frenzied whipping ('Look! It moved! And how much faster could it move, If only we had the money to feed it better!')
• transparency: 'Of course you can pet it. Don't I keep telling you every day that you can pet it tomorrow? Oh, look! A pink elephant...'
• [enter your metaphor here]

(Ok, that was a little off-topic, but the urge was overwhelming )

What I was trying to say: it is not an investment-friendly environment and I don't have the least problem with it (yeah, it sounded differently, so I'll specify: I don't have a problem with the way it is, but with the way it is handled).

Usually, no big red button gets pushed, the lights keep burning and no puppy dies if something goes wrong with pimping some girls in HH. There is no need (and it would be ill advised) to use some over-sophisticated code here (Einstein: 'Make things as simple as possible, but not simpler').

Oh, and I never commented on the amount of queries, but if you insist: I doubt your numbers. Basically, you load the data when the session starts and save it, when the session ends . If we can trust the ToF (moan) there are about a million accounts, some of them dead, not all of them online at the same time - it doesn't need high-end hardware, to keep that in memory).

Cheers

Edit: just want to clarify, that the 'horse'-part was not meant to aim specifically at HH or Kinkoid, but the whole genre as such.

Edited June 11, 2018 by Harem Krishna

[Habi]

9 hours ago, Harem Krishna said:

No, it could not work by timestamps, it does! Maybe HH is not a good example for a POC, but I daresay that its kind of common practice. DST is not a problem at all. Based on the server's location you either need some minor calculations twice a year ($dst_switching_timestamp, I won't go into detail here, its trivial) or simply do nothing (if the server is not affected). I hope, we don't need to discuss the utter irrelevance of the clients' time...

Concerning the company: I don't know its size or wealth. They could be filthy rich. I was talking about the resources (made) available to the project (here: HentaiHeroes). Since I love metaphors, here we go again: They are riding a horse until it dies. Then they continue riding it, until the flesh drops from its bones and there's no one left they can convince to give them money to feed the poor beast. And then they take its little sister, paint it pink, mount a dildo on its forehead and in no time, you see them riding through town again - this time on an Unicorn After the starting period, they won't groom the horse anymore - unless people are throwing bags of gold at them.

Let's see, whether we can apply this picture:

• rising amount of unfixed bugs / autistic behavior towards requests and complaints: bones shining through the hide / carrion-like odour
• absurd frequency of events: frenzied whipping ('Look! It moved! And how much faster could it move, If only we had the money to feed it better!')
• transparency: 'Of course you can pet it. Don't I keep telling you every day that you can pet it tomorrow? Oh, look! A pink elephant...'
• [enter your metaphor here]

(Ok, that was a little off-topic, but the urge was overwhelming )

What I was trying to say: it is not an investment-friendly environment and I don't have the least problem with it (yeah, it sounded differently, so I'll specify: I don't have a problem with the way it is, but with the way it is handled).

Usually, no big red button gets pushed, the lights keep burning and no puppy dies if something goes wrong with pimping some girls in HH. There is no need (and it would be ill advised) to use some over-sophisticated code here (Einstein: 'Make things as simple as possible, but not simpler').

Oh, and I never commented on the amount of queries, but if you insist: I doubt your numbers. Basically, you load the data when the session starts and save it, when the session ends . If we can trust the ToF (moan) there are about a million accounts, some of them dead, not all of them online at the same time - it doesn't need high-end hardware, to keep that in memory).

Cheers

Edit: just want to clarify, that the 'horse'-part was not meant to aim specifically at HH or Kinkoid, but the whole genre as such.

thanks for being persistent with your explanations. i usually give up after the first try as i'm not sure if the consumed time is spent wisely (aka the people needing expanations again and again either can't or don't want to understand).

luckily i don't earn my money with teaching people. that would be a blatant fail and result in my insanity. 

Edited June 11, 2018 by Habi

[saberbholt]

@Harem KrishnaI understood you hahaha, what I was referring to is that as a programmer my philosophy is and always was: that the company that uses the hardware itself and does not do anything or the minimum client, so I did not think they did not calculate the time.
About the number of consultations, as I said, I do not think they'll ever do so many, not even 20 per second (I put 200 because it's a number of maxima I've come to see in Sap S / 4 with some companys).

As you say, is a company that seeks only benefits even at the cost of burning the product and when it fails to change the name of the game, funds, icons, characters and history and come out as "hunting all pokemons."

Edited June 11, 2018 by saberbholt