BTPlusPlus

[Cruque]

Originally Posted by face

Seems the spectate capping is not possible anymore.

Thanks, good to know. Did you test ace-plugin and the general reconnect bug?

Originally Posted by face

1: Possibility to edit the records without restarting server.

edit or delete?

Originally Posted by face

2: The overlapping of the maprecord with timer section as posted with screenshot earlier in this topic.

On my list - low priority.

Originally Posted by face

thx for the good work sofar.

You are welcome.

Originally Posted by luluthefirst

Need a better timer, when I respawn it starts by 2, 3 or 4 seconds, need a fix for this: when we press the fire button to respawn, it musts reset the timer to 0 seconds, and better thing is to show a milliseconds ; I don't know if you can do it. So if peoples have problem with their mouse they don't need to kill theirselves to reset the timer. You understand what I mean?

Short sentence: Reset the timer when the player respawn instead when the player is dying.

You know what I'm coding on? "they don't need to kill theirselves to reset the timer" -> they wouldn't have to suicide if they idled after death/cap.

All I want say is this:

Everybody has to accept that BunnyTrack-Time will be dropped and that all BunnyTrack-Times are unreliable. Reason: BTTime is no correct time measure and not fair.

Example: On FBT-forum there is a thread about a suspicious 1:11 BT-Time cap on ReadyForBunnytrack saying that it is impossible because best official i4G Time in BunnyTrack-Time is 1:12. That is not correct. There is a chance of around 30% that the i4G time is 1:11 in BunnyTrack-Time, else 1:12, so 1:11 is no impossible BunnyTrack-Time and you are puzzled 100% now. Or compare BTTime with the same time-taking rounded to whole seconds: either it is the same or +1 second or -1 second.

[face]

the reconnect bug still works,so our forced suicide mod stays on the server.

About the times. We all know BT timer is about 3 sec away from real time.Yet we do not compare with i4g timer. What we do is look at wr made with BTTimer and if a map has a wr 1:16 and you take 5 sec off and all the best players say that can not be done then i trust them. So that time has to be made with or a bug or a big shortcut.

Anyway would be nice if the BTTimer would be build new lets say i4g standerd so we do not need to recalculate or whatever. In BT++ when you resoawn you actualy lose 3 to 4 sec before you even start to play.

Any fix for that?

[TheDane]

ModifyPlayer works on all pawns that has bIsPlayer=True (PlayerPawn and Bot), it will work each time the player is spawned into the map, so it will also work on reconnect.

[TheDane]

what's the story of : v0.97r7 name?

I honestly find these version names impossibly to remember or keep track of. how about doing a v1 .. then change something and call it v2? man it's so simple even i can keep track of it

[Rush]

Originally Posted by luluthefirst

Fix: The timer now reset when the player respawns.
Added: bInstantRespawnAfterCap, this function respawn the player directly after cap.
Small fix: Player doesn't move anymore when he did cap.

And in conjuction all these guarantee the same respawn as after capping in original bunny track?

[Sp0ngeb0b]

All the original BT times will be corrupt, at the moment you start your run with ~3 secs delay, you cant say that exactly, but with your fix you can no longer compare the times with older versions.

[Rush]

It's totally wrong. 0:01 start time comes from rounding-up. 0:00:1 will get rounded to 0:01. Artificially raising the time up is stupid.

[Cruque]

I am working on it but next release is ready when it is ready.

luluthefirst: new release will bring a new timer starting from spawn. What new insta did you make?






================================================== ==================
================================================== ==================
Why BunnyTrack-Times is not correct and not fair
================================================

What you gonno see on the charts next is:
x = timestamp at cap
y = timestamp at start(death here like in BTTime)
z = resulting TIME

a) how it should be

You see a section of something like an infinite staircase where one step = all runs resulting in the same time. For practice you choose one spot - you can't sit on the walls - and move parallel to the edges = start the run later(up) or earlier(down).
What you see is simple: you allways stay on the same step/time.

b) BunnyTrack-Time

