Operating G-Force Plat in StandAlone on a XP, SP3 platform.
I have written several scripts and used G-Force from verison 360 in 2007. Recently updated to version 392 in October this year and having problems.
I'm having trouble writing scripts with this later version. Have there been significant changes to this newer version in terms of memory load or commands?
I am unable to get smooth transitions from WaveShape to WaveShape or Flowfield to FlowField, even though I'm allowing plenty of time between each call. The new WaveShape/FlowField will start at the appropirate time, but there's no smooth transition between the two functions, even when plenty of time is allowed. It will appear to jump to the new WaveShape or FlowField rather than morph smoothly.
I tried the SetNextFlowField command to provide plenty of lead time to see if that would help, but to no avail. I'm assuming that if you use the SetNextFlowField command you really don't need to follow up with a SetFlowField command. I tried both variations and didn't get improved results. Is my logic correct?
I am also using jpgs as backgrounds overwhich the G-Force images flow. This look great. I thought this might be loading the CPU (2.4 PIV with 2Gig Memory)), but even when I elimianted the jpg it didn't help.
I sometimes get a Runtime Error (R6025) - pure virtual fuction call, when booting G-Force, at which point it will stop booting and I have to click off the RunTime error notice, up comes the "send or do not send" prompt to Microsoft, and then I'm alble to reboot G-Force. This is an intermittent event, but it happens only when loading G-Force.
I've noticed an even stranger problem when running scripts with version 392. I'm using CNTRL X to start a script. I have to enter this CNTRL X command twice in rapid succession, almost like a double click, to get the script to start running. This double-click problem happens no matter what the X letter or number, and I've tried it even with the most simple scripts. Any guesses here?
I was thinking that the evolution from 360 to 392 might now favor Vista as an OS rather than XP. However, when I instigate changes in WaveShapes, ColorMaps or FlowFields using the Tool Bar, everything works smoothly. I can't understand the problems I'm having with scripts.
I reset the kFlags on sprites from 24583 to 7 to see if this was causing a problem, but again, no correction in the un-even transition problem.
I've checked the Add/Remove Programs in Windows Control Panel to see if possibly I have a conflict betweent he old 360 versin and this new 392, but the control panel shows only this new 392 version installed.
Any ideas?
May I assume there is still no way to use jpgs in a color mode? It's still all black and white jpg/png images, correct?
May I assume the PDur command in the Default.txt file determines the length of all sprite (jpg in my case) and that this cannot be varied in the actual script once set in this Default.txt config file. In other words, putting a new PDur in a script just before or after a StartSprite() command would have no effect on the sprite's length of view. Am I correct in this logic? I would like to vary the times of different jpgs in the script, but this may not be possible as I currently now understand the scripting program.
Thanks for your help and the development of such a great product.
Scripts for Version 392
Moderators: BTT, andy55, b.dwall, juxtiphi
Figured Out Scriptingin Ver 392
I've figured out most of the problems in the previous post, but I would be curious to know what JayPro uses as a separate program to start fresh, i.e. to start from black, each time you start a script.
I was getting into a series of loops until I remembered the killRunningScript/killRunningSprites commands. So I built a separate little program (Control 0) that I loaded before starting the main program script, e.g. Control 1. In that Control 0 script I had all the kill commands to stop the looping, because if you put them at the end of your real program script (Control 1), you have to wait for it to run its full length before you can stop it and start over. The longer your script becomes, the more time is wasted just letting it run its course until it hits those killScript commands.
The double-click/keyboard problem was related to using those kill commands with Control 0, which in turn was related to the next problem.
Figuring out how to start the main program (Control 1) with all the visual elements appearing at exactly the same place each time, i.e. starting from a totally black screen, predicting the placement of the WaveShape as it first appears on the screen, with the FlowField already developed at a predictable point, and with the ColorMap at a predictable selection, is a necessary part of building a script that is dependent on 0:00 time.
So Control 0 had the first WaveShape already in place, and assuming there were no random functions in that WaveShape config file (easily removed), you could determine where the first WaveShape would be when the real program (Control 1) started. Of course, I'm using a WaveShape that has some definite placement parameters.
It so happens I had chosen DT's Birds WaveShape as the opening WaveShape. That little decision was the source of a couple of other problems relating to the previous post.
I had installed an older version of GForce (Version 360) on another computer just to see why I was having so many problems with Version 392. It so happens that DT-Birds will not run on G-Force Version 360. In fact, Version 360 won't even recognize DT-Birds as a valid WaveShape, even though the code in the WaveShape config file says Vers=270.
So I went back to Version 392 to slug it out.
I had questioned whether it was now an advantage to switch to Vista OS, but then realized that Windows 7 will soon be on us, and, according to my sources, there's no way to upgrade from XP to Windows 7.
Thank you Billy.
Even though my scripts are now up and running with GForce, I would appreciate hearing from Jay Pro how he addresses that starting point problem while avoiding the looping problem.
I was getting into a series of loops until I remembered the killRunningScript/killRunningSprites commands. So I built a separate little program (Control 0) that I loaded before starting the main program script, e.g. Control 1. In that Control 0 script I had all the kill commands to stop the looping, because if you put them at the end of your real program script (Control 1), you have to wait for it to run its full length before you can stop it and start over. The longer your script becomes, the more time is wasted just letting it run its course until it hits those killScript commands.
The double-click/keyboard problem was related to using those kill commands with Control 0, which in turn was related to the next problem.
Figuring out how to start the main program (Control 1) with all the visual elements appearing at exactly the same place each time, i.e. starting from a totally black screen, predicting the placement of the WaveShape as it first appears on the screen, with the FlowField already developed at a predictable point, and with the ColorMap at a predictable selection, is a necessary part of building a script that is dependent on 0:00 time.
So Control 0 had the first WaveShape already in place, and assuming there were no random functions in that WaveShape config file (easily removed), you could determine where the first WaveShape would be when the real program (Control 1) started. Of course, I'm using a WaveShape that has some definite placement parameters.
It so happens I had chosen DT's Birds WaveShape as the opening WaveShape. That little decision was the source of a couple of other problems relating to the previous post.
I had installed an older version of GForce (Version 360) on another computer just to see why I was having so many problems with Version 392. It so happens that DT-Birds will not run on G-Force Version 360. In fact, Version 360 won't even recognize DT-Birds as a valid WaveShape, even though the code in the WaveShape config file says Vers=270.
So I went back to Version 392 to slug it out.
I had questioned whether it was now an advantage to switch to Vista OS, but then realized that Windows 7 will soon be on us, and, according to my sources, there's no way to upgrade from XP to Windows 7.
Thank you Billy.
Even though my scripts are now up and running with GForce, I would appreciate hearing from Jay Pro how he addresses that starting point problem while avoiding the looping problem.
Duration of Sprite JPG Images
And I'm still interested to know if it's possible to vary the length of each Sprite JPG Image with the PDur command.
For example, let's assume you have three JPG images you're using in series as a Sprite background. You want the first JPG to last for 5 seconds, the second for 10 seconds and the third for 15 seconds.
It would be nice to specificy the length of each JPG with the PDur command, but that command, as I understand it, is a one-time-only read from the Default.txt file as GForce is loaded.
Can PDur be used to set a different length for each Sprite Image in a single script?
I've figured out a clumsy-work around. Just repeate the lowest common denominator, which in the above example would be 5 seconds. So you would enter two 5-second start commands back to back to get the 10 second appearance of Sprite JPG number two, and three 5-second back to back start commands for Sprite JPG number three. The problem with this work-around is that there is a fade-in, fade-out value assigned to the appearance of the Sprite Images, a necessary element for sure. So it's a little clumsy getting those sequenced Sprite Images not to flicker. And, you soon be at a point where the smallest denominator is 0.5 seconds, and at that point, the work-around is no solution at all.
And, am I still correct in assuming there is no way to have a Sprite Image in full color ... yet. So how did you guys produce those Christmas packages with the Sprite particles moving over a full color Christmas tree ... without using a video key-compositor?
For example, let's assume you have three JPG images you're using in series as a Sprite background. You want the first JPG to last for 5 seconds, the second for 10 seconds and the third for 15 seconds.
It would be nice to specificy the length of each JPG with the PDur command, but that command, as I understand it, is a one-time-only read from the Default.txt file as GForce is loaded.
Can PDur be used to set a different length for each Sprite Image in a single script?
I've figured out a clumsy-work around. Just repeate the lowest common denominator, which in the above example would be 5 seconds. So you would enter two 5-second start commands back to back to get the 10 second appearance of Sprite JPG number two, and three 5-second back to back start commands for Sprite JPG number three. The problem with this work-around is that there is a fade-in, fade-out value assigned to the appearance of the Sprite Images, a necessary element for sure. So it's a little clumsy getting those sequenced Sprite Images not to flicker. And, you soon be at a point where the smallest denominator is 0.5 seconds, and at that point, the work-around is no solution at all.
And, am I still correct in assuming there is no way to have a Sprite Image in full color ... yet. So how did you guys produce those Christmas packages with the Sprite particles moving over a full color Christmas tree ... without using a video key-compositor?
-
JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
I'm not a big maven on scripting (config scripting/engineering is my thing); but I do believe that PDur works only with those effects in the WaveShapes folder that are created specifically to be Particles. I don't believe Sprites of any sort can be manipulated via the aforementioned parameter.
And unfortunately, there's no support for integrating photo sprites in their original colors.
I hope I'm accurate in these. Again, scripting in this context isn't my strong suit.
And unfortunately, there's no support for integrating photo sprites in their original colors.
I hope I'm accurate in these. Again, scripting in this context isn't my strong suit.
"God is syntax."