ClubNutte

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: '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'. 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. 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'

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...

Concerning the 1min freeze: it rises from the dead after a minute Due to the careless truncating, 1min actually covers everything between 1:59 an 0:59 Reduction of precision comes at the price of, well, precision... edit: forgot the 1 in 1min

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

Crude, but effective :) thx

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

Hi there, do the event banners in the forum really need to be that big? I think, most users are aware of the current event and it's a little annoying for me to scroll down each time, to get to the first line of relevant info. Another point: I intended to follow the rules, but was too lazy to search for the 'Ideas'-thread. If the rules are still in effect, could you please pin it? Or else update the rules? It's a little confusing... regards

OK, I think it is save to assume, that the left and the top right section of your image are part of the same screenshot, whereas the bottom right section simply serves to illustrate the relation between your- and the girl's level. If I got it right, Fran's profile was merely an example and other profiles are affected as well (=isolate the bug). Did you actually battle Fran, or did you access the profile through the ToF (=different contexts for the ajax-request)? Did you log-out, clean your browser-cache and delete the cookies (=reduce probability of client-sided inconsistencies)? Just a few points, the devs might be interested in and help them, to become more lovable to you. I am clearly not a friend of the ways, the support-/dev-team handles the requests in this forum (>/dev/null), but Chthugha does his best to help. If he should report this glitch to the devs (and - caution! conspiracy theory - this this is not just another symptom of long known inconsistencies in the database), you could help by providing a little more input. @Chthugha: thx for your moderation, but by the looks of the ajax-request/-response, it's most likely not a display bug (but I wouldn't bet on it).

Since I don't load any scripts, that are not really necessary (Firefox + NoScript), I cannot estimate, what statisgeek actually does (besides gathering (your) data). But in spite of Firefox being apparently prone to the 503 witth HH, I rarely get that error. There might be a connection *bkink*

Sorry, I'm not sure I get your point... Could you explain, how the images are related to each other? That's what I get when I open Fran's profile:

Yes, you wrote this several times before, and of course the devs know about it. It simply does not take that long to find an error, we're not talking about several million lines of code. To fix it is a different story - and what happens, if the solution is more costly than you're willing to invest? So, if you are not an official member of the (support) team, it's just hearsay and not an acknowledgment. Proposal: I sign a NDA, you show me the code, I show you the error (or do penitence).

Mojo (victory_points) is not stored in the Hero-object on the client side and I can only guess, how they handle their data on the server (serialized sessions?). That they store the leaderboard data separately is not a crime as such, but this ought to be a snapshot of the hero data at a given time and should not be meddled with (=in sync at the time of an update). Concerning the matchmaking: the rewards are based on the position in the leaderboard. I'll take your point, if the 'old' accounts are out of sync, too.

Just to keep you informed: this 'bug' is about 10 weeks old and I have not yet seen it even acknowledged by anyone of the team (beside Chtugha, who is - no offense - merely a mod).

I'm afraid, you'll have to learn to live with it, then. The real fixes for 503 are all server-sided and require money and/or optimizing of the code. The mere reduction of the amount of requests might already help. For example, currently 'onresize()' triggers a XHR (for the screen ratio). Albeit these requests are tiny, they nonetheless have to be processed by the server (service). In theory, one could run a 'mechanical' DOS attack by attaching a mobile device to a fan or the hub of a wheel

Dunno whether this helps, but have you tried different devices and/or networks? I get an 503 almost exclusively in testing scenarios (weak devices, slow networks).