Now look at the chart produced by BunnyTrack-Time. Choose a spot and start the run earlier/later. What you see now is that you either move up or down(except the lines touching corners like the left one) so depending on when you start the very same run, you may get two different BunnyTrack-Times. EDIT: Or in some cases you may do a run almost 1 seconds slower, but starting some other time and get a 1 second improvement.


Further the spawn ain't BT-related and I measured volatile times on it so you can easily loose 0.1 seconds or more and get a higher BTTime through this.

================================================== ==================
================================================== ==================


What's needed now is consens on what time follows BT-Time:

I) call it BT++Time - already implemented -
-same speed as BT-Time
-starting at spawn
-rounded to centiseconds
-similar size as BTTime; on average lower by the duration of spawning (~1 second)

II) i4G time


I don't want i4G - Time because: http://www.i4games.eu/forum/p62744-t...-bt-time#62744
==============

- i4G recs are important to very few
- fake accuracy
- showing captime in realtime (use=?; info of gamespeed = 110% absolutely needed) instead of gametime which is a a general UT-size
- it will be easy and accurate for i4G site to convert to the new BT++ time
- players get an option to show i4G-like captime in the chatarea and console if they need it

Old recs are not very useful because BT-Time is not correct. E.g. BT-Time compared to BT++-Time is this:
EDIT: general problem as moving to more accurate timer


With spawning time = 1 second new time is always lower so keeping old recs and using new BT++Time works and all recs are possible, but breakable with slower runs(furher to the right).


And the same run measured with BT++Time gets up to 2 seconds lower time then.

==> so you want I) or II) / old recs YES/NO ?

[Bloeb]

Cruque, first off all, I think it's great that you've taken over the project. I'm wondering though, since I've never seen you on a BT-server, are you a BT-player yourself or just helping out?

Now, about your timing-mechanisms, do you really want to introduce a third timer-system? From a players-perspective I don't think anyone is interested in a completely new timer-system. It would be more interesting to simply implement the i4g-timer, because it allows players to compare times easily. At the moment the i4g-recs seem to replace the BT-Match-recs. Even better; you could give the server-admins the possiblity to choose between the old BT-timer or the i4g-timer.

Also, I'd like to point out that the BT-community is trying to create a BT3-mod based on previous versions and BT++. I think it would be a good idea to collaborate. Check this topic on BT-Match

[2ndsB4]

respect!
old recs should be converted automatically. the holders will improve them or hunters will beat them if theyre eager enough xD
i find it pretty good of Cruque to try to get away from the i4g timer and i totally support his to do list for the mod!
what would be great to add is to improve the compatibility to the CTF-BT prefix since it attracts the most people to public servers^^

[[rev]rato.skt]

The correct would be the accountant of time of the BT was thus:
minute, second and hundredth


a new compatible project for bt without bugs with ipcontry would be well better and a mutator of votemap that it could searching the map typing the full name or incomplete would be beim more organized and would be very good of if playing
Mapvote Equal to the MapvoteLA13 only added the system of could searching the map typing the full name or incomplete..


If somebody will have courage to face this challenge knows that all community of bt would go to adore!

OBS: BTPlusPlusv097r7 IS BUG Dont is compatible for Botpack.CTFGame

[Cruque]

Hope everyone did read this before posting: http://www.unrealadmin.org/forums/sh...&postcount=170
And please

OBS: BTPlusPlusv097r7 IS BUG Dont is compatible for Botpack.CTFGame

is that a bug-report

-----------------------
BT++ ain't a new time. It is
-BT-Time fixed
-starting at spawn
-as accurate as possible (see below)
=> so just what BT++ players wish for and just a bit lower while i4G is nearly 10% lower

all other get this feature: (textarea + console)

-----------------------
now on i4G time
Now here comes the big assumption:
I got to assume that i4G Time is as simple and plain as described on the forum http://www.i4games.eu/forum/p62744-t...-bt-time#62744.
If so: the only difference between BT++Time and i4G Time is the time dilation (speed of the timer = a simple division/multiplication).

As BT++ was built on BT-Time now moving to i4G time would be at least doubtable.

After asking i4G vs. BT++ time one week ago I'm no way convinced that BT++ players want to see i4G time.
You got to proof that quickly or BT++ time is the new time.

In any case you get a time with centiseconds(this is btw 1 hundreth of a second) - not more and not less - and no option to choose between different times.
And yes it looks good:
http://img20.imagevenue.com/img.php?..._122_384lo.jpg


WHY MILLISECONDS ARE FAKE: (correct me if I'm wrong)
====================================
Level.TimeSeconds is updated every tick, server measures time.
Servers run at 20 ticks per second by default. This means on average every 0.05 seconds real time Level.TimeSeconds increases.
for simplicity take captime in realtime like i4G Time:
-> 20 consecutive ticks for you to make a cap resulting in the same seconds
-> 2 consecutive ticks for you to make a cap resulting in the same deciseconds
Up to this it is all correct to display.
On the scale of centiseconds you skip 4 possible values. But the significant change happens here so it is not all bad to show them.
Adding that ticks ain't all of the same length this opens a new playground for rec-hunters: lucking on centiseconds instead of seconds as it happend with BT-Time.
Moving further down is useless as you move to scales where you skip whole bunches (49/499/...) of possible times and it is fake to display what you can't measure (pretend you can see differences in captimes where you can't).
====================================

A preview on how BT-Time records (seconds; left) would be converted (not yet implemented) to BT++Time/i4G-Time(centiseconds; right)
For all BT-Times it is assumed that they were made with the slowest possible run. The i4G time is rounded up so the time is beatable with the same run.
Don't be confused: if you (correctly) transform the i4G-Time back to BT-Time you get BT-Time + 1 for technical reasons.

i4GT = ceiling(BTT*100/1.1)
BT++T = BTT
e.g 58 seconds BT-Time->  5273 = 52.73 seconds i4G-Time | 58 BT++Time
„  0     0  ?*
¦  1    91  ¦
¦  2    182 ¦
¦  3    273 ¦
¦  4    364 ¦
¦  5    455 ¦
¦  6    546 ¦
¦  7    637 ¦
¦  8    728 ¦
¦  9    819 ¦
¦ 10    910 ¦
¦ 11   1000 ¦
¦ 12   1091 ¦
¦ 13   1182 ¦
¦ 14   1273 ¦
¦ 15   1364 ¦
¦ 16   1455 ¦
¦ 17   1546 ¦
¦ 18   1637 ¦
¦ 19   1728 ¦
¦ 20   1819 ¦
¦ 21   1910 ¦
¦ 22   2000 ¦
¦ 23   2091 ¦
¦ 24   2182 ¦
¦ 25   2273 ¦
¦ 26   2364 ¦
¦ 27   2455 ¦
¦ 28   2546 ¦
¦ 29   2637 ¦
¦ 30   2728 ¦
¦ 31   2819 ¦
¦ 32   2910 ¦
¦ 33   3000 ¦
¦ 34   3091 ¦
¦ 35   3182 ¦
¦ 36   3273 ¦
¦ 37   3364 ¦
¦ 38   3455 ¦
¦ 39   3546 ¦
¦ 40   3637 ¦
¦ 41   3728 ¦
¦ 42   3819 ¦
¦ 43   3910 ¦
¦ 44   4000 ¦
¦ 45   4091 ¦
¦ 46   4182 ¦
¦ 47   4273 ¦
¦ 48   4364 ¦
¦ 49   4455 ¦
¦ 50   4546 ¦
¦ 51   4637 ¦
¦ 52   4728 ¦
¦ 53   4819 ¦
¦ 54   4910 ¦
¦ 55   5000 ¦
¦ 56   5091 ¦
¦ 57   5182 ¦
¦ 58   5273 ¦
¦ 59   5364 ¦
¦ 60   5455 ¦
¦ 61   5546 ¦
¦ 62   5637 ¦
¦ 63   5728 ¦
¦ 64   5819 ¦
¦ 65   5910 ¦
¦ 66   6000 ¦
¦ 67   6091 ¦
¦ 68   6182 ¦
¦ 69   6273 ¦
¦ 70   6364 ¦
¦ 71   6455 ¦
¦ 72   6546 ¦
¦ 73   6637 ¦
¦ 74   6728 ¦
¦ 75   6819 ¦
¦ 76   6910 ¦
¦ 77   7000 ¦
¦ 78   7091 ¦
¦ 79   7182 ¦
¦ 80   7273 ¦
¦ 81   7364 ¦
¦ 82   7455 ¦
¦ 83   7546 ¦
¦ 84   7637 ¦
¦ 85   7728 ¦
¦ 86   7819 ¦
¦ 87   7910 ¦
¦ 88   8000 ¦
¦ 89   8091 ¦
¦ 90   8182 ¦
¦ 91   8273 ¦
¦ 92   8364 ¦
¦ 93   8455 ¦
¦ 94   8546 ¦
¦ 95   8637 ¦
¦ 96   8728 ¦
¦ 97   8819 ¦
¦ 98   8910 ¦
¦ 99   9000 ¦
… 100  9091 ‡

Old Accessed None bug(jamming players UT.log):

ScriptWarning: BTScoreBoard HardcoreMap.BTScoreBoard0 (Function BTPlusPlusv097r7_C.BTScoreBoard.DrawNameAndPing:0A63) Accessed None
ScriptWarning: BTScoreBoard HardcoreMap.BTScoreBoard0 (Function BTPlusPlusv097r7_C.BTScoreBoard.DrawNameAndPing:0AF4) Accessed None

Can someone point the line and/or explain how to read the addresses?

[TheDane]

I don't understand this time measurement with so many digits? how can there be so many digits while the tickrate of the server is WAY slower and therefore the game WILL not update within these many digits? 6 digits of a second ... ?? please enlighten me on the game update frequencies, because the is surely something i missed?

EDIT: And how do you compensate for the players ping if time is controlled each tick? many ticks can pass before the server gets the players input?

[[rev]rato.skt]

Cruque :

You could to arrange to be compatible with Botpack.CTFGame and added the chronometers it of the i4games?

[face]

After asking i4G vs. BT++ time one week ago I'm no way convinced that BT++ players want to see i4G time.
You got to proof that quickly or BT++ time is the new time.


I dunno who you asked but as far as i know at BT match and after asking most of the players on my server.

They do not look at the old BT++ world records anymore.

They look at the I4G time and recalculate that back to BT++.

So they new standard for most players if it comes to world record times is the I4G time because they say and think its more accurate.

Correct them if you think they are wrong.

[[rev]rato.skt]

Then it could only put compatible with Botpack.CTFGame

[TheDane]

Originally Posted by face

They look at the I4G time and recalculate that back to BT++.

So they new standard for most players if it comes to world record times is the I4G time because they say and think its more accurate.

Correct them if you think they are wrong.

unless you post the code that does the time calculation i'll have to go for : BS, they are wrong.

fastest operation will be function Tick(), but it cannot produce measurements below 0.05 second, and that's with ZERO lag from the players = ping 0. Speaking of "World Record" makes me laugh ... i gotta see the code to be convinced of any measurement done more exact than 0.05 * player ping.

[face]

Originally Posted by TheDane

unless you post the code that does the time calculation i'll have to go for : BS, they are wrong.

fastest operation will be function Tick(), but it cannot produce measurements below 0.05 second, and that's with ZERO lag from the players = ping 0. Speaking of "World Record" makes me laugh ... i gotta see the code to be convinced of any measurement done more exact than 0.05 * player ping.

I think they posted it on i4g how to recalculate from i4g time to bt++ and vice versa. Or google it!

[Rush]

Just a random idea .. couldn't calculating speed vectors and location of players make it possible to calculate the "real time" needed to travel between the ticks?

For example we check that in next tick the cap will occur but given the speed vector of the player, the cap could be theoretically done in half the time to the next tick (if the tickrate was 2 times faster) - then we simply scrap the last tick measurement and add 0.025 to the record.

I don't know if i4g does that - but sounds doable.

[TheDane]

except it's based upon the same assumptions that Intel uses for their prcessors to compute: nothing changes ...... say a player decide to change it's movement? what calculation would you recommend to use to predict in what direction and when?

you can only be 100% accurate if you use current location and check for when the player actualy touches the flag.

but again ... IF i could see the code i will be convinced .. but since your dealing with human i bet there is nothing you can code to predict it 100%?