View Full Version : PgcEdit 8.0 beta discussion thread
r0lZ
5th December 2006, 19:05
PgcEdit v8.0 final is now released. See the new PgcEdit v8 thread (http://forum.doom9.org/showthread.php?t=121146).
PgcEdit v8.0 beta 2
If you want to test it, download it here (http://download.videohelp.com/r0lZ/pgcedit/beta/).
Of course, use it at your own risk.
See the history in the Help menu for the changelog.
Please report the bugs in this thread. Thanks.
Garambone
5th December 2006, 22:33
Thank you very much for this major release! Can't wait to test the new functionalities. Great tool!
So, I've just tested the "Delete Uncalled PGCs" function on Seinfeld S7. It found 17 uncalled PGCs and seems to work perfectly. The DVD structure is absolutely clean now!
However the Time Map Rebuild function seems to be unable to fix the 2 uncongruencies found on VTS 2 and 3. Everytime I run the verification plugin, it accuses these wrong TMAPS. I FixVTSed the whole DVD and it didn't change.
r0lZ
6th December 2006, 00:05
Can you post the output of the Time Map verification? And maybe also the PGC details (Info -> PGC)?
Of course, be sure to save the DVD after the rebuilding of the time maps!
blutach
6th December 2006, 03:44
Strange issue with B2.
After calling Info - Find Uncalled PGCs, if I try to put the mouse on an uncalled PGC which is a Root Menu it goes somewhere else - usually a PGC in VMGM.
Anyone else getting this?
EDIT: Might only be with one DVD - will revert after more experimenting.
Regards
r0lZ
6th December 2006, 08:52
Might be caused by misplaced user labels. Do you have some labels defined (not including the "uncalled" labels added automatically by PgcEdit)?
Anyway, I'm waiting for your confirmation...
blutach
6th December 2006, 09:54
I've emailed you - I am sure it has to do with a corrupt IFO with bad end of table pointers.
Regards
r0lZ
6th December 2006, 13:17
OK, beta 3 is here (http://download.videohelp.com/r0lZ/pgcedit/beta/).
The frame rate problem (http://forum.doom9.org/showthread.php?p=913106#post913106) should be fixed, and I have added an option in Remove Cells to automatically remove the chapters (http://forum.doom9.org/showthread.php?p=912893#post912893) at the end of the chapter table when they are not assigned to a program any more.
Sorry, blu, I haven't analysed the PGC Selector problem yet...
blutach
6th December 2006, 13:31
Little bug in shorten the chapter table.
In the following I removed cells 3-15 and ended up with 2 chapters.
http://img245.imageshack.us/img245/3156/12062006233102bi6.png
http://img99.imageshack.us/img99/4558/12062006233136zp7.png
Of course, there is no program 2.
Regards
r0lZ
6th December 2006, 13:35
Bizarre! OK, I'll verify that too...
r0lZ
6th December 2006, 13:42
Yep, there was a bug. I have replaced beta 3 by a fixed version (but haven't increased the beta version number.)
Garambone
7th December 2006, 04:29
Can you post the output of the Time Map verification? And maybe also the PGC details (Info -> PGC)?
Of course, be sure to save the DVD after the rebuilding of the time maps!
Sure, there it is.
TMap verification:
------------------- Summary -------------------
VTST 1 , 1 TTN 1 (0:01) Title 19: No TMAPTI!
VTST 2 , 1 TTN 1 (22:47) Title 1: Wrong TMAP duration
VTST 2 , 2 TTN 2 (22:46) Title 2: Wrong TMAP duration
VTST 2 , 4 TTN 4 (22:46) Title 4: Wrong TMAP duration
Rebuild time map log:
Some times have been fixed in VTS_TMAPTI of VTS 1:
VTS 1, PGC 1, cell 1: 00:00:00.18 -> 00:00:00.14
VTS 1, PGC 1, cell 2: 00:00:00.18 -> 00:00:00.14
VTS 1, PGC 1 playback time: 00:00:01.06 -> 00:00:00.28
After saving the project I ran the TMap verification again and voilą:
------------------- Summary -------------------
VTST 2 , 1 TTN 1 (22:47) Title 1: Wrong TMAP duration
VTST 2 , 2 TTN 2 (22:46) Title 2: Wrong TMAP duration
VTST 2 , 4 TTN 4 (22:46) Title 4: Wrong TMAP duration
Finally, the PGC Info as you requested (only from TTN 1):
VTST 2 , 1 TTN 1 (22:47) Title 1 - Chapters: 5, Programs: 5, Cells: 5
********** pre commands:
1 Set gprm(9) =(mov) gprm(14)
2 Set gprm(9) &=(and) 61440
3 if ( gprm(9) == 8192 ) then { Goto line 10 }
4 if ( gprm(9) == 20480 ) then { Goto line 10 }
5 Set gprm(9) =(mov) gprm(14)
6 Set gprm(14) =(mov) 8193
7 Set gprm(12) =(mov) 0
8 if ( gprm(6) == 6826 ) then { Set gprm(14) =(mov) 10922 }
9 Break
10 Set gprm(9) =(mov) gprm(10)
11 Set gprm(9) &=(and) 127
12 Set gprm(2) =(mov) gprm(9)
13 (SetSTN) Set Sub-picture stream = gprm(2)
14 Set gprm(3) =(mov) gprm(2)
15 Set gprm(3) &=(and) 63
16 Set gprm(4) =(mov) gprm(10)
17 Set gprm(4) &=(and) 3840
18 Set gprm(4) /=(div) 256
19 Set gprm(4) &=(and) 15
20 (SetSTN) Set Audio stream = gprm(4)
21 (CallSS) Call the VMGM PGC 8, resume cell 1
********** post commands:
1 Set gprm(9) =(mov) gprm(14)
2 Set gprm(14) =(mov) 8193
3 if ( gprm(9) == 8241 ) then { Set gprm(14) =(mov) 8241 }
4 if ( gprm(6) == 6826 ) then { Set gprm(14) =(mov) 4098 }
5 Set gprm(9) =(mov) sprm(1:Audio stream number)
6 Set gprm(9) &=(and) 15
7 Set gprm(10) &=(and) 61695
8 Set gprm(9) *=(mul) 256
9 Set gprm(10) +=(add) gprm(9)
10 Set gprm(9) =(mov) sprm(2:Sub-picture stream number)
11 Set gprm(9) &=(and) 127
12 Set gprm(10) &=(and) 65280
13 Set gprm(10) +=(add) gprm(9)
14 (CallSS) Call the VMGM PGC 1, resume cell 1
********** cell commands:
Playback time: 00:22:47.25 (at 30 fps)
PG Playback mode: sequential
PUOs: 0 (0x00000000)
NextPGCN: 0
PrevPGCN: 0
GoUpPGCN: 0
PGC Still Time: 0
Audio stream 1 status: 0x00008000 (stream=0)
Audio stream 2 status: 0x00008200 (stream=2)
Subpic stream 1 status: 0x80000000 (streams for 4:3=0, wide=0, letterbox=0, pan&scan=0)
Subpic stream 2 status: 0x81000000 (streams for 4:3=1, wide=0, letterbox=0, pan&scan=0)
Subpic stream 3 status: 0x83000000 (streams for 4:3=3, wide=0, letterbox=0, pan&scan=0)
Subpic stream 4 status: 0x84000000 (streams for 4:3=4, wide=0, letterbox=0, pan&scan=0)
Subpic stream 5 status: 0x86000000 (streams for 4:3=6, wide=0, letterbox=0, pan&scan=0)
Subpic stream 6 status: 0x88000000 (streams for 4:3=8, wide=0, letterbox=0, pan&scan=0)
BOVs Chap. Prog. Cell Type Seam- Ang VOBU Cell Cell Playback End Entry First Last Last VOB Cell
(PTT) Flags less Still Still Cmd. Time Time VOBU ILVU VOBU VOBU ID ID
Joint Time # sector End Start End
? 1 1 1 2 no - no 0 0 00:00:40.00 00:00:40.00 0 0 6994 7021 1 1
? 2 2 2 8 yes - no 0 0 00:09:31.12 00:10:11.12 7022 0 115747 115767 1 2
? 3 3 3 8 yes - no 0 0 00:11:53.08 00:22:04.20 115768 0 250677 250706 1 3
? 4 4 4 8 yes - no 0 0 00:00:41.25 00:22:46.15 250707 0 258388 258415 1 4
? 5 5 5 2 no - no 0 0 00:00:01.10 00:22:47.25 258416 0 258448 258462 1 5
Sorry for being too long. I promisse to clean the message as soon as I get any reply (to keep the room neat). Answer only if you have the patience and the time. :thanks:
Garambone
7th December 2006, 04:39
As I opened a new project I got this message:
Error sourcing /Tcl/work/PGCEDIT/PgcEdit.tcl: invalid command name "it"
(THE 4400_S2_D3) 1 %
Despite the error message I am allowed to carry on with the project as usual.
Any clue?
r0lZ
7th December 2006, 08:23
Hum, I can't understand the Time Map problem with the logs only. Can you send me your IFOs? pgcedit [at] scarlet [dot] be
For the error message, try this:
Do not open the DVD at startup. Use the menu File -> Open DVD to open it (not the toolbar icon!)
When the error occur, you should see in the dialog a "Details >>>" button. Click on it, and copy the full message. Do not close PgcEdit. Paste the message here. You can also send me the IFOs if you wish. Thanks.
BigCondor
7th December 2006, 08:31
I had just tried to clean sub pgcs with the new version.
There are 24 vts in the dvd. After manually changed some lines I use the Delete uncalled PGCs function. After a while it
said this function will try to DELETE 311 PGCs from the DVD! Then it said there are some VM commands using the SPRM 4,5,6 or 10 and asked me if I want to continue. I replied no and the command containing the VM commands were shown in a box:- (There were 3 altogether and this was one of them)
VTSM 24, LU1(en),1 (0:00) RootM '<uncalled>' - pre command 5:
Set gprm(0)=(mov) sprm(5:Title number in VTS)
When I goto the RootM of VTSM 24 by clicking the program on the left, strange thing happened, it jumped to VMGM, LU1(en), 22 (dummy). But the content on the right belongs to that of VTSM 24, LU1(en),1 (0:00) RootM.
If I click on the 2nd pgc in VTSM24 and use the arrow to move to the root there is no problem. But if I directly click on it then it will jump to pgc22 of VMGM. This did not happen before I try to 'Delete uncalled PGCs'. Here are the commands of the root M of VTS 24.
1 NOP
2 NOP
3 Set gprm(6) =(mov) 0
4 NOP
5 Set gprm(0) =(mov) sprm(5:Title number in VTS)
6 Set gprm(0) *=(mul) 256
7 Set gprm(0) |=(or) sprm(7:Chapter number (or PGN))
8 NOP
9 NOP
10 NOP
11 NOP
12 NOP
13 NOP
14 NOP
15 NOP
16 NOP
17 if ( gprm(0) >= 25957 ) then { Goto line 21 }
18 Set gprm(2) =(mov) 13
19 (JumpSS) Jump to VMGM PGC 6
20 NOP
21 NOP
22 RSM
There were 3 instances that had reported issue but this is the only one that has the problem. I could goto others as usual.
r0lZ
7th December 2006, 09:02
I've just fixed this bug. It is not related to the SPRM warning. Just a GUI bug. The next beta will be released soon...
BigCondor
7th December 2006, 09:06
Thanks, then I can continue along...
r0lZ
7th December 2006, 09:10
Yes, but remember that the SPRM warning is important. PgcEdit cannot delete the uncalled PGCs and be sure to keep the navigation intact if this warning is displayed. You must understand the implications of the SPRMs and probably fix the navigation manually! If you are a beginner, do not continue! And be sure to create an incremental backup first!
Read the excellent guide (http://www.digital-digest.com/~blutach/pgcedit_guide/remapping/PgcEdit_Advanced_Functions.htm) by blutach for more info.
BigCondor
7th December 2006, 09:16
Thanks for the advice, I'd done this before manually and I want to see what the new program can be of help. I've already burnt the project, I just want to try things out.
I'll revise the guide to see what steps I've missed.
blutach
7th December 2006, 12:04
This is - or was - the "pink root menu bug" mentioned in post 4. :)
Where you get this warning about SPRMs, I'd find out if the offending SPRM is ever set. If the only place is in an uncalled PGC itself, then I don't suppose it is an issue (someone correct me if I am wrong). If, however, there are other places, then you need to tread warily.
Regards
BigCondor
7th December 2006, 13:01
I think these settings are for various jumps to other titles, since all other titles except the main have been removed(blanked with VobBlanker) so it is quite save to replace them with nops.
When I look at post 4 again and it's almost the same as what I encounter.
r0lZ
7th December 2006, 13:33
If the only place is in an uncalled PGC itself, then I don't suppose it is an issue (someone correct me if I am wrong).Of course, you're right. PgcEdit should test that also, but it's not easy, and IMO this case is rare. Anyway, you can manually remove the offending commands as long as they are in PGCs marked as uncalled, and call the Remove Uncalled PGCs function again.
r0lZ
7th December 2006, 20:27
Beta 4 is here (http://download.videohelp.com/r0lZ/pgcedit/beta/).
I have hopefully fixed all problems reported so far.
I have also modified the video attributes of the menu domains to leave them unset (at zero) until a VOB file is imported or created, and to reset them to 0 when a menu or its VOB file is deleted. This part was not easy, and I have modified many things. I hope I haven't introduced new bugs. If you have some time, please test it carefully, especially with hybrid PAL/NTSC compilations. Thanks.
BigCondor
8th December 2006, 01:43
Just downloaded beta 4, there is no misbehaviour occured. After changing the commands to nops, the pgcs were cleared beautifully and only the ifos and vob_01 of each VTS were left. Then I did 23 time delete last VTS and the dvd is functioning exactly as expected. Thanks for your effort!
r0lZ
8th December 2006, 09:24
Thanks for the positive report. :)
BTW, it should be possible to enhance Delete Uncalled PGCs further by incorporating the complete removal of the useless titlesets, but that requires using the Remap Titlesets function to push them to the end of the DVD, and that function needs to save the DVD. I don't like to do it automatically without the user consent. But I can probably open the Remap Titlesets dialog with the right remapping already preselected, so that the user will have only to accept it, and then delete the last uncalled VTSs easily.
Or I can also replace completely the whole uncalled VTSs by a single Title with only a black 10KB VOB cell. That will speed up the VOB cleaning process with FixVTS or VobBlanker. (The crappy ARccOS protected VTSs will therefore be cleaned also automatically, even if they are not at the end of the DVD, but I'm not sure it's very useful, as ARccOS can be cleaned by other tools like RipIt4Me.)
BigCondor
8th December 2006, 10:54
Maybe you can further develop the delete last VTS command by continuing to delete until the user halts, then I can delete all 23 titleset in a single command.
r0lZ
8th December 2006, 11:28
Well, that's not so simple, as it is possible that some uncalled VTS are not at the end of the DVD, and/or that the Title numbers are not in the right order. Therefore I cannot delete those VTSs without remapping the title numbers and the VTSs first. And as remapping the VTSs requires saving the DVD, it's potentially dangerous.
Anyway, I'm working on it... :)
r0lZ
8th December 2006, 13:24
Beta 5 is available at the usual place (http://download.videohelp.com/r0lZ/pgcedit/beta/).
I have improved the Delete Uncalled PGCs function. It is now possible to delete the uncalled PGCs that are alone in a titleset after the first pass. The titlesets and title numbers are remapped automatically if necessary, and the useless titlesets are deleted completely (but the VOB files are moved to the backup folder, just in case.) Several incremental backups are made automatically during the operation.
Of course, it is still not possible to delete the last Title in a VTS if the menu of that VTS is called by the VMG, as the menu must be kept. In this case, its Title number is pushed at the end of the Title Play Map table, so that the lowest Title numbers are used by the called, useful Titles. You can however manually blank the uncalled titleset if you wish, to regain some disc space or clean the ARccOS crap.
@blutach: Sorry, you will have to modify your guide (http://www.digital-digest.com/~blutach/pgcedit_guide/remapping/PgcEdit_Advanced_Functions.htm)!
(BTW, I have also modified slightly the first dialog.)
Edit: Also, the title of the guide is "How to use PgcEdit’s Remapping and Restoring Functions", but the title in the titlebar of the web browser is different. Not very important though! ;)
blutach
8th December 2006, 14:22
I was dreading that! It is already the weekend here though :)
Regards
dirio49
8th December 2006, 15:54
Is it possible to mark that pgc that are referenced within themself ( within the same titleset, and not referenced anywhere else)
like:
VTSM 1 LU1 references VTSM 1 LU2, and LU2 does LU3 since these one are in effect unreferenced.
Thanks
r0lZ
8th December 2006, 16:49
Why do you need that?
The Go To Calling Command function lists all references to the current PGC, including the references within themself.
But of course, those references must be ignored when the DVD is searched for uncalled PGCs.
Anyway, a menu PGC in a specific LU cannot point to a PGC in another LU of the same domain. Only one LU is active at a time. The active LU is determined by your preferred menu language.
Maybe I don't understand your question well?
dirio49
9th December 2006, 01:20
Why do you need that?
The Go To Calling Command function lists all references to the current PGC, including the references within themself.
But of course, those references must be ignored when the DVD is searched for uncalled PGCs.
Anyway, a menu PGC in a specific LU cannot point to a PGC in another LU of the same domain. Only one LU is active at a time. The active LU is determined by your preferred menu language.
Maybe I don't understand your question well?
Forget it, i was having a brain fart.
I was thinking that assuming the Pgcedit knows that the pgc in never played(visited during playback), and also referenced only with in itself. if these condition are true then the pgc that is referenced within itself would be trully useless because it is never play.
Sorry for the confusion.:D
BigCondor
9th December 2006, 05:22
Just downloaded beta 5 and tested. With a dvd of 6 VTS I changed all external calls to VTS_02 and used delete uncalled pgcs. After a series of Q/A the VTS was moved to the bottom and removed. And after running FixVTS to blank out some stuffs the dvd is ready to burn, nice and neat.
Thanks for the qood work!
r0lZ
9th December 2006, 09:19
@ BigCondor: :)
@ dirio49:
There is a difference between uncalled PGCs and never-played PGCs.
The Delete Uncalled PGCs function doesn't test if a PGC can be played, but only if it is called by a VM command from another PGC that is called, or if it can be called with the remote. The function removes (virtually) the VM commands and Next/Prev/GoUpPGCN links of all uncalled PGCs, and repeat that until no more uncalled PGCs are found. It doesn't simulate the playback. Therefore, if a PGC is called only by a VM command that cannot be executed (for example because its condition cannot be true), that PGC will not be removed, although it is useless. To find and remove those never-played PGCs, you have to analyze the navigation (with the help of the trace), and edit or remove the VM commands yourself before using Delete Uncalled PGCs.
BTW, there is a drawback of my method. For example, if you use the Jump To PGC Upon DVD Insert function (say to jump directly to the main menu), many PGCs will probably never be played. However, since Jump to PGC leaves the original commands in place, those skipped PGCs are still called, and they will not be removed. I'll try to improve the Jump to PGC function a bit, as it is possible to remove automatically the original commands of the FP-PGC if (and only if) the FP-PGC is never called. In this case, it should be possible to remove all bypassed PGCs with Delete Uncalled PGCs, although not in all cases.
Also, a common authoring method to call a title is to define a VMGM dummy with a lot of jumps to Titles with conditions, and init a GPRM before calling that PGC to jump to the right title. Most of the time, those PGCs have jumps to all titles of the DVD, and PgcEdit cannot determine if some of them are never executed. I cannot handle this case without simulating the playback.
BigCondor
9th December 2006, 10:13
In that case I'll check carefully when using the function if I had changed the destination. Generally, such titles are mostly trailers of other films and in most cases they are unwanted materials and are most likely deleted (or made isolated) before using Delete Uncalled Pgcs. Others are generally callable from a menu so they are not likely deleted by Delete Uncalled Pgcs. Anyway, I think it is a good practice to test virtually with trace and run thru the dvd as a check out to make sure everything is functioning as expected.
r0lZ
9th December 2006, 12:27
Beta 6 (http://download.videohelp.com/r0lZ/pgcedit/beta/).
As explained in my previous post, after using the Jump to PGC function, the bypassed PGCs were never considered as uncalled, because the original commands of the FP-PGC were kept anyway.
I have therefore modified Jump2PGC to remove them when the FP-PGC is never called directly. It should now be possible to delete the bypassed PGCs automatically with the new Delete uncalled PGCs function (unless they are called by another PGC that is still called.)
Also, when I've re-read my code, I've found another little problem with the Jump to PGC function. A GPRM is used to bypass the original pre-commands of some bypassed PGCs, and jump directly to the target. But when a free GPRM is available, it is not initialized in the FP-PGC. Its value is therefore 0. When a title PGC is modified, that GPRM is tested, and if its value is still 0, the nav is redirected to the target. In the target, the GPRM is modified to be non-zero, so that, when the title is called again, the commands added by the function are bypassed, and the title is played normally.
The problem with this method is that, if the title is called directly from the exit domain (when the DVD is not playing) with the player's function to call a title by its number, all GPRMs are cleared first. Therefore, the title was not played, and the navigation was redirected to the target PGC of the Jump2PGC function.
I have therefore modified the Jump2PGC method. Now, the target PGC is initialized with a non-zero value in the first-play PGC, and the test in the pre-commands of the title is inverted: the nav is now redirected to the target of Jump2PGC if the GPRM has the value used to initialize it in the FP-PGC. In the target PGC, the GPRM is forced back to 0. This way, it is (theoretically) possible to play the title directly from the exit domain with the remote.
I hope I haven't introduced new bugs, as this function is rather complex. Please test your DVD carefully if you use the modified Jump2PGC function!
Nothing has been changed in the Delete Uncalled PGCs function since beta 5.
BigCondor
9th December 2006, 13:20
I had never tried to use the Jump2PGC function. I do this manually. I think each DVD should be treated differently since they are not authored in the same manner. And in most cases, I have to change some codes regarding language and subtitles (mostly adding Chinese subtitles) so that my new subtitle can be set as pre-selected without being masked off (when there were only 2 subtitles in the DVD, most likely it will be masked to 64 or 65). Since I had been programming in assembly language in the apple ][ ages, I have little trouble with that.
blutach
9th December 2006, 13:49
A beta a day r0lZ ... :)
Great stuff.
Regards
r0lZ
10th December 2006, 14:04
Yes, blu! And yet another one: Beta 7 (http://download.videohelp.com/r0lZ/pgcedit/beta/).
It is now possible to launch the preview from the remapping GUI by double-clicking on an entry in the listbox. (Available for DVD -> Remap Titlesets, Domain -> Remap PGCs in domain, and Title -> Remap Title numbers.)
Thanks to Foxace, who has suggested this improvement, via PM. :thanks:
@ BigCondor:
I have also programmed in assembly in the eighties, on a Commodore 64. IIRC, it used the same processor than the Apple II, the CMOS 6502 (8 bits!)
blutach
10th December 2006, 14:54
Yes, the 6502/10. Was fun optimising code in such a small RAM. :)
Regards
setarip_old
10th December 2006, 21:36
As I noted in another post (at another forum), The 6502, created by Motorola, was introduced in 1975. It was a great chip, used to give Atari its early success in both standalone game machines (The "VCS" or "2600") and the Atari 400 and 800 computers. It was also used in the Apple][.Initially (in 1979/80), the really great fun was programming for the VCS/2600 using the "Computer Magic" programming cartridge (It cost $50, which, back then, was quite substantial. I still have it - and have been offered upwards of $1,000 for it) to enter "Fetch" and "Store" commands via the dual keypads (that were bundled together with the separately purchased "B.A.S.I.C." cartridge). Of course, at that time, there was no way to save your work, unless you were willing to re-wire the VCS/2600 so that it could output to a tape recorder (And I wasn't, for fear that, if I blew it, my son would never forgive me) - Ah, fond memories ;>}
blutach
10th December 2006, 21:51
$1,000! I've got (what I guess is) a fully working C64 portable with a teensy weensy screen somewhere with fast loader cartridge too. I thought it might be worth about 25 cents :D
Regards
setarip_old
10th December 2006, 22:07
@blutach
What I've described pre-dates the creation of the Commodore...
BTW - The initial 6502 chip, used in the Atari 2600/VCS game machine, was a 4 bit processor. The 6502C, used in both the Atari 400/800 and Apple ][ computers was an 8 bit processor - which also pre-dates the 6510 chip which I believe was used in the Commodore...
**EDIT** Now that I think of it, I believe the Commodore VIC20 (as advertised by William Shatner) also used the 6502C - but it was introduced about 1 year after the Atari 400/800...
r0lZ
10th December 2006, 22:34
The VIC-20 was based on a 6502, and the 64 on a 6510. Both are 8 bits processors, but the 6510 was able to address 64KB of pure RAM, plus the ROM and the IO registers with the bank switching technique, hence the fabulous amount of RAM available in the 64! ;)
setarip_old
10th December 2006, 22:46
@r0lZ
The Atari 400/800, using the 6502C, also utilized bank switching ;>}
jsoto
11th December 2006, 00:22
Guys, you're very old men... :D :D
Now, if you want, we can discuss about black&white TVs, using lamps instead of transistors, and when the color was born.
jsoto
EDIT:
I was very proud when I coded my "indirect jump" in 6805 because this chip didn't have an indirect Jump instruction. What I did is to modify the code of a simple jump directly RAM, just the operand part of the JMP. Everything encapsulated in a macro...
I'm also very old...
setarip_old
11th December 2006, 02:58
Guys, you're very old men...Thanks so much for the reminder!
I remember when I was speaking to Babbage's daughter...
BigCondor
11th December 2006, 04:45
Suddenly we were back to nostalgia, just reminds me of my first hand on computer... even without DOS, save projects on cassette tapes. And it is funny to enter those machine codes like A2, E8... to test out programmes without compiling.
@jsoto
Have you ever been shocked when doing projects on tubes? I was afraid of getting electric shocks so most of my porjects were on transisters (and later ttls).
Ha ha, we are all old men!
r0lZ
11th December 2006, 09:36
Guys, you're very old men... :D :D
Now, if you want, we can discuss about black&white TVs, using lamps instead of transistors, and when the color was born.Have a look at my high-tech radio:
http://img222.imageshack.us/img222/6313/concertinoma1.th.jpg (http://img222.imageshack.us/my.php?image=concertinoma1.jpg)
(BTW, the sound is great!)
Sir Didymus
11th December 2006, 09:38
I have also programmed in assembly in the eighties, on a Commodore 64. IIRC, it used the same processor than the Apple II, the CMOS 6502 (8 bits!)
Me too! on the lovely Apple II...
Never an off topic branching was nicer!
Apple II was my first PC...
I arranged a nice travel in USA, from Italy, in 1984 (or it was 85 ?) to buy it...
Saved up money largely compensated both flight and accomodation costs... :D
setarip_old
11th December 2006, 10:43
@r0lZ
That radio is absolutely beautiful! Is it shortwave as well as AM?
BigCondor
11th December 2006, 12:53
@r0lZ
Your radio reminds me of my "shocking experiences" on these radios. Generally most of these radios didn't had any power transformer (to cut down the cost) and the earth was connected to one of the two plugs of the power (plugs with earthing were not common in those days). So there was a great chance to connect the case to the live wire. The tubes in these radios were also quite queer. E.g. instead of of 6BM8, you might as well got 12BM8 (so that the sum of all the tubes added up to 120V).
Sorry to have swifted that far, but I just can resist!
Updating is really fast, I have to jump to B7 from B5!
r0lZ
11th December 2006, 16:58
It is true that there is no ground pin in the power supply connector, but there is a separate ground connector on the rear panel, with the antennas connectors.
Not sure what you mean with the 6BM8 vs. 12BM8 tubes. I'm not a radio specialist, but I know that those radios were not designed to be cheap.
Is it shortwave as well as AM?AM, (mono) FM, Long and Short waves, yes! Everything works well, but I have replaced several tubes. I use it as an alarm clock, connected to a (modern :)) chrono-switch (damn, what's the name of that device in english?) to wake up in the morning. I like the fact that the volume slowly grows up when the tubes are warming up. :cool:
BigCondor
11th December 2006, 17:31
6BM8 means the tube works on 6V filament, that's most common and so 12BM8 will work on 12V filament and they have the same specification. If you have a transformer to provide individual tube then there won't be any problem. But in this case all the filaments of the tubes in the circuit are connected in series so that the total voltage will equal to that of the power source. So some special tubes were made so as to meet the requirement.
Just for illustrative purpose, suppose you have 10 tubes in the radio, then the average will be 12V and with all the tubes' filament in 12V everything is fine. But what if you only have 8? So in that case you need to have some tubes with voltage greater than 12 to make a total of 120V. I had seen tubes with filament's voltage as high as 35V.
r0lZ
11th December 2006, 18:34
Thanks!
frank
11th December 2006, 19:55
I'm happy to see 40 years of experience in our team! :D
I love my old Atari XL with 6502 and the funny games!
After 6 monthes of debugging and hardware hacking I wrote a new quick firmware for it's external floppy drive...
r0lZ
20th December 2006, 10:31
Beta 8 is available here (http://download.videohelp.com/r0lZ/pgcedit/beta/).
I have fixed an important bug in Reorder TTNs in Domain. In some case, the Title Play Map table was totally messed up after using this function. Trying to reload the DVD produced a lot of errors. Since this function is used by the new Delete Uncalled PGCs function, that function was dangerous too!
(The problem occurred only with not-one_sequential titles, when several PGCs were shared by the same TTN.)
Many thanks to Calimari, who has submitted this bug here (http://forum.digital-digest.com/showthread.php?t=75476#3)!
Another tiny bug is also fixed. Sometimes, clicking on an entry of the Jump To Calling Command GUI had the effect to display the PGC (that was correct) but the calling command was not selected automatically.
There are also some (very) little GUI improvements.
Unless another bug is found, this beta is probably the last one, so, consider it as RC1.
blutach
20th December 2006, 12:25
Actually it is almost beta 30, isn't it? :D
Congratulations - looking forward to the release!
Regards
dirio49
20th December 2006, 15:34
thanks, for the new beta. :)
President
25th December 2006, 15:42
Beta 8 is available here.
Thank's for the next beta.
Your radio is great. I have the same raritet, but my "monster" have a 3 devices in one box. LP player (33, 45 and 78 rpm), B&W TV set and the same radio (LW, MW, SW and mono FM). Year of production - 1957. No one PCB, space-wired interconnection, wood box with ~4 cm wall thickness, weight... mmm, very heavy:). Partially working now. It was my first monitor for my ZX-Spectrum. Sorry, I have no photo.
Excellent offtopic:).
r0lZ
25th December 2006, 16:22
My Telefunken Concertino 6 is older: 1956! :p
(Good photos here (http://dampfradioforum.foren-city.de/topic,330,-telefunken-concertino-6.html).)
Dr.Khron
25th December 2006, 21:54
Sorry to jump in on an old conversation, but I too am an old man... My first comp was a VIC-20, followed by a C-64, and then an Amiga 500. Sigh. I loved Commodore. My Amy was my first introduction to real command-line computing.
I like the fact that the volume slowly grows up when the tubes are warming up.
That is one of the coolest things I've heard in a long time. Too bad you can't get Sirius on that thing. :)
As for the beta of PCG Edit, I havn't used it. However, I've used the released version long enough now to have a few suggestions for future versions.
1. A unified import/export tool or menu.
PCG Edit has some very powerful import/export features, but they are scattered about in the program. Its also not always immediately clear specifically what you are importing/exporting. Also, the menu and menu color scheme exports are in button editing menu, which seems a little awkward.
2. A mass replace tool for CMDs and/or jump targets.
Basically, this would run through every menu and title PCG in a chosen title set, and replace one specific target location with another. For example, in the project I just did, where I grafted two DVDs together, I had to reroute the VMGM PGC jumps to new dummy VMGM PCGs (for example, to jump to feature X, you now jump to VMGM 13 instead of VMGM 4).
Keep up the good work!
r0lZ
25th December 2006, 23:35
An unified import/export tool or menu is possible, but IMO, as the functions are already available, it's not a priority.
It is already possible to export all PGC commands as an hex dump, and import them back. (See the File menu.) However, the button commands are not exported with that method.
You might find it easier to change the commands with a text editor or a script to modify several target at once, but of course, you have to understand somewhat the hex codes.
(Note that you can also delete some files, if you don't want to re-import them. If a file is missing for a PGC, that PGC is simply not modified.)
A fully automatic method to remap some targets already exists (it's a major new feature in v8) but you have to specifically remap the VTS, Titles, TTNs or PGCs to trigger it. It is currently not possible to do it without modifying the order of the items.
It is probably very difficult to do what you want, as I have to know in which domains I must remap the commands, and for which sources and targets. The GUI must therefore be very complex. Really not easy.
Dr.Khron
28th December 2006, 14:21
as the functions are already available, it's not a priority.
Yeah, I see your point... to make the program really easy to use, you'd need a team of full-time programers, and then you'd have to charge a lot of money for it. :)
Me, I'm much happier with a free program that works really well.
It is probably very difficult to do what you want
I don't think I understand your explanation, but I'll take your word for it, since I don't really know much about programming. (well, OK, I took a Pascal course back in college... back in 1990 ;) )
Thanks for your response, I'm looking forward to the next release of your program.
linx05
7th January 2007, 09:22
Is this now safe to use?
blutach
7th January 2007, 10:24
@linx05
I can tell you that I have thoroughly tested it and it works a treat. Plus, with the backup procedure in place, you shouldn't go wrong.
Regards
r0lZ
7th January 2007, 11:11
There are still some minor bugs, and I still want to improve it a little bit, but the last beta is reasonably stable.
linx05
7th January 2007, 13:34
Thanks. I've been messing around with it, using some of the new functions. One in particular, Delete Uncalled PGCs. Very cool indeed. If you look at the picture I've attached, there are no commands in the one shown. So where would it go? I used the Trace function (ends with DVD Playback End!) and the Go to calling command (takes it back to RootM) and I am puzzled. What would call this empty dummy?
http://img247.imageshack.us/img247/520/pgceditdummyhh9.th.png (http://img247.imageshack.us/my.php?image=pgceditdummyhh9.png)
r0lZ
7th January 2007, 14:40
Are you sure it is really called? Do you have used the trace right from the FP-PGC, without forcing it to execute some commands or assigning manually a specific value to a GPRM?
I have already seen several times the root menu calling a PGC in the same domain, and that PGC was empty. But the calling command is executed only if a GPRM has a specific value, and I believe that value is never assigned to the GPRM. It's a strange authoring, with useless commands and PGCs, but maybe the PGC is really called on some DVDs, and in that case only it is filled with commands.
Can you verify if that empty PGC has also no commands in the original IFO? Maybe you've found a bug! (Be sure to identify the right PGC, as the VTS and PGCs might have moved.)
blutach
7th January 2007, 15:17
I've seen such authoring quite a bit - where the empty PGC is called conditionally (but the condition is never true). I usually take the references to these PGCs away (you see them in the root menu mainly - they are authoring remnants).
Another, safer way, is to pop a line in the precommands of each of them to Call the First Play PGC.
Regards
linx05
7th January 2007, 15:20
Thanks for the reply. I did another trace from FP-PGC right through the movie, Special Features and then back to the Main Menu. It wouldn't go to that PGC I was talking about.
As for your second request I would if I knew how. I disabled AnyDVD and opened the IFO(s) on the original disc. I have no clue what I am looking for. How do I find out which IFO to open up?
EDIT: That's a good idea blutach. I might do that just in case.
blutach
8th January 2007, 09:47
As for your second request I would if I knew how. I disabled AnyDVD and opened the IFO(s) on the original disc. I have no clue what I am looking for. How do I find out which IFO to open up?Open the DVD itself in PgcEdit (it can also open a DVD from the optical drive). Have a look at the same PGC. But undoubtedly, it's an authoring remnant.
Regards
r0lZ
8th January 2007, 10:41
Well, I'm not totally sure it's that problem, as I have experienced a little problem when using Delete Uncalled PGCs. The last PGC that was selected during the operation was empty in the GUI. I've selected another PGC and then the "empty one" again, and the commands were there again. So, it's only a little GUI problem, but maybe PgcEdit forgets the commands completely if you edit the PGC before refreshing it.
Anyway, I'll fix this bug right now...
linx05, no need to verify the problem that way. Just post the commands of the root menu PGC (of the same titleset) here, and I'll be able to recognize if it's the strange authoring described above. (Use Info -> PGC to display the PGC as text, and copy/paste here.)
linx05
8th January 2007, 12:48
Here it is, from the same title set. This isn't from the original DVD, this is the processed version.
VTSM 2 , LU 1 (en) , 1 (0:00) RootM - Chapters: n/a, Programs: 1, Cells: 1
********** pre commands:
1 if ( gprm(1) != 0 ) then { LinkPGCN PGC 3 }
2 if ( gprm(2) != 0 ) then { LinkPGCN PGC 2 }
3 Set gprm(6) =(mov) 0
4 NOP
5 Set gprm(0) =(mov) sprm(5:Title number in VTS)
6 Set gprm(0) *=(mul) 256
7 Set gprm(0) |=(or) sprm(7:Chapter number (or PGN))
8 NOP
9 NOP
10 NOP
11 NOP
12 NOP
13 NOP
14 NOP
15 NOP
16 NOP
17 NOP
18 RSM
********** post commands:
********** cell commands:
********** menu buttons commands:
Playback time: 00:00:00.15 (at 25 fps)
PG Playback mode: sequential
PUOs: 0 (0x00000000)
NextPGCN: 0
PrevPGCN: 0
GoUpPGCN: 0
PGC Still Time: 0
But- Prog. Cell Type Seam- Ang VOBU Cell Cell Playback End Entry First Last Last VOB Cell
tons Flags less Still Still Cmd. Time Time VOBU ILVU VOBU VOBU ID ID
Joint Time # sector End Start End
0 1 1 2 no - no 255 0 00:00:00.15 00:00:00.15 0 0 0 76 1 1
And this is from the original disc.
VTSM 2 , LU 1 (en) , 1 (0:00) RootM - Chapters: n/a, Programs: 1, Cells: 1
********** pre commands:
1 if ( gprm(1) != 0 ) then { LinkPGCN PGC 5 }
2 if ( gprm(2) != 0 ) then { LinkPGCN PGC 4 }
3 Set gprm(6) =(mov) 0
4 NOP
5 Set gprm(0) =(mov) sprm(5:Title number in VTS)
6 Set gprm(0) *=(mul) 256
7 Set gprm(0) |=(or) sprm(7:Chapter number (or PGN))
8 NOP
9 NOP
10 NOP
11 NOP
12 NOP
13 NOP
14 NOP
15 NOP
16 NOP
17 NOP
18 RSM
********** post commands:
********** cell commands:
********** menu buttons commands:
Playback time: 00:00:00.15 (at 25 fps)
PG Playback mode: sequential
PUOs: 0 (0x00000000)
NextPGCN: 0
PrevPGCN: 0
GoUpPGCN: 0
PGC Still Time: 0
But- Prog. Cell Type Seam- Ang VOBU Cell Cell Playback End Entry First Last Last VOB Cell
tons Flags less Still Still Cmd. Time Time VOBU ILVU VOBU VOBU ID ID
Joint Time # sector End Start End
0 1 1 2 no - no 255 0 00:00:00.15 00:00:00.15 0 0 0 76 1 1
I didn't know which ones you wanted so I did both. I can see a couple of things changed but I'll leave the rest up to you guys to figure out. I've learnt a lot more from this experience! :D
r0lZ
8th January 2007, 13:18
It's exactly what I thought, and, I'm sure, blutach too.
Look at the first two pre-commands: the LinkPGCN commands are usually never executed, because the condition is never true. Most of the time, the target PGC of those commands is empty.
Unfortunately, PgcEdit cannot delete those useless empty PGCs because they are still called (even though they cannot be called in practice.)
If you want to remove them, you must delete the two first lines of the root menu PGC, and call the Delete Uncalled PGCs function again. But take care. Although I have never seen a DVD where those PGCs are really called, it's not impossible. Anyway, if the target PGC is blank, you can certainly delete the command.
Note also that on those DVDs, all menus (except the main menu with real content and the VMGM) are authored that way. You can therefore probably apply the same procedure in several PGCs.
(In the processed version of the Root Menu PGC, the target PGC numbers have changed, because some PGCs have been deleted in the same domain by the Delete Uncalled PGCs function. It was therefore necessary to remap the commands to point to the right PGCs.)
Thanks for your help. I'm now sure that it's not a PgcEdit bug!
linx05
8th January 2007, 14:17
Thanks for the confirmation. I don't think I will delete them as they do no harm. I will test the DVD out and if I feel like it I may do what blutach said (http://forum.doom9.org/showthread.php?p=928330#post928330). This new feature is a favourite of mine. Thanks for the addition!
blutach
9th January 2007, 04:57
@linx05
One final thing you might do before deleting the lines (which I am totally sure are junk) is to do a search in PgcEdit for "set gprm(1)" (and gprm(2)). Make sure no command ever sets them to a non-zero value.
Regards
zyzyx
10th January 2007, 02:12
I think I have a new one. Of course I could be completely nuts for trying to do this. I inheirited scenarist and have taught myself how to use it, (learning curve steeper than Mount Everest). But I can now output a reasonably professional looking dvd. When I started with it, I made a dvd 4:3, 720X480 with button highlights from photoshop.
I placed the buttons outside the safe zone (didn't know any better) and in the final product some of the graphics and buttons were off screen when played. Everything worked but it just looked bad.
Well I was toying around with the original the other day and I thought, what if I changed the domain stream attributes to 16:9 letterboxed? Sounded like a good idea at the time.
I am using version 7.4 and changed all of the DSA's to 16:9 and checked letterbox. When I viewed the final result. I was suprised to find that It looked good with good resolution, But the menu button highlights are still in 4:3.
I could not find anywhere to change the subpicture aspect ratio. That is my guess at how to fix it at least.
You are probably asking yourself, why anyone would want to do that anyway....LOL. I am still pretty new on PGCedit but I seem to learn more by doing strange stuff.
Any Ideas?
r0lZ
10th January 2007, 03:37
You cannot change the buttons highlights, as they are hardcoded in the subpic stream, and are NOT scaled proportionally to the resolution in Domain Stream Attributes by the player. Unfortunately, you have to reauthor your menu in 16:9 letterboxed to obtain what you want. Furthermore, on a 16:9 TV, your reauthored subpics will also be wrong. You need to provide at least two subpic streams for 16:9: one for the true 16:9 (as displayed on a 16:9 TV) and one for the 4:3 letterboxed.
IMO, it is probably easier to redo the 4:3 menu with Scenarist.
zyzyx
10th January 2007, 03:53
I kind of figured as much. I know that scenarist will create two subpic streams when using photoshop imported images. One for 4:3 and the other for 16:9. One of the few things that it does automatically without extreme effort on your behalf....!
I thought that as great as pgcedit was there might be a chance that I was overlooking something.
Thankyou for your timely response and all your great work with the prog. (pgcedit)
Still nothing better to debug dvd's with!!!
r0lZ
10th January 2007, 03:56
Thanks for your appreciation!
And, BTW, I forgot to say: Welcome to the forum!
r0lZ
13th January 2007, 15:14
PgcEdit v8.0 beta 14 is available here (http://download.videohelp.com/r0lZ/pgcedit/beta/).
I have just fixed a problem with the Kill Playback function (described here (http://forum.doom9.org/showthread.php?p=933511#post933511).)
Most other changes are little bug fixes, and several improvements to load some severely damaged IFOs (as found on some new ARccOS protected releases.)
blutach
14th January 2007, 02:26
Thanks r0lZ
Regards
dirio49
14th January 2007, 18:04
Thanks. r0lZ
r0lZ
15th January 2007, 11:43
There is a big bug introduced in beta 14 and fixed in beta 15. The Reorder TTNs did not reorder the TTNs correctly in some cases. As a consequence, Delete Uncalled PGCs failed also.
DO NOT USE BETA 14 ANY MORE, and download beta 15 here (http://download.videohelp.com/r0lZ/pgcedit/beta/).
This beta fixes also some minor bugs or problems.
Sir Didymus
16th January 2007, 09:39
Hi r0lZ,
I have a little doubt: most time I am using the very powerful command editor of PgcEdit as a "reference manual" for checking of some VM commands...
Looking at the JumpSS to VTSM command:
30 06 00 00 01 83 00 00
It seems the value 00 is accepted as a valid TTN number (byte 4)... Is it valid to set 0 as a valid TTN number for sprm(5) ? Shouldn't it be restricted to 1-99 ?
r0lZ
16th January 2007, 09:50
See the note in the editor:
"Setting the VTS to 0 means Last visited VTS. However, IfoEdit complains about this."
I think it can be used in the FP-PGC or the VMGM to return automatically to the menu of the last visited VTS. Furthermore, it can be used in a VTSM menu to jump to itself, but in this case, the VTS number must be 0!
Of course, I'm not God, and I may be wrong, but I have tested that on my Sony and it works well. I have not tested that command in the VMGM when no VTS has been accessed yet!
IIRC, I've found that info on mpucoder's DVD-Information site.
[EDIT] See also this thread (http://forum.doom9.org/showthread.php?t=79536). Obviously, the command is legal, at least in the VMGM.
I don't know if sprm 5 can be 0 as well, but anyway sprm 5 is the TTN number inside the VTS, not the VTS itself.
President
16th January 2007, 13:32
2 r0lZ.
Thank's for a new beta :thanks:.
A little suggestion. Would you want to add to the "Find Jumps to nowhere" function a search for non-existent program links, like LinkPGN? And cell too:).
r0lZ
16th January 2007, 13:44
The Next/Prev/GoUp links are already checked.
But currently, only the target PGCs are checked, not the cells, PGs and PTTs. Checking them is a big job. Maybe I'll do that for a next release...
President
16th January 2007, 13:50
...Maybe I'll do that for a next release...
Thank's.
Sir Didymus
16th January 2007, 19:38
...Furthermore, it can be used in a VTSM menu to jump to itself, but in this case, the VTS number must be 0!
...
[EDIT] See also this thread (http://forum.doom9.org/showthread.php?t=79536). Obviously, the command is legal, at least in the VMGM.
I don't know if sprm 5 can be 0 as well, but anyway sprm 5 is the TTN number inside the VTS, not the VTS itself.
Thanks for the link; the VTS parameter usage was clear to me (...hem... I just used the "1" based indexing to designate the first byte of the command... sorry for the introduced confusion... :scared: ).
However the reading of the (very nice) thread you pointed out is still not clarifying my doubts:
1) what could be the reason for having a parameter, in a command jumping from FP-PGC or from VMGM to a VTSM menu, to set SPRM(5) to a given TTN value ?
2) in all other commands, the TTN parameter (which is referencing a valid DVD title) is restricted between 1 and 99. Why, just for this command, the value 0 is admitted ?
r0lZ
16th January 2007, 21:33
OK, understood!
I don't remember why I did that that way.
Perhaps it's because there was at that time a discussion on the legality of the TTN 0? I remember that mpucoder said that 0 means 'not defined' or 'last accessed' like the VTS parameter, but I'm not sure it was about this parameter. BTW, nobody understands exactly why the TTN parameter is present in this command, and how it should be used. Setting sprm 5 is fine, but why should we need that?
Or it's simply a little bug of my own. Note also that the valid range displayed in the GUI is 1-99. I cannot forbid 0 in the input box so that the user can type an hex (0xNN) or octal (0NN) number. But the validation of the command should probably be a little more strict. If you find somewhere that it must be > 0, then I'll change the validation code...
rack04
19th January 2007, 19:11
I was trying to "Delete Uncalled PGCs" using PgcEdit v 8.0beta15 and got the following error message. Any ideas?
Here is a copy/past if the attachment doesn't work.
invalid command name ".mf.f2.selector.a.lb"
invalid command name ".mf.f2.selector.a.lb"
while executing
".mf.f2.selector.a.lb itemconfigure $item -background #FFE0E0"
(procedure "show_crossrefs" line 235)
invoked from within
"show_crossrefs true"
(procedure "find_all_uncalled" line 30)
invoked from within
"find_all_uncalled"
(procedure "::utils::delete_all_uncalled" line 12)
invoked from within
"::utils::delete_all_uncalled"
(menu invoke)
r0lZ
19th January 2007, 19:20
Hum, it's a GUI bug in the window that is supposed to display the result of the search of the SPRMs that can be potentially dangerous when using this function.
I don't know why it happens for you, as I have never encountered it.
Can you send me your original IFOs? pgcedit [at] scarlet [dot] be. Thanks.
rack04
19th January 2007, 19:53
Email sent. Thanks for you continued support and great work.
r0lZ
20th January 2007, 14:45
Hum, I can't reproduce the problem. Maybe it is dependent of some menu buttons. If you have still your original menu on hard disc, can you shrink it with MenuShrink, and send it also? Thanks.
Also, can you try to delete uncalled PGCs again, but be sure to launch PgcEdit and do it immediately. It is possible that the bug happens only when PgcEdit has been used with another DVD before.
Anyway, I'll try to fix this potential bug. Perhaps I don't need your files.
r0lZ
20th January 2007, 14:53
Sorry, forget my previous post. I think I have discovered the problem.
Can you confirm that you have launched Delete Uncalled PGCs when the PGC selector pane was hidden? The command that failed assumes that it is visible. (It's the command that highlight the uncalled PGCs in pink in the PGC selector.)
r0lZ
20th January 2007, 15:19
I'm almost sure the problem was caused by the hidden PGC selector pane. I got exactly the same error when using the function in that situation. It's fixed now. I'll release v8 soon. In the meantime, enable View -> PGC Selector before using this function.
BTW, I've verified my code, and a similar bug was present at 3 other places! I use always PgcEdit with the PGC selector pane visible (as, apparently, almost all users do), so I haven't trapped this bug before. Thanks for your useful bug report!
rack04
20th January 2007, 16:55
Sorry, forget my previous post. I think I have discovered the problem.
Can you confirm that you have launched Delete Uncalled PGCs when the PGC selector pane was hidden? The command that failed assumes that it is visible. (It's the command that highlight the uncalled PGCs in pink in the PGC selector.)
Can you tell me how to un-hide the PGC selector pane? So that I can confirm. Sorry nevermind, I should have read through your post more completely.
CONFIRMED: EVERYTHING WORKED GREAT WITH PGC SELECTOR VISABLE.
r0lZ
20th January 2007, 17:04
Thanks! That confirm that the bug is fixed.
Robotik
21st January 2007, 00:34
Delete Uncalled PGCs is awesome! thanks a lot!
r0lZ
23rd January 2007, 09:31
See the new PgcEdit v8 thread (http://forum.doom9.org/showthread.php?t=121146).
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.