| Pages: 1 2 3 4 [5] 6 :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
CaseyLance
   |
Posted - 2005.12.11 11:38:00 -
[121]
Ok enough confusion, the formula above works perfectly. My error was to align the measured graph and calcuated graph correctly. Since you cannot measure from cap = 0.
I only checked the formula above with the skill bonuses, but i think this will also go well with module recharge bonuses (don't forget the stacking penalty)
|
masterjob
|
Posted - 2006.03.08 13:57:00 -
[122]
I can't make alot of this..
so can I now calculate when my ship can recharge the best
I really need to see that though
|
masterjob
|
Posted - 2006.03.08 13:58:00 -
[123]
and how can I fill in that formula what exactly must I fill in.. and what do I get to see
if it works?
|
Eat'me
|
Posted - 2006.03.08 14:33:00 -
[124]
Bunch of geeks...all off you 
|
Night Swordstrike
|
Posted - 2006.03.08 15:13:00 -
[125]
Execellent job on the Capacitor recharge rate. I had done some testing as I wanted to figure out DPS my ship could take (by writing a program that takes Cap use, damage type, and resists into account). Your graph is supported by the data I collected.
|
Skravos
|
Posted - 2006.03.22 16:37:00 -
[126]
All these calculations, all these huge brains... I wish it meant something to me besides being involved in a game that I'm not smart enough to play 
|
Detrol
|
Posted - 2006.03.22 22:24:00 -
[127]
Edited by: Detrol on 22/03/2006 22:25:18
It's all in there somewhere but your cap recharge is optimal when it's around 30 percent full... lower then that and cap recharge really starts to hit rock bottom.
Around the 30 percent mark, your cap recharge is roughly 2.5 times your (linearly calculated) cap recharge (being total cap/recharge time)
So if you have 1000 cap size, 100s cap recharge time, you would have a linear recharge of 10 cap/sec.... however, because cap recharge is not linear, around 30 percent your cap recharge will be 2.5 times 10cap/s or around 25 cap/s.
Cap recharge as function of cap level is shown here:
Linky
|
Sepul Marius
|
Posted - 2006.03.23 00:10:00 -
[128]
Fantastic work Dust Puppy. The graphs bear out what I'd noticed in my (admittedly brief) experiences in-game, and back up the tactics I've been using with hard math (complete with graphs, yay!). Now I can worry far less when firing up my shield boosters with 1/3 of my cap remaining.
What would be interesting to see would be a non-skilled comparison of drain/charge rates under the influence of certain long-on modules, like AB's, etc. to see if there is any significant deflection in the #'s. I'd assume not, and that it would still be ideal to use higher-load intermittent mods (reps, boosters, etc.) at about the 30% mark as shown.
-Sepul
t1 modded rifter ftw
|
Myrk Reinhart
|
Posted - 2006.04.18 21:58:00 -
[129]
I love this post
But for practical reasons i always use 2.4 as multiplyer for optimal recharge. Reason for this that 2.5 only excist in a small window while 2.4 is true for a better part of your cap between 30% and 40%.
I never undock any ship at all before i have done calculations on cap usage/recharge for the ship with that current setup. that include EW, guns and all (and pack the ammo you can sustain fireing as primary ammo) (i'm gallente and AM is nice but you need to have enough cap to use it)
CAP IS LIFE.
|
CaseusFeles
|
Posted - 2006.04.18 22:00:00 -
[130]
 Originally by: Mr Raine
woooossssshhhhhh... what was that that went over my head,
This stuff is actually all pretty interesting for a physics student; nice to see that boring electrical properties stuff put to good use.
|
Riebart Norith
|
Posted - 2006.06.22 04:40:00 -
[131]
I guess this may qualify as a bump, but with good reason. I've noticed many people talking about how computationally intensive this is, and they are right. That formula is insanely computationally intensive, compared to something like a third order polynomial. I won't go into detail, but there is really good evidence to suggest that the actual recharge rate is a third order polynomial, since if you plot F(x)=12x(x-1)^2, you get a curve that levels off at 1 (Consider that 100% full), with a recharge rate of zero (As we'd expect, since it is full), and with a max recharge rate at 1/3 = 33.33% which is right around the experienced 30% mark. As well, consider the plot of it's integral, as we see that we get a curve that levels off at 1 (100%), which could represent 100% complete charge. Also, this is much less computationally intensive, and significantly simpler than something involving trig functions.
I don't have any data to back up this wild claim.....yet. I will be running tests and gathering data, but for now all I have is this claim.
Now, in this thread, I could be taken as a heretic (Heck, that's been the case on every one of my other posts), but for now I would be happy to hear some constructive criticism.
Thanks
|
Adila
|
Posted - 2006.06.22 06:31:00 -
[132]
Edited by: Adila on 22/06/2006 06:35:31
Originally by: Matthew
What do you think of this plan? Would it be better to use C as the value at the start of the second, or at the end of the second (i.e. before or after all the drains get taken out)?
IMO you would be better off calculating both and using the smaller value, as pessimistic results are in general more useful.
@the op: high resolution data should be relatively easy to generate. Just write a simple app to record the timing interval of keystrokes and then press a key each time your capacitor ôticksö upà of course this assumes that each tick gives a constant amount of cap, which may be a bad assumption.
Quote:
I've noticed many people talking about how computationally intensive this is, and they are right.
there is no reason that whatever function they are using couldn't be driven acceptably by a relatively small lookup table... given that I donÆt think that computational expense is really a factor.
|
Julie Daichupe
|
Posted - 2006.06.23 16:36:00 -
[133]
Edited by: Julie Daichupe on 23/06/2006 16:44:55
Edited by: Julie Daichupe on 23/06/2006 16:41:16
Well, lookup tables or no, wouldn't it make sense to use a continuous function instead of keeping a ton of lookup tables in memory? I'm sure CCP has better ways of using that RAM than lookup tables for cap recharge rates. Especially considering the huge number of variations given by skills, modules, ships, etc. So, I could be wrong, but I'm going to go ahead and see if this cubic fits anyway.
Edit: Oh, and in case anyone was wondering about resolution (This has probably been posted already, and I just missed it), the ingame cap readout has a resolution of 1 second, and (I believe) it rounds off decimal places. So, the resolution you get for measurements can be no better than 1 second. As for capturing the data at that resolution, shouldn't be hard. I find Jasc PSP works beautifully (Set up an import from screen cap at an interval of 1 second).
Edit2: And the ingame cap readout rounds instead of truncates...I think. I could be wrong. The skill points round, so I only assume the cap does too.....however, that is far more computationally intensive than truncating, so I could very well be wrong.
|
Deren Thaldrel
|
Posted - 2006.06.23 16:57:00 -
[134]
Edited by: Deren Thaldrel on 23/06/2006 16:57:07
This is very interesting, sorry to bump old threads but this is great reading for us n00bs ;). Additionally... is it just me or is the capacitor recharge behaviour nearly identical to shield recharge behaviour? See Pottsey's Passive Shield Tanking Guide
Thoughts?
|
Riebart Norith
|
Posted - 2006.06.26 03:02:00 -
[135]
Hmm, I haven't looked at the Shield recharge at all, but it is possible that it follows the same model. I'll look into it after I satisfy myself with an answer I derive. If my answer agrees with that of Dust Puppy, then I will have no problems saying he beat me to it. However if it differs, I'd be curious as to how much.
|
Riebart Norith
|
Posted - 2006.06.26 04:10:00 -
[136]
Oh, and just a comment to Dust Puppy on his model. Congratulations on all the work, definitely some solid stuff there. Have you had any formal training in calculus at a university or College level? Anyway, onto my real point.
The first thing I'm noticing about his Hyperbolic Cosine solution is that it's inflection point (I.e: Point of maximum recharge) occurs at about 18% charged, as opposed to the observed 30-35% that we observe it at.
I also took some measurements from a nearly empty cap at 1 second intervals and they are nice to get the general shape of the curve, but as for solving things, they are pretty useless since we get integer values only. If there was a way to get even a single decimal place (Consistently) then we'd be laughing and have a 99.8% accurate esitmate. If someone knows of a way, I'd be more than happy to hear.
So, now, here is my proposed solution (And it appears that my previous assumption about the cubic may be somewhat off, but we'll find out more soon): If we denote Y[t] to be our function of time that returns the current cap value (Since that is the only one we can measure, and therefore plot against), T to be the recharge time, and C to be the max cap value when full, then we know the following:
Y[0] = 0 (At 0 seconds after the cap is empty...it is still empty)
Y[T] = C (When it is done recharging, it is full)
Y'[T] = 0 (When it is done recharging, it is momentarily no longer charging, which explains why it takes so long to recharge that last 15%)
Y''[K] = 0 (We get our Inflection point [I.e. point of maximum recharge] at time K seconds after it is empty, and Y[K] = C/3)
There are most likely others, but I'll work with these for now. If anyone else knows of something, please let me know.
From this information, we can solve for 4 constants, and so get ourselves a cubic polynomial.
This is all preliminary, but I figure if someone was going to thinkg of something before me, it would be you guys, so thoughts and ideas are appreciated.
|
Silver Night
|
Posted - 2006.06.26 07:05:00 -
[137]
Think maybe CCP took the hyperbolic function (Capacitor recharge is exponential IRL, but as was mentioned, Hyperbolic is exponential in disguise), and found some nth order polynomial (3rd?) that fit 'well enough' to use for computational reasons? I'm no expert like you all of course, 2nd year physics and math stuff, but that would kinda make sense. Always just figured that cap was exponential, and shield. But I never did check with hard numbers.
You guys are awesome.
--------------
Director.
GLS Mr. State
Caldari Patriot.
Murderer of (his own) Frigates.
|
Dust Puppy
|
Posted - 2006.06.26 09:15:00 -
[138]
Riebart, I have a B.Sc. in Electronic Engineering which involves a fair bit of calculus. Also the peak happens at around 18% time, that is if you would leave the capacitor empty you would notice the peak when about 18% of the recharge time has passed but by then the capacitor will be around 30% full.
Whether I'm right or wrong about the formula is really irrelevant. Actually the chances of me "guessing" the right formula is pretty slim, it must be thousunds of formula that actually fit that curve. The important part is really that this is close enough that it makes no difference, at least not in practice. Well in practice then I guess all you need to know is the maximum possible recharge rate and when it occurs, which people already kind of knew by observation.
Original Mr Floppyknickers sig |
Pottsey
|
Posted - 2006.06.26 09:57:00 -
[139]
ôHmm, I haven't looked at the Shield recharge at all, but it is possible that it follows the same model. I'll look into it after I satisfy myself with an answer I derive.ö
Shields are based on the same module but itÆs not 100% the same. My research shows it peaks out a little higher at x2.5. I am interested and willing to help any research done into shields.
Passive shield tanking guide, click here. |
Riebart Norith
|
Posted - 2006.06.27 00:22:00 -
[140]
Oops, yes, so I see Dust Puppy. Sorry. I keep forgetting that we are looking at a Cap vs. Time graph. But, plugging in we get it at %29-ish charged, as you say in your first post. And I am familiar with the amount of calculus involved in an Engineering degree as I have several friends getting such a degree. I myself am moving ito my third year of Honours Mathematics, so I've got my own mathematical background.
|
Curzon Dax
Caldari
Deep Core Mining Inc.
|
Posted - 2006.12.01 12:48:00 -
[141]
This great wonderful thread that someone just pointed me to shouldn't be allowed to die!
|
Laboratus
Gallente
BGG
Freelancer Alliance
|
Posted - 2006.12.05 00:05:00 -
[142]
I'm impressed.
Good job with the OP.
___
P.S.
Post with your main.
Mind control and tin hats |
The CaPoNe
Cataclysm Enterprises
Dusk and Dawn
|
Posted - 2007.02.24 19:18:00 -
[143]
Nice Thread. :) but i got 2 questions. maybe someone can help me with this.
Originally by: Dust Puppy
tau is 4.8/T => T = average recharge rate
how i can calculate the average Recharge Rate?
since most if the formulas require them. at the mom i use tau=4.8/recharge time.
how bad is my tau?
another question is in borland delphi im do for example for i:= 1 to (recharge time).
but im not able to make value like 710.85 i need to round it up. how bad its for my calcs?
sry for necro. this thread :)
_________________________________________________
Best Regards
The CaPoNe
|
Foolish Bob
Caldari
State War Academy
|
Posted - 2007.05.06 11:27:00 -
[144]
geeky sidebar:
someone might want to double check to make sure, but I was playing around with the cap formula whilst thinking about bonuses, and I suddenly noticed that with a bit of judicious redefining, you can express the recharge rate as a function of time as
Rate=tau*sqrt(Cr^2-Cr^4)
where tau is as defined by OP and Cr is the fraction of Cap that is empty ( (1-C/C0) in OP speak)
which has to my mind three main advantages going for it: first, it's not so intensive to calculate; second it fits the paradigm of how CCP seem to work things out (qv connections and shield hardeners); and finally, it yields a max recharge rate (independant of tau) when your cap is at (1-1/sqrt(2)) (just shy of 30%) capacity which fits with observed facts (always useful when formulating an hypothesis)
anyway, check it out for yourselves. There was no fermat moment of insight so you should be able to get there too but I don't want to risk contaminating the verification, so I'll only give pointers if you're really stumped.
|
000Hunter000
Gallente
Magners Marauders
|
Posted - 2007.06.10 20:56:00 -
[145]
oh brother, i allready had a headache but now i read this thread it's gotten worse LOL!!!!
might try reading (and hopefully comprehencing) this tomorrow again.
CCP, let us pay the online shop with Direct Debit!!!
|
Acacia Everto
|
Posted - 2007.06.11 03:21:00 -
[146]
Edited by: Acacia Everto on 11/06/2007 03:21:11
Originally by: Foolish Bob
geeky sidebar:
someone might want to double check to make sure, but I was playing around with the cap formula whilst thinking about bonuses, and I suddenly noticed that with a bit of judicious redefining, you can express the recharge rate as a function of time as
Rate=tau*sqrt(Cr^2-Cr^4)
where tau is as defined by OP and Cr is the fraction of Cap that is empty ( (1-C/C0) in OP speak)
which has to my mind three main advantages going for it: first, it's not so intensive to calculate; second it fits the paradigm of how CCP seem to work things out (qv connections and shield hardeners); and finally, it yields a max recharge rate (independant of tau) when your cap is at (1-1/sqrt(2)) (just shy of 30%) capacity which fits with observed facts (always useful when formulating an hypothesis)
anyway, check it out for yourselves. There was no fermat moment of insight so you should be able to get there too but I don't want to risk contaminating the verification, so I'll only give pointers if you're really stumped.
Hmm...this formula isn't working quite right for me if I plug in tau as defined on the first page (tau = 4.8/recharge_time), however substituting tau for a simple 4.8 (k as defined by Dust Puppy's initial post) returns 2.399 as a recharge rate. Now 2.4 was originally proposed for the modifier on the average recharge time to find peak regeneration (i.e. 2.4(capacity/recharge_time) = peak regen at 30%). Is this what was intended by your formula? Rather than returning an actual rate in capacitor per second, it would provide a coefficient for the average recharge rate, therefore effectively making the true "recharge rate" in capactor per second 4.8*sqrt(Cr^2-Cr^4)(C0/T), where T is the time for the capacitor to recharge from 0, C0 is capacitor capacity, and Cr is the operation (1-C/C0).
If this was your intention for the formula, I recall that further data had led to the conclusion that 2.5 was the max coefficient at peak capacitor regen. This formula would seem to suggest that 2.4 was indeed the correct peak coefficient. When changing tau to 5 however, the formula returns 2.499, supporting the coefficient suggested earlier.
Please correct me if I'm wrong, as I really would like to learn how this formula works. Some of my statement is conjecture, and I've yet to have study much of the math involved in this thread; I'm currently entering Pre-Calculus.
If I may say, that formula seems much more like something CCP would use (And who wouldn't? It takes much less computation.)
Nice work, and that goes for everyone in this thread. It certainly was an interesting read.
|
Deschenus Maximus
Amarr
Digital Fury Corporation
Digital Renegades
|
Posted - 2007.06.11 05:10:00 -
[147]
I took one look at this, and my brain imploded.
|
tarin adur
Gallente
Einherjar Rising
|
Posted - 2007.06.11 05:13:00 -
[148]
Originally by: Deschenus Maximus
I took one look at this, and my brain imploded.
Lol ditto
|
Acacia Everto
State War Academy
|
Posted - 2007.06.20 03:43:00 -
[149]
Bump...want to see if my guess is correct.
|
Foolish Bob
Caldari
The Shaw
THE R0CK
|
Posted - 2007.08.12 09:55:00 -
[150]
To be clear, my formula is in no way empirical - I was playing with the derivative of the OP's formula and it just kind of popped out. I should also note that I made everything fractional to help make sure that I didn't make any mistakes with the homogeneity of the equation - that's why there's no reference to C0 - should have made that clearer, sorry.
|
| |
|
| Pages: 1 2 3 4 [5] 6 :: one page |
| First page | Previous page | Next page | Last page |