It is currently Wed, 26-09-18, 4:56 GMT

All times are UTC




Post new topic Reply to topic  [ 45 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Time-dilation problem
PostPosted: Mon, 15-06-15, 12:17 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
Here's a thorny problem ... but it has nothing to do with GR, or SR (depending on your POV ;) )

The rendering engine in Celestia can generally deal OK with high-poly situations by reducing the FPS rendered, however when capturing a video snapshot of a "scripted" scene, this causes a dis-connect between the "script-rate" and the "capture-rate".

The net result is:
Unpredictable and non-deterministic results with regards to the captured video (especially if capturing at higher resolutions).
ie. A CELX script which pans the observer's viewpoint thru 60 degrees in 30 seconds in order to capture a specific scene will terminate within 30 seconds of "actual time" even if it takes more than 30 seconds to render the video. For example, on a machine with a slow hard-disk or limited GPU, it may take 90 seconds or more to capture those 30 seconds of video to the hard-disk, however the execution of the CELX script does NOT slow down to match the video capture-rate.

I'm not entirely sure if this is due to a mis-match between script-time and simulation time, or between simulation time and video capture rate (perhaps simply because the rendered FPS has dropped below the video framerate of let's say 25fps).

Is this an unavoidable feature of video-capture which would require a software update or is there already a way (perhaps with a specific CELX method) to "force" the execution of a CELX script to be synchronized correctly with the frame rate of the captured video.

NOTE:
Under normal running conditions, CelX scripts, if coded correctly, will in my experience always execute consistently and deterministically with the render engine (even in high-poly situations where the rendered FPS may drop significantly), however when capturing video this synchronization is lost, and an unpredictable scene will be captured because the CELX script has "raced ahead" of the video-capture.


I hope I've described the situation reasonably clearly and unambiguously.

Regards
CC

PS> I think this has more to do with the amount of time required to capture the video frames, rather than any mis-match between "script-time" and "simulation-time". For example, executing the same script and capturing at 1080p will result in a greater disparity in the captured scene, than capturing at 720p.
YMMV, for example if your machine is always rendering Celestia scenes at 30FPS or higher, and capable of capturing 1080p to disk at real-time rates or better, then you probably haven't encountered this problem.

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Wed, 17-06-15, 9:51 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
I'm assuming that the video-capture functionality in Celestia is provided by some third-party component, and therefore is not integrated in any way with Celestia's render loop, which might explain why this issue arises.
I'm assuming also that this functionality remains as well in Celestia.Sci, so someone (Fridger/Dirkpitt) may care about it.

Here's a quick test script (deleted) to highlight the issue. Feel free to run this script on your machine, and then run again while capturing video. You should notice that the results vary when capturing video. On my machine for example (only when capturing video), the "Script Completed" message is displayed at least 10 of seconds before the final movement is actually completed. This obviously has something to do with the slow down in rendering caused by video capture.
I'd be interested to hear if other's experiences are similar to mine.

CC

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Last edited by chuft-captain on Wed, 24-06-15, 18:38 GMT, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed, 17-06-15, 10:42 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 418
Location: Tuscany, Tyrrhenian Sea
chuft-captain wrote:
I think this has more to do with the amount of time required to capture the video frames, rather than any mis-match between "script-time" and "simulation-time". For example, executing the same script and capturing at 1080p will result in a greater disparity in the captured scene, than capturing at 720p.
YMMV, for example if your machine is always rendering Celestia scenes at 30FPS or higher, and capable of capturing 1080p to disk at real-time rates or better, then you probably haven't encountered this problem.


I agree. for smooth output, the FPS with which the video size resolution is captured and saved with or without compression must be higher than Celestia's FPS scene rendering.

EDIT LATER:
Albeit expensive and not quickly manipolable, for best result should be best to record on external devices, ables to capture the video flux "as it is" on the screen in real time. Desktop clone mode -> send to external recorder.

_________________
Never at rest.
Massimo


Top
 Profile  
 
PostPosted: Wed, 17-06-15, 12:00 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
fenerit wrote:
I agree. for smooth output, the FPS with which the video size resolution is captured and saved with or without compression must be higher than Celestia's FPS scene rendering.

Hi Fenerit,

That's pretty much true, however, it can still be a little hit and miss even under those circumstances, as Celestia adjusts the FPS dynamically in response to the workload "in scene". So, even when the FPS is good, it can vary, and drop below the video capture frame-rate when there's a lot of poly's to render for example.
This results in a jittery video, and/or one in which the rate of time is not constant, and will most likely not match with what a given script would display under normal conditions.