And yet back again (but ,as promised, no nagging) Since I'm currently applying for a project that requires some ajax skills, I took the liberty to practice a little on your code (just debugging, no hacking involved!). Here are two examples of (h)h_ajax params, that return different results for mojo: 'leaderbord'-mojo (->leaderbord.js): class: TowerOfFame action: leaderboard_change ranking_field: victory_points returns (excerpt): html->WW (inside the html) '+1000'-mojo (->battle.js (->Battle animation code)): class: Battle action: fight who[]: <opponent info> returns (excerpt): J1->victory_points I didn't investigate much further, as I don't have access to your ajax.php, but it should not be too hard, to trace the data from the request-handler back to its source (or, in this case sources SCNR). If you want some more data from my debugging session, don't hesitate to ask (I don't think, a forum is the right place to post this unrequested).

Hi Chthugha, thx for the reply. I hope, you're getting well compensated for the job you're doing here... I know that Jessie did the reorg (I shortly entertained the idea of posting in an obviously wrong board, just to get her attention), I was just referring to my rant about not sending bug-reports by mail, when there are other defined input-channels Back to the problem at hand: as far as I am concerned, you can tell them, that they can stop 'searching'. Even in its early beta state, HH is still a nice, playable game - though (in my opinion) not (yet) worth to spend any money on it. I won't bother the team with childish nagging anymore. It took a little time, but at last I got the hint.

Mine are OK

Would you be so kind as to look into this matter? If you are in need of more info, don't hesitate to ask TLDR; Since march, new users get 1000 phantom Mojo added, by which they are measured in combat resulting in fewer wins with lower rewards and more losses with higher penalties (= less items, experience, affection and mojo) @Chthugha This board looks even more official than the last one

Another guess (and my favorite) is the inconsistency of the entire database. Several profiles seem to be out of sync, simply compare the stats displayed in PvP with those in the corresponding profile. Edit: got one, check Endurance and Harmony (and while your at it: check his position in the leaderboard (6404, me: 12983) and the fat reward for a victory) Ignore this Screenshot, slipped in by accident and I just don't get it deleted...

Thanks again, I do appreciate your moderation, but I'll stick to the standard procedure... Your points are valid - as long as we are talking about some community driven, non-profit project. But this is a commercial product, the vendor provides a channel for suggestions and complaints and - surprise - suggestions and complaints are placed there. There is no room for 'due to the team being so small'-excuses, it's no rocket science to set up notifications for new forum entries (= send a mail to devs). A piece of cake for any advanced user, not to mention a software developer. It's a matter of indifference (if I don't monitor the feedback channels I provide myself) or incompetence (if I am incapable to do so). I hope, you are taking no offense, Chthugha, it's not you I am addressing with my criticism

Thx for the reply, but I do you really think, that issue has gone unnoticed? Maybe a board in the forum could help here, something like 'Support and Bug report'? A glance at the topics from time to time, a little 'acknowledged'-note - or simply a 'F*ck off, bug reporters!'-banner. Honestly, this board here suggests to be the appropriate input channel, @itslarrythecableguy reported the issue two weeks ago, screen-shot and all. It does not seem to be a matter of awareness, but of motivation.

Well, nothing has changed yet... I'm trying to create a highly competitive character, spend my gold on maxing the stats (which are a sad joke compared to the effects of a handful of 'rainbow'-items) and end up as 'mojo-cattle' for the established players. Couldn't they simply display a 'F*ck off, new players!'-banner? The error (it's NOT a bug, but an example of bad design) is that stupid, that I hoped, they would fix it soon - if not out of sheer embarrassment. Do I miss something, or shouldn't the leaderboard-mojo simply be a representation of 'Current Mojo' at a given time? Add 1000 to 'Current Mojo', wait for the next table update, sync the values and DO NOT manipulate the results anymore. It actually takes more effort to make it wrong. Or is it just me being stupid again? What am I missing?

I suspect, there is more behind it. I started the game last monday and I know, that I didn't gather ~2800 Mojo since then, so the 'Current Mojo'-value is bogus. But it is apparently taken into account, when the wins and losses are calculated. Today I lost 28 Mojo against one and gained 15 Mojo against another opponent who both were far over 10.000 positions higher than me in the Mojo-ranking.If this is really due to the wrong 'Current Mojo', it leads to a massive distortion in the whole gameplay, as those who are concerned by this bug will lose more often (facing stronger opponents) and gain less Gold and items (and for those who care: less Mojo). Can somebody confirm this?