From: Tamas T. <te...@cs...> - 2004-03-21 18:39:51
Attachments:
timer.cpp
|
Does what is says on the tin, getSunPhi and getSunTheta give the direction of the sun at a given time. centurion |
From: <red...@pr...> - 2004-04-06 21:36:22
|
Hi all, > [is it considered ill manners not to write something on the top of an e-mail?] <RK> I dont think so. > Precision: float is inaccurate, but if there won't be lots of DateTime instantiations that will run for a long time aside one another, I can see no problem with double (in)accuracy or using an integer seconds value separately from the fractional part; during a game year at 100 time updates per game second <4E9 increases happen, producing something like a 100 seconds error in total, which is irrelevant if there is nothing to compare with. <RK> You are right in that, but I prefer to think of it for Xenocide as a timestep. (Interpreted as a second, that is the current needed resolution). > Doesn't matter, your call, microseconds used as minimal values (UInt32 isn't enough even for 10 ms units). <RK> Using microseconds is far too much for our needs (that is a high resolution timer :D )... we are ok using seconds. > > A fully implemented (gaudy) calendar is IMHO completely unnecessary, we > >only need it to show the user amounts of time, and only in usual terms. So > >all constants went private, but stayed static (why create unnecessary > >instants of them every time a DateTime is created). I was thinking on in gaudy calendar terms when I gave you the links, but in posible localization needs, thats why the conversions should be virtual (for instance in here que use pretty diferent ways to write the string version of the daytime) > Am I correct in thinking DateTime will be instantiated 1)as the game clock and 2)as workshop/arrival date holder only? Mhh probably nope. We may have other uses for it, that includes event initiation times, posibly stored on the data structures used for information holding. That includes UI things like the one needed on the planetview, etc. It is a general time helper class. Thats why I pointed to those DateTime classes the most interesting stuff is the add, diference, and that functionality. > To use OGRE's PI value I have to know where it will be, and I don't have the slightest idea. I will handle that then before committing the sources. Greetings Red Knight |
From: <red...@pr...> - 2004-04-08 17:31:19
|
> How do we plan on updating interceptor/UFO flight paths? They would jump > a lot if updated every second, or would we map a new flight path for them > to follow each second and have them "fly" in between intervals? > > -chrisp The position interval is just a simulation step ( there is no time involved ) as the simulation timestep use a high resolution time tracker that do not involve the knowledge of seconds, let alone days or string representation of it. However it is important to find a map between the simulation time for events such as crash lands (if we ever track them down) or the actual time for lighting in the battlescape or the sun lighting in the planetscape (everywhere when a high resolution timer is either not necesary or not suitable for the task). Greetings Red Knight |
From: Tamas T. <te...@cs...> - 2004-04-08 19:26:40
Attachments:
iaircraft.rar
|
Attached is a version of IAircraft with the soldier hold that's not necessarily a rectangle (no way of initializing one yet, though), like the Ultimate Craft in one of the equipping concept pics; additionally, 'personnel' and 'hullOccupancy' now cross-reference each other, which makes things faster (at least with non-rectangle hulls) but needs more memory. So I'd like to know whether it's ok or the memory will be the bottleneck with idle CPU time present. To the flight path update question: if the TimeDate has appropriate resolution, then it can be updated during each frame (.1 milliseconds resolution at 100 fps = 1% discrepancy between rounded simulation time and real time, I doubt anybody would notice). centurion |
From: <red...@pr...> - 2004-04-08 22:02:34
Attachments:
iaircraftnew.h
|
> Attached is a version of IAircraft with the soldier hold that's not > necessarily a rectangle (no way of initializing one yet, though), like the > Ultimate Craft in one of the equipping concept pics; additionally, > 'personnel' and 'hullOccupancy' now cross-reference each other, which > makes things faster (at least with non-rectangle hulls) but needs more > memory. So I'd like to know whether it's ok or the memory will be the > bottleneck with idle CPU time present. Forget about both CPU efficience and or memory consumption efficiency, what we really need is coding efficiency so an easy, well designed interface is what we should aim to. I am sending a very simplified version (took out a lot of code just for showing the most important concepts). I think we should start from here following the same guidelines, to define the interface in that way. Always aim for programmers/debug convenience, dont use strange flags, very meaningful names, etc. You choosed very experimental code to implement, as not much interface work had been done with it yet. You shouldnt waste your time implementing unfinished interfaces. I can assure you the one that I proposed to implement is near final, so you can implement it. For interface work, you should put toghether and interface, submit it for discussion in the list (dont even write a line of code, cause it will change - I assure you ;) ). And only after is agreed on, start doing the implementation work. We work faster that way, the problem is not much people is doing interface definition and some very important (very basic) classes are not ready so most code cannot even get into CVS after those classes are (even if in dummy form). Greetings Red Knight |
From: Cpt. B. <cpt...@pr...> - 2004-04-08 22:51:05
|
Are we going to institute an Engine class as well as an Armor class? It might be good for future-proofing. Should the data file for crafts contain size/shape of the hold as well? Currently I just have amounts for smallunits (operatives), largeunits (xcaps), and equipment (toys). What about for alien crafts? On a related topic, should the data file contain size/shape of weapon points too? -The Captain -----Original Message----- From: xen...@li... [mailto:xen...@li...] On Behalf Of Tamas Terpai Sent: April 8, 2004 12:26 PM To: xen...@li... Subject: [Xenocide-programming] non-rectangle aircraft holds Attached is a version of IAircraft with the soldier hold that's not necessarily a rectangle (no way of initializing one yet, though), like the Ultimate Craft in one of the equipping concept pics; additionally, 'personnel' and 'hullOccupancy' now cross-reference each other, which makes things faster (at least with non-rectangle hulls) but needs more memory. So I'd like to know whether it's ok or the memory will be the bottleneck with idle CPU time present. To the flight path update question: if the TimeDate has appropriate resolution, then it can be updated during each frame (.1 milliseconds resolution at 100 fps = 1% discrepancy between rounded simulation time and real time, I doubt anybody would notice). centurion |
From: <red...@pr...> - 2004-04-10 03:38:52
|
> Are we going to institute an Engine class as well as an Armor class? It > might be good for future-proofing. Well having an Engine class wont be anything bad at all, cause we can offload the problem of getters/setters of velocity-fuel-etc and maybe some simulation (who knows) into the Engine class. I say that we can try to see how it works out. Any other idea? > Should the data file for crafts contain size/shape of the hold as well? > Currently I just have amounts for smallunits (operatives), largeunits > (xcaps), and equipment (toys). What about for alien crafts? Do you have any idea for this kind of thing? I created a uniform container based system for storing things (with position aware interface and positionless interface too). Do you have an XML entity idea of what would be needed? BTW Cpt. if you want to define the data needed for the diferent Object interfaces, then go for it cause they will then coded in C++ or offloaded to a loader. In that case we already have the loading code, and even if it not we will have a guideline for entity object design. (XML can be very Object Oriented if well crafted). Greetings Red Knight > > On a related topic, should the data file contain size/shape of weapon > points too? > > -The Captain > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Tamas Terpai > Sent: April 8, 2004 12:26 PM > To: xen...@li... > Subject: [Xenocide-programming] non-rectangle aircraft holds > > Attached is a version of IAircraft with the soldier hold that's not > necessarily a rectangle (no way of initializing one yet, though), like > the > Ultimate Craft in one of the equipping concept pics; additionally, > 'personnel' and 'hullOccupancy' now cross-reference each other, which > makes things faster (at least with non-rectangle hulls) but needs more > memory. So I'd like to know whether it's ok or the memory will be the > bottleneck with idle CPU time present. > To the flight path update question: if the TimeDate has appropriate > resolution, then it can be updated during each frame (.1 milliseconds > resolution at 100 fps = 1% discrepancy between rounded simulation time > and > real time, I doubt anybody would notice). > > centurion > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > |
From: Cpt. B. <cpt...@pr...> - 2004-04-11 01:36:30
|
Hi RK, >> Should the data file for crafts contain size/shape of the hold as well? >> Currently I just have amounts for smallunits (operatives), largeunits >> (xcaps), and equipment (toys). What about for alien crafts? >Do you have any idea for this kind of thing? I created a uniform container >based >system for storing things (with position aware interface and positionless >interface too). Do you have an XML entity idea of what would be needed? I started to do this, but I couldn't come up with anything for non-rectangular shapes (specifically, the belt area on a combat unit). The idea suggested (I don't remember if it was you or centurion) about defining a rectangle, and then flagging specific coordinates as unavailable would work. >BTW Cpt. if you want to define the data needed for the diferent Object >interfaces, then go for it cause they will then coded in C++ or offloaded >to a >loader. In that case we already have the loading code, and even if it not >we >will have a guideline for entity object design. (XML can be very Object >Oriented if well crafted). I've got most of the data outlined...I'll start posting the layouts as I finish the documentation. Some of the layouts (items, specifically) are quite complicated, and probably unreadable without the docs. -The Captain > > -----Original Message----- > From: xen...@li... > [mailto:xen...@li...] On Behalf Of > Tamas Terpai > Sent: April 8, 2004 12:26 PM > To: xen...@li... > Subject: [Xenocide-programming] non-rectangle aircraft holds > > Attached is a version of IAircraft with the soldier hold that's not > necessarily a rectangle (no way of initializing one yet, though), like > the > Ultimate Craft in one of the equipping concept pics; additionally, > 'personnel' and 'hullOccupancy' now cross-reference each other, which > makes things faster (at least with non-rectangle hulls) but needs more > memory. So I'd like to know whether it's ok or the memory will be the > bottleneck with idle CPU time present. > To the flight path update question: if the TimeDate has appropriate > resolution, then it can be updated during each frame (.1 milliseconds > resolution at 100 fps = 1% discrepancy between rounded simulation time > and > real time, I doubt anybody would notice). > > centurion > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xenocide-programming mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenocide-programming > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xenocide-programming mailing list Xen...@li... https://lists.sourceforge.net/lists/listinfo/xenocide-programming |
From: Tamas T. <te...@cs...> - 2004-04-14 07:55:23
Attachments:
carrier.rar
|
Thinking about it, making ICombatants ICarriables isn't terribly unreal, and would make IAircraft simpler (and only posiible problem is with names, as an ICombatant would have an ICarrier name and an ICarriable name). So ICarrier would have to handle non-rectangle containers (btw where is the positionless interface? couldn't find it, so I've put in my own idea in the attachment). To engines, will we have a simplified way of handling it (engine determines max speed, acceleration, everything), or make things dependent on both the engine and the craft (say, fuel capacity is not something logically bound to the engine)? centurion |
From: <fl...@ma...> - 2004-03-21 23:54:48
|
Aoid using plain C implementations. Having those helper functions will be very useful when doing the lighting positioning so you should repackage them in an appropriate abstraction. Greetings Red Knight > Does what is says on the tin, getSunPhi and getSunTheta give the direction > of the sun at a given time. > > centurion |
From: Tamas T. <te...@cs...> - 2004-04-04 13:52:01
|
Like this? |
From: Red K. <red...@pr...> - 2004-04-05 00:47:23
|
I2luY2x1ZGUgPHV0aWxpdHkvY29tbW9uLmg+DQ0KI2luY2x1ZGUgPGNvbW1vbi94ZW5vcmVxdWlz aXRlcy5oPg0NCm5hbWVzcGFjZSBYZW5vY2lkZQ17DQoNCmNsYXNzIERhdGVUaW1lDQp7DQpwdWJs aWM6DQoNCiAgIERhdGVUaW1lICgpOw0KICAgRGF0ZVRpbWUgKCBjb25zdCBEYXRlVGltZSYgZGF0 ZVRpbWUgKTsNCiAgIERhdGVUaW1lICggVUludDggZGF5LCBVSW50OCBtb250aCwgVUludDMyIHll YXIsIFVJbnQzMiB0aW1lSW5NaWxsaXNlY29uZHMgKTsNCiAgIERhdGVUaW1lICggVUludDggZGF5 LCBVSW50OCBtb250aCwgVUludDMyIHllYXIsIFVJbnQzMiBtaWxsaXNlY29uZCwgVUludDggc2Vj b25kLCBVSW50OCBtaW51dGUsIFVJbnQ4IGhvdXIgKTsgICANCg0KICAgVUludDMyIGdldE1pbGxp c2Vjb25kICgpIGNvbnN0Ow0KICAgVUludDggZ2V0U2Vjb25kICgpIGNvbnN0Ow0KICAgVUludDgg Z2V0TWludXRlICgpIGNvbnN0Ow0KICAgVUludDggZ2V0SG91ciAoKSBjb25zdDsNCg0KICAgVUlu dDggZ2V0RGF5ICgpIGNvbnN0Ow0KICAgVUludDggZ2V0TW9udGggKCkgY29uc3Q7DQogICBVSW50 MzIgZ2V0WWVhciAoKSBjb25zdDsNCg0KICAgSW50MzIgY29tcGFyZSAoIGNvbnN0IERhdGVUaW1l JiBkYXRlVGltZSApIGNvbnN0Ow0KICAgc3RhdGljIEludDMyIGNvbXBhcmUgKCBjb25zdCBEYXRl VGltZSYgZmlyc3QsIGNvbnN0IERhdGVUaW1lJiBzZWNvbmQgKTsNCiAgIA0KICAgVUludDMyIGdl dFRpbWVJbk1pbGxpc2Vjb25kcyAoKSBjb25zdDsNCiAgIFVJbnQzMiBnZXRNaWxsaXNlY29uZHNT aW5jZSAoIGNvbnN0IERhdGVUaW1lJiBkYXRlVGltZSApIGNvbnN0Ow0KDQogICBTdHJpbmcgdG9T dHJpbmcgKCk7DQoNCn07DQoNCmNsYXNzIFN1bk9yYml0Q2FsY3VsYXRvcg0Kew0KcHVibGljOg0K DQogICBTdW5PcmJpdENhbGN1bGF0b3IgKCBSZWFsIHJhZGl1cyApOw0KICAgdmlydHVhbCB+U3Vu T3JiaXRDYWxjdWxhdG9yICgpOyANCg0KICAgVXRpbGl0eTo6VmVjdG9yMzxSZWFsPiBnZXRTdW5Q b3NpdGlvbiAoIGNvbnN0IERhdGVUaW1lJiBkYXRlVGltZSApOw0KDQp9Ow0KDQ0KfSAvLyBYZW5v Y2lkZQ== |
From: Tamas T. <te...@cs...> - 2004-04-05 18:06:05
|
No defines as I am confused about where will these really go. centurion |
From: Red K. <red...@pr...> - 2004-04-05 18:46:47
|
I2luY2x1ZGUgPHV0aWxpdHkvY29tbW9uLmg+DSNpbmNsdWRlICJ4ZW5vY2lkZS9zcmMvY29tbW9u L3hlbm9yZXF1aXNpdGVzLmgiDQ0KLy8gPFJLPiBXYXRjaCBvdXQgeW91IGhhdmUgc2VyaW91cyBw cm9ibGVtcyB3aXRoIGVuZCBsaW5lcywgZWl0aGVyIHlvdXIgZWRpdG9yIG9yIHlvdXIgbWFpbCBj bGllbnQgaXMNLy8gY29ycnVwdGluZyB0aGUgZmlsZXMgc28gSSBnZXQgb25lIGxpbmUgYW5kIGFu IGVtcHR5IGxpbmUgYWZ0ZXIgdGhhdCBvbmUuIChmb3IgYWxsIGxpbmVzKSA8Uks+DW5hbWVzcGFj ZSBYZW5vY2lkZQ17DQ0KLy8gPFJLPiBUYWtlIGEgbG9vayBhdCBoZXJlIHlvdSB3aWxsIGZpbmQg c29tZSBpbnRlcmVzdGluZyBpZGVhczoNCi8vIGh0dHA6Ly9vc3Muc29mdHdhcmUuaWJtLmNvbS9p Y3UvdXNlcmd1aWRlL2RhdGVDYWxlbmRhci5odG1sI2NhbA0KLy8gQW5vdGhlciBnb29kIHNvdXJj ZSBpcyB0aGUgSmF2YSBvciAuTkVUIEFQSSBmb3IgYSB3ZWxsIGRvbmUgQ2FsZW5kYXIvRGF0ZVRp bWUgDQovLyBPT1AgY29ycmVjdCBzb2x1dGlvbi4NCg0KY2xhc3MgRGF0ZVRpbWUNCnsNCnB1Ymxp YzoNDQoJRGF0ZVRpbWUoUmVhbCB0aW1lKTsNDQoJRGF0ZVRpbWUoY29uc3QgRGF0ZVRpbWUmIGRh dGVUaW1lKTsNDQoJRGF0ZVRpbWUoVUludDMyIHllYXIsIFVJbnQ4IG1vbnRoLCBVSW50OCBkYXks IFVJbnQ4IGhvdXIgPSAwLCBVSW50OCBtaW51dGUgPSAwLCBSZWFsIHNlY29uZCA9IDApOw0NCgl2 aXJ0dWFsIH5EYXRlVGltZSgpOw0NCg0vLyBBbGwgdGhpcyBpcyBub3Qgc3VwcG9zZWQgdG8gYmUg ZWl0aGVyIHN0YXRpYyBub3IgcHVibGljLg0vLyBFbmNhcHN1bGF0ZSBpdCBpbiBhIHZpcnR1YWwg Y2FsbCBpbiBhIHByb3RlY3RlZCBmdW5jdGlvbiBpZiBpbnNpZGUgeW91IHdhbnQgdG8gdXNlIA0v LyBhbiBzdGF0aWMgdmFyaWJsZSB0byBoYW5kbGUgaXQsIGl0IGlzIHVwIHRvIHlvdSBidXQgdGhl cmUgaXMgbm8gcG9pbnQsIG5vciBPT1AgdmFsaWQNLy8gcmVhc29uIHRvIGRvIGl0IHRoaXMgd2F5 LiA8Uks+DQ0gICAvLyBhbGwgdGltZSBpcyBpbiBzZWNvbmRzIGFmdGVyIGJlZ2lubmluZyBvZiBO ZXcgWWVhciBEYXkgbnVsbFllYXINCXN0YXRpYyBjb25zdCBVSW50MzIgbnVsbFllYXI7DQkvLyBk YXkgb2Ygd2VlayBhdCAxc3QgSmFuIG51bGxZZWFyDQlzdGF0aWMgY29uc3QgVUludDggbnVsbFdl ZWtEYXk7DQlzdGF0aWMgY29uc3QgVXRpbGl0eTo6U3RyaW5nIG1vbnRoTmFtZXMgWzEyXTsNCXN0 YXRpYyBjb25zdCBVdGlsaXR5OjpTdHJpbmcgbW9udGhOYW1lTmlja3MgWzEyXTsNCXN0YXRpYyBj b25zdCBVdGlsaXR5OjpTdHJpbmcgd2Vla0RheU5hbWVzIFsxMl07DQlzdGF0aWMgVUludDggc3Rk TW9udGhMZW5ndGhzIFsxMl07DQlzdGF0aWMgVUludDggZXh0TW9udGhMZW5ndGhzIFsxMl07DSAg IFVJbnQ4ICgqbW9udGhMZW5ndGhzKVsxMl07DQ0KCXN0YXRpYyBCb29sIGlzRXh0ZW5kZWRZZWFy KFVJbnQzMiB5ZWFyKTsNDQoJdm9pZCBzZXRBY3RpdmVNb250aHMoY29uc3QgVUludDMyIHllYXIp Ow0NCglzdGF0aWMgVUludDMyIG51bWJlck9mRGF5cyhVSW50MzIgeWVhcik7DS8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8NCg0NCi8vIDxSSz4gVGhvc2UgYXJl IHZhbGlkIGZpZWxkcyBmb3IgYSBkYXRldGltZSBldmVuIGlmIHlvdSB1c2UgYW4gVVRDIHZhbHVl Lg0KCVVJbnQ4IGdldFNlY29uZCgpOw0JVUludDggZ2V0TWludXRlKCk7DQlVSW50OCBnZXRIb3Vy KCk7DQlVSW50OCBnZXREYXkoKTsNCVVJbnQ4IGdldERheU9mV2VlaygpOw0JVUludDggZ2V0TW9u dGgoKTsNCVVJbnQzMiBnZXRZZWFyKCk7DQ0KDS8vIDxSSz4gWW91IGhhdmUgdG8gYXZvaWQgdXNp bmcgcmVhbCBudW1iZXJzIGZvciB0aW1lcywgYmVjYXVzZSB0aGV5IGFyZSBsb3NpbmcgDQovLyBw cmVjaXRpb24gYXMgbG9uZyBhcyB0aGV5IHJ1biwgaXQgaXMgYmV0dGVyIHRvIHVzZSBhbiBpbnRl Z2VyIG51bWJlciB0aGF0IGhhcw0KLy8gYSBmaXhlZCBzdGVwIGJldHdlZW4gdmFsaWQgbnVtYmVy cy4NCgl2b2lkIGFkZFRpbWUoUmVhbCBleHRyYVRpbWUpOw0NCi8vIDxSSz4gVGhvc2UgYXJlIGNv bXBsZXRseSBwcml2YXRlIGZ1bmN0aW9ucy4NCi8vIDxSSz4gVGhvc2UgaGF2ZSB0byBiZSB2aXJ0 dWFsIHNvIHlvdSBjYW4gbG9jYWxpemUgbGF0ZXIgaWYgbmVlZGVkLCBCVFcgZmluZCBiZXR0ZXIg bmFtZXMgZm9yIHRoZW0NICAgVXRpbGl0eTo6U3RyaW5nIGludGVnZXJUb1N0cmluZyhVSW50MzIg bnVtYmVyKTsNCVV0aWxpdHk6OlN0cmluZyBpbnRlZ2VyVG9GaXhTaXplZFN0cmluZyhVSW50MzIg bnVtYmVyLCBVSW50OCBzaXplKTsNCVV0aWxpdHk6OlN0cmluZyBnZXROYW1lT2ZPcmRpbmFsKFVJ bnQ4IG51bWJlcik7DS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vDQoN Cg0vLyA8Uks+IFRob3NlIGhhdmUgdG8gYmUgdmlydHVhbCBzbyB5b3UgY2FuIGxvY2FsaXplIGxh dGVyIGlmIG5lZWRlZA0gICAvLyBNb25kYXkgNXRoIEFwcmlsIDIwMDQgMTg6NTU6NDMNCVV0aWxp dHk6OlN0cmluZyBnZXRGdWxsVGltZVN0cmluZygpOw0JLy8gTW9uZGF5IDV0aCBBcHJpbCAyMDA0 DQlVdGlsaXR5OjpTdHJpbmcgZ2V0RnVsbERhdGVTdHJpbmcoKTsNCS8vIDE4OjU1OjQzDSAgIFV0 aWxpdHk6OlN0cmluZyBnZXRUaW1lU3RyaW5nKCk7DQkvLyA1IEFwciAyMDA0DQlVdGlsaXR5OjpT dHJpbmcgZ2V0U2hvcnREYXRlU3RyaW5nKCk7DQ0KLy8gPFJLPiBZb3UgaGF2ZSB0byBhdm9pZCB1 c2luZyByZWFsIG51bWJlcnMgZm9yIHRpbWVzLCBiZWNhdXNlIHRoZXkgYXJlIGxvc2luZyANCi8v IHByZWNpdGlvbiBhcyBsb25nIGFzIHRoZXkgcnVuLCBpdCBpcyBiZXR0ZXIgdG8gdXNlIGFuIGlu dGVnZXIgbnVtYmVyIHRoYXQgaGFzDQovLyBhIGZpeGVkIHN0ZXAgYmV0d2VlbiB2YWxpZCBudW1i ZXJzLg0gICBSZWFsIGdldFRpbWVWYWx1ZSgpOw0KDQovLyA8Uks+IENvbXBhcmluZyB0d28gdGlt ZXMgaXMgYW4gaW1wb3J0YW50IHRhc2ssIEkgc2hvdWxkIHB1dCBpdCBiYWNrLg0KLy8gPFJLPiBU aGUgc2FtZSB0byBhZGQgYW5kIGdldCBhIGRpZmZlcmVuY2Ugb2YgdHdvIGRhdGV0aW1lcy4NCiAg IA0KcHJpdmF0ZToNLy8gPFJLPiBZb3UgaGF2ZSB0byBhdm9pZCB1c2luZyByZWFsIG51bWJlcnMg Zm9yIHRpbWVzLCBiZWNhdXNlIHRoZXkgYXJlIGxvc2luZyANCi8vIHByZWNpdGlvbiBhcyBsb25n IGFzIHRoZXkgcnVuLCBpdCBpcyBiZXR0ZXIgdG8gdXNlIGFuIGludGVnZXIgbnVtYmVyIHRoYXQg aGFzDQovLyBhIGZpeGVkIHN0ZXAgYmV0d2VlbiB2YWxpZCBudW1iZXJzLg0KCVJlYWwgdGltZVZh bHVlOw0NCn07DQ0KDQ0KfSAvLyBYZW5vY2lkZQ== |