There is a very good and justifiable reason for reducing the FPS of course ... this is mandated by the fact that Celestia is a "real-time" rendering engine, however I submit that when video-capture is in progress the priority becomes the accuracy and quality of the captured video, rather than any real-time requirements.
In this circumstance (video-capture), I believe the solution is to allow (perhaps as an an option) for the engine to "lock" the FPS to the frame-rate selected for the video capture (eg. 24,25, 30fps, etc) as it does not matter whether it displays in real-time in this scenario. The primary focus is to capture a smooth and accurate video (even if this takes 10 minutes).
Note that this effectively turns Celestia into a non-real-time render engine for this purpose, however once captured in this fashion, the video will be guaranteed to play back at the correct speed and with any scripted motions appearing as expected with the correct timing in the final result.
In my experience, it is difficult when video-capture is in progress to get consistent control using non-scripted real-time movements (i.e. with the normal keyboard and mouse controls), especially when the capture rate is slowed by machine resources (or lack thereof).
The solution to this issue, for me ... is to script these movements, however, the script time needs to be "locked" to the video-frame-rate.
eg.
1 second of script/simulation time == 25 frames of video,
or:
1 second of script/simulation time == 30 frames of video,


CC

PS>
I would be interested to know from the DEVs :
1. whether this is also an issue in the current Celestia.Sci code.
2. is it possible to "lock" the FPS to the video frame-rate as I suggest?
3. Is there a motivation amongst the DEV's to fix this?
4. Assuming a solution along the lines of what I'm suggesting has been (or will be) implemented in Celestia.Sci, is it possible in the meantime (prior to the release of Celestia.Sci) to apply the same patch to the original Celestia trunk code as well.

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Wed, 17-06-15, 15:37 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4577
Location: Hamburg, Germany
CC wrote:
PS>
I would be interested to know from the DEVs :
1. whether this is also an issue in the current Celestia.Sci code.
2. is it possible to "lock" the FPS to the video frame-rate as I suggest?
3. Is there a motivation amongst the DEV's to fix this?
4. Assuming a solution along the lines of what I'm suggesting has been (or will be) implemented in Celestia.Sci, is it possible in the meantime (prior to the release of Celestia.Sci) to apply the same patch to the original Celestia trunk code as well.


Hi CC,
it all depends on the available manpower... Currently our highest priority resides on implementing basically NEW features into celestia.Sci, rather than fixing old ones. We want "our baby to walk by itself" rather than producing a vast Celestia update ;-)! Furthermore, at least my video expertise is far from being overwhelming. In the past, I captured a numberr of hires video scenes with .Sci without encountering any awkward slowdowns. Apart from various fixes, the video code in .Sci amounts to a comparably recent video patch in Celestia.SVN.

Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Wed, 17-06-15, 16:47 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
t00fri wrote:
Hi CC,
it all depends on the available manpower... Currently our highest priority resides on implementing basically NEW features into celestia.Sci, rather than fixing old ones. We want "our baby to walk by itself" rather than producing a vast Celestia update ;-)! Furthermore, at least my video expertise is far from being overwhelming. In the past, I captured a numberr of hires video scenes with .Sci without encountering any awkward slowdowns. Apart from various fixes, the video code in .Sci amounts to a comparably recent video patch in Celestia.SVN.

Fridger
Hi Fridger,

I appreciate that you have other priorities. I would actually look into the code myself if my C++ expertise wasn't pretty much zero. I realize also that you've probably not encountered too many issues on your machine, however not everyone is necessarily blessed with strong resources in that respect. (Even on your machine though, I would bet that you cannot capture the exact same video twice in succession, even if scripted.)

Putting aside priorities, what do you think, in principle, of my suggestion regarding "locking the engine FPS to the selected video-FPS? ie. Do you agree with the idea, in principle?
This approach would allow video to be captured in a repeatable (ie. deterministic) fashion regardless of the machine's resources. A lower spec'd machine would just take a lot longer. The current situation will always result in unpredictable and unmanageable results under certain conditions (eg. when high-polycount in the viewport causes a slowdown in the FPS in Celestia's render-engine and/or disc-contention causes a delay in the video-rendering pipeline).

Bear in mind that this is all about having perfect control over the rendering of the video, so that a specific scenario can be scripted and rendered out reliably, and with repeatability, regardless of the real-time performance.

With your knowledge of the underlying rendering engine in general (which I'm sure is good) do you have a "gut feeling" as to whether this is technically feasible, even if it was at some point in the future? --- in which case it might be worth putting on a "todo list".

Also, contributing to the issue for me, is that my current machine only allows me to capture "uncompressed" video:
Attachment:
codecs.jpg
codecs.jpg [ 18.73 KiB | Viewed 3069 times ]
which at 4GB for a 90 second video, is very demanding on resources.
I assume that the compression options presented by Celestia in this dialog depend purely upon which codecs you have installed on the machine. For example on my old XP machine, I had a long list of (mostly useless) codecs:
Attachment:
video-codec.JPG
video-codec.JPG [ 14.89 KiB | Viewed 3069 times ]

I am a little surprised that there are NO compression codecs at all presented on my current machine. As I have various video-editing software installed, I would have expected their codecs to be available to Celestia as well. Can you offer any advice regarding this?

I'm sure that with access to some efficient codecs on my machine, video capture would be less of an issue, although I think there is still merit in the FPS-lock idea because it can in theory guarantee repeatability.

Cheers
CC

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Wed, 17-06-15, 17:04 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4577
Location: Hamburg, Germany
Hi CC,

from what you write, I understand that you are using exclusively a Windows version of Celestia. I must confess that I never did a video capture in Celestia under Windows. At this point, It's not even clear whether your code has implemented all these comparatively recent video fixes in the SVN repository of Celestia?.

Thus at this time, any possible guesses of mine concerning your problem would not be well-founded. Also, we are very busy until July 1st, when Dawoon (Dirkpitt) will get "distracted" ;-) by starting with a new job!

Sorry & cheers,
Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Wed, 17-06-15, 17:51 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 418
Location: Tuscany, Tyrrhenian Sea
chuft-captain wrote:
I am a little surprised that there are NO compression codecs at all presented on my current machine. As I have various video-editing software installed, I would have expected their codecs to be available to Celestia as well. Can you offer any advice regarding this?


Strange enough. I got them through the installation of MediaPlayer Classic, an open source project based upon "old" WMP interface.

Attachment:
codecs.png
codecs.png [ 100.1 KiB | Viewed 3061 times ]

_________________
Never at rest.
Massimo


Top
 Profile  
 
PostPosted: Thu, 18-06-15, 4:12 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
t00fri wrote:
from what you write, I understand that you are using exclusively a Windows version of Celestia. I must confess that I never did a video capture in Celestia under Windows. At this point, It's not even clear whether your code has implemented all these comparatively recent video fixes in the SVN repository of Celestia?.

Thus at this time, any possible guesses of mine concerning your problem would not be well-founded. Also, we are very busy until July 1st, when Dawoon (Dirkpitt) will get "distracted" ;-) by starting with a new job!
Glad to hear that DW has found a job ... hopefully something in the space industry as I know that's what he's interested in.

I think that suggesting this is simply a "Windows" issue is probably a "red-herring". I suspect that if you stress your machine enough (whether it is Linux or OS/X) you will be able to create the conditions which cause this issue.
Firstly, using the script I posted above, capture at 1080p resolution without a compression codec ie. Full Frames (Uncompressed)
If that alone does not replicate the issue, the next step is to replace the Earth scene with a scenario containing a huge number of polys. For example a closely packed fleet of Cham's highly detailed spacecraft models would probably do the job! :shock: (but any high-res models you may have will do)
Then just replace "Sol/Earth" in the following line of the script with the name of one of the craft in the scene:
Code:
objectname = celestia:find( "Sol/Earth" )

The aim is that during the execution of the script, the viewport is filled with enough polygons at some point to cause the FPS in Celestia to drop below the video frame rate. 10-15fps would be a good target.
If you can do this, then I believe you also will see the issue.
Any volunteers? :mrgreen:

fenerit wrote:
Strange enough. I got them through the installation of MediaPlayer Classic, an open source project based upon "old" WMP interface.
Sounds like you have the K-Lite Codec Pack. MediaPlayer Classic is packaged with it (also what I had on my old XP machine).

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Last edited by chuft-captain on Thu, 18-06-15, 8:02 GMT, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu, 18-06-15, 8:01 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4577
Location: Hamburg, Germany
Hi CC,

Quote:
I think that suggesting this is simply a "Windows" issue is probably a bit of a red-herring. I suspect that if you stress your machine enough (whether it is Linux or OS/X) you will be able to create the conditions which cause this issue.


Please note that I did NOT suggest that your problem is simply a Windows issue. But rather, I meant to say that personally, I have never used Windows for video capture and currently have no spare time to dive into a major bug hunt with many unknowns...

Cheers,
Fridger

PS: The video patch in Celestia.SVN refers to Linux in the first place, and thus involves the 'theora' library along with the Ogg/Theora video format that is not well spread in the Windows world. This format is known to be quite efficient, though and may be converted via free web interfaces, if desired. For respective discussions you may consult the Celestia-developers list...

_________________
Image


Top
 Profile  
 
PostPosted: Thu, 18-06-15, 9:25 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
t00fri wrote:
Please note that I did NOT suggest that your problem is simply a Windows issue. But rather, I meant to say that personally, I have never used Windows for video capture and currently have no spare time to dive into a major bug hunt with many unknowns...

Cheers,
Fridger

PS: The video patch in Celestia.SVN refers to Linux in the first place, and thus involves the 'theora' library along with the Ogg/Theora video format that is not well spread in the Windows world. This format is known to be quite efficient, though and may be converted via free web interfaces, if desired. For respective discussions you may consult the Celestia-developers list...

Thanks for the information. Appreciate that, and certainly I'm not asking you to initiate a major bug-hunt at this stage ... it's certainly not productive to start investigating code until the actual scope of the issue is first determined. In order to achieve that, it just requires someone, anyone, who is running Linux and/or OS/X to perform the test(s) I outlined in my previous post.
It doesn't have to be you Fridger if your time is limited, but if you do happen to find a spare half-hour one day ... ;)
If a quick test like this confirms that it affects all 3 platforms, then the case for addressing the issue becomes more substantial, IMO (especially if it occurs in .Sci code).

Cheers
CC

PS>
I could of course build the latest SVN, but it's many years since I built Celestia from trunk. I think I was using VS2010 for this. Is it true that at some point before Chris "retired" from Celestia development, that he started incorporating QT dependent functionality? -- This would mean that past a certain SVN revision level it is no longer possible to build Celestia with M$ tools.
I've only made a brief foray into QT (recent experiments with Cosmographia a few months ago), so I'm sure that this path of action would take me a lot longer than the 1/2 hour or so which would be required for someone who already has an executable on those platforms to perform the tests outlined above.
Confirming the behaviour on the other 2 platforms using legacy Celestia code could be done in 1/2 an hour by anyone with OS/X or Linux using the script I provided above with some high-resolution models (or even better, test it using the more recent Celestia.Sci code ... which would obviously require a small effort from either yourself or DW, at least until Celestia.Sci code is released into the wild.)

I don't think a 1/2 hour represents a "major bug-hunt". In fact I've spent more time talking about it than it took to write that script in the first place.

Regards
CC

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Thu, 18-06-15, 9:53 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4577
Location: Hamburg, Germany
CC, some more info just quickly:
  • yes, Celestia.SVN is Qt based. I suggest to use the latest Qt4 (Qt 4.8.6) libs and the very convenient QtCreator integrated dev tool. Celestia.SVN code doesn't compile with later Qt5.x libs without patching !
  • celestia.Sci is strongly Qt based and builds/runs with the latest Qt5 libs (Qt 5.4.2)
  • we use exclusively QtCreator as a most convenient cross-platform dev tool.
  • Celestia.SVN builds with about 60 warnings (if I correctly remember ;-)) while celestia.Sci builds with NONE.
For Windows, one also needs to have a VS 2010/SR1 Express compiler toolkit installed that is found and used by QtCreator. Celestia.SVN code may build also with a later VS Express (e.g. VS 2013), but then you are on your own (essentially)

Cheers,
Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Thu, 18-06-15, 12:19 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
t00fri wrote:
CC, some more info just quickly:
  • yes, Celestia.SVN is Qt based. I suggest to use the latest Qt4 (Qt 4.8.6) libs and the very convenient QtCreator integrated dev tool. Celestia.SVN code doesn't compile with later Qt5.x libs without patching !
  • celestia.Sci is strongly Qt based and builds/runs with the latest Qt5 libs (Qt 5.4.2)
  • we use exclusively QtCreator as a most convenient cross-platform dev tool.
  • Celestia.SVN builds with about 60 warnings (if I correctly remember ;-)) while celestia.Sci builds with NONE.
For Windows, one also needs to have a VS 2010/SR1 Express compiler toolkit installed that is found and used by QtCreator. Celestia.SVN code may build also with a later VS Express (e.g. VS 2013), but then you are on your own (essentially)

Cheers,
Fridger
Thanks Fridger,

Just out of interest I decided to just now try and do that Qt build.
First, did an SVN Update which puts it at revision 5229.
Then opened the celestia.pro file in QtCreator and then Ctrl-B (Build project "Celestia")

54 issues; 21 warnings; 1 fatal error :
Quote:
00:15:18: Running steps for project celestia...
00:15:18: Configuration unchanged, skipping qmake step.
00:15:18: Starting: "E:\Qt\5.3.2\Tools\QtCreator\bin\jom.exe"
E:\Qt\5.3.2\Tools\QtCreator\bin\jom.exe -f Makefile.Debug
link /LIBPATH:"e:\Qt\4.8.6\lib" /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /MANIFEST /MANIFESTFILE:"obj\celestia.intermediate.manifest" /SUBSYSTEM:WINDOWS "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /VERSION:1.70 /OUT:debug\celestia.exe @C:\...\AppData\Local\Temp\celestia.exe.315668.62.jom
LINK : fatal error LNK1104: cannot open file 'windows/lib/x86\zlib.lib'
jom: E:\SVN\celestiacode\trunk\build-celestia-Desktop_4_8_6-Debug\Makefile.Debug [debug\celestia.exe] Error 1104
jom: E:\SVN\celestiacode\trunk\build-celestia-Desktop_4_8_6-Debug\Makefile [debug] Error 2
00:15:18: The process "E:\Qt\5.3.2\Tools\QtCreator\bin\jom.exe" exited with code 2.
Error while building/deploying project celestia (kit: Desktop 4.8.6)
When executing step "Make"
00:15:18: Elapsed time: 00:00.
(so no celestia.exe created)

Not sure what the issue is here, The zlib.lib file is present in "...\trunk\celestia\windows\lib\x86"

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
PostPosted: Thu, 18-06-15, 12:53 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4577
Location: Hamburg, Germany
First of all: switch to Release build mode! You don't have the debug versions of all libs available. The debug version would e.g. require the use of 'zlibd.lib' that is also available. So something seems to be wrong with your Path assignments since 'zlib.lib' was looked for!?.

Did you place all *.dll versions of the libs into the root dir?


Was QT 4.8.6 found by Qtcreator in the Project section? Are you sure that version 4.8.6 is used rather than Qt 5.3.2 that also seems to be around on your HD?

Fridger

_________________
Image


Top
 Profile  
 
PostPosted: Thu, 18-06-15, 13:20 GMT 
Offline
User avatar

Joined: Fri, 03-04-09, 8:21 GMT
Posts: 219
t00fri wrote:
First of all: switch to Release build mode! You don't have the debug versions of all libs available. The debug version would e.g. require the use of 'zlibd.lib' that is also available. So something seems to be wrong with your Path assignments since 'zlib.lib' was looked for!?.
Done, but still the same error.

t00fri wrote:
Did you place all *.dll versions of the libs into the root dir?
I didn't realize that dll's needed to be relocated. What do you mean by root directory in this context?
    trunk?
    trunk\celestia?
Note that the only DLL's that I appear to have in the entire directory tree are the 3 files in "...\trunk\celestia\windows\dll\x86":
    iconv.dll
    lua5.1.dll
    intl.dll
Are these the ones you mean? Do these have to be relocated prior to the build?
(Surely it would be more appropriate to tell the makefile where to locate them, rather than actually moving them?)
t00fri wrote:
Was QT 4.8.6 found by Qtcreator in the Project section? Are you sure that version 4.8.6 is used rather than Qt 5.3.2 that also seems to be around on your HD?
Yes, as evidenced by the output path: build-celestia-Desktop_4_8_6-Debug
Qt 5.3.2 was installed in order to get QTCreator (if I recall correctly) but I'm building with 4.8.6 :
Attachment:
QtProject Settings for Celestia Build.PNG
QtProject Settings for Celestia Build.PNG [ 81.15 KiB | Viewed 3028 times ]

_________________
CITIZENS OF CM - JOIN THE REVOLUTION
...black out your avatar
THE AVATARS ARE REVOLTING !!!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 45 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group