Kulyok Posted March 18, 2007 Author Share Posted March 18, 2007 In the code I tried above, the main component asks about installation. There is no SUBCOMPONENT or FORCED_SUBCOMPONENT action; it is one component, with the inclusion of user input as to what values are used in compiling. Since it is a question asked and answered, and then BAFs are compiled, we certainly *don't* want anyone exiting until the full component is installed!!!! Well, if you say so. Link to comment
Kulyok Posted March 18, 2007 Author Share Posted March 18, 2007 So, what I have currently - er, not me, but Nythrun, cmorgan and CamDawg, mostly, but you get the idea. /* XAN ROMANCE */ BEGIN @1015 /* The BG1 NPC Project: Xan's Romance Core (teen content) */ GROUP @1010 /* The BG1 NPC Project: Romances */ REQUIRE_FILE ~override/X#BG1NPCCore.G3~ @1004 /* BG1 NPC Required Changes component is not installed. */ COPY ~BG1NPC/Core/X#component.xx~ ~override/X#XanRomance.G3~ /* sound */ COPY ~BG1NPC/Phase3/XAROM/Sound/X#BLANK.WAV~ ~override~ ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN /* Script */ EXTEND_TOP ~_XAND.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAROD.BAF~ EXTEND_TOP ~_XAN.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAROM.BAF~ EXTEND_TOP ~_HARTEEL.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XASTRE.baf~ EXTEND_TOP ~_JAHEIRA.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAJARE.baf~ EXTEND_TOP ~_ONTARON.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAMORE.baf~ EXTEND_TOP ~_TIAX.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XATIRE.baf~ EXTEND_TOP ~_MINSC.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAMIRE.baf~ EXTEND_TOP ~_QUAYLE.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAQURE.baf~ EXTEND_TOP ~_EDWIN.BCS~ ~BG1NPC/Phase3/XAROM/BAF/X#XAEDRE.baf~ END ELSE BEGIN /* BGT Versions */ /* Script */ EXTEND_TOP ~XAND.BCS~ ~BG1NPC/BGT/BAF/X#XAROD.BAF~ EXTEND_TOP ~XAN.BCS~ ~BG1NPC/BGT/BAF/X#XAROM.BAF~ EXTEND_TOP ~SHARTEEL.BCS~ ~BG1NPC/BGT/BAF/X#XASTRE.baf~ EXTEND_TOP ~BGJHEIRA.BCS~ ~BG1NPC/BGT/BAF/X#XAJARE.baf~ EXTEND_TOP ~MONTARON.BCS~ ~BG1NPC/BGT/BAF/X#XAMORE.baf~ EXTEND_TOP ~TIAX.BCS~ ~BG1NPC/BGT/BAF/X#XATIRE.baf~ EXTEND_TOP ~BGMINSC.BCS~ ~BG1NPC/BGT/BAF/X#XAMIRE.baf~ EXTEND_TOP ~QUAYLE.BCS~ ~BG1NPC/BGT/BAF/X#XAQURE.baf~ EXTEND_TOP ~BGEDWIN.BCS~ ~BG1NPC/BGT/BAF/X#XAEDRE.baf~ END /* Xan's Dream 2DA set up */ COPY ~BG1NPC/Phase3/XAROM/MOS/XANDREAM.MOS~ ~override~ COPY ~BG1NPC/Phase3/XAROM/MOS/X#BLANK.2da~ ~override/XANDREAM.2da~ REPLACE_TEXTUALLY ~IMAGE~ ~XANDREAM~ REPLACE 99999 @475 /* Xan romance timer */ DEFINE_ACTION_MACRO ~set_timer_for_xans_romance~ BEGIN PRINT ~Select Xan's Romance Speed: [1] 1 hour (standard) [2] 45 minutes [3] 30 minutes [4] 15 minutes [5] 1 hour 30 minutes (extended) Input your choice and press enter.~ ACTION_READLN ~xantimer~ ACTION_IF NOT (IS_AN_INT ~xantimer~) THEN BEGIN PRINT ~Please, choose 1,2,3,4 or 5 and press enter.~ LAUNCH_ACTION_MACRO ~set_timer_for_xans_romance~ END ELSE BEGIN ACTION_IF (("xantimer" != 1) AND ("xantimer" != 2) AND ("xantimer" != 3) AND ("xantimer" != 4) AND ("xantimer" != 5)) THEN BEGIN PRINT ~Please, choose 1,2,3,4 or 5 and press enter.~ LAUNCH_ACTION_MACRO ~set_timer_for_xans_romance~ END ELSE BEGIN ACTION_IF ("xantimer" = 2) THEN BEGIN APPEND ~gtimes.ids~ ~2700 XAROM_TIMER~ END ACTION_IF ("xantimer" = 3) THEN BEGIN APPEND ~gtimes.ids~ ~1800 XAROM_TIMER~ END ACTION_IF ("xantimer" = 4) THEN BEGIN APPEND ~gtimes.ids~ ~900 XAROM_TIMER~ END ACTION_IF ("xantimer" = 1) THEN BEGIN APPEND ~gtimes.ids~ ~3600 XAROM_TIMER~ END ACTION_IF ("xantimer" = 5) THEN BEGIN APPEND ~gtimes.ids~ ~5400 XAROM_TIMER~ END END END END LAUNCH_ACTION_MACRO ~set_timer_for_xans_romance~ /* dialogue */ ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN COMPILE ~BG1NPC/Phase3/XAROM/DLG/X#XANLT.D~ END ELSE BEGIN /* BGT Versions */ COMPILE ~BG1NPC/BGT/DLG/X#XANLT.D~ END Upon reinstalling/uninstalling, XAROM_TIMER gets deleted from gtimes.ids, so there's no messing with that, thankfully. And, yeah - tested it, and it works. No need for a temporary folder, thanks to Cam, and no need for separate components, thanks to Nythrun and cmorgan. Phew! Three more romances to go... Link to comment
Nythrun Posted March 18, 2007 Share Posted March 18, 2007 Sorry about the delay - when your doctor tells you not to drink while you're on this immunosupressant, it's not actually a good idea to knock back a few whiskeys Fortunately, you don't need my input at all, because that looks great And should be easier to maintain than a bunch of SUBCOMPONENTS If you really want an additional option to not install, you can change your PRINT sequence to something like PRINT ~Select Xan's Romance Speed: [0] I changed my mind, no Xan after all! [1] 1 hour (standard) [2] 45 minutes [3] 30 minutes [4] 15 minutes [5] 1 hour 30 minutes (extended) Input your choice and press enter. and then include in the nested ACTION_IFs: ACTION_IF NOT (IS_AN_INT ~xantimer~) THEN BEGIN PRINT ~Please, choose 1,2,3,4 or 5 and press enter.~ LAUNCH_ACTION_MACRO ~set_timer_for_xans_romance~ END ELSE BEGIN ACTION_IF ("xantimer" = 0) THEN BEGIN FAIL ~Make up your mind already - Xan is well written and you should install it!~ END ACTION_IF (("xantimer" != 1) AND ("xantimer" != 2) AND ("xantimer" != 3) AND ("xantimer" != 4) AND ("xantimer" != 5)) THEN BEGIN PRINT ~Please, choose 1,2,3,4 or 5 and press enter.~ LAUNCH_ACTION_MACRO ~set_timer_for_xans_romance~ END ELSE BEGIN and the user can back out even after saying yes...I wouldn't bother, but the option is certainly there if you want it If you do this, installation of the whole component will be halted and WeiDU will uninstall what it's installed already regardless of the order (it's "nicer" coding to do this early so WeiDU doesn't waste a few milliseconds installing stuff that it might uninstall - raise your hand if you care ) EVALUATE_BUFFER isn't flaky, honest, and it's a powerful way to avoid having to do COPY ~mydialog.d~ ~override~ REPLACE_TEXTUALLY EXACT_MATCH ~imoen_dv~ ~%imoen_dv%~ REPLACE_TEXTUALLY EXACT_MATCH ~xan_dv~ ~%xan_dv%~ REPLACE_TEXTUALLY EXACT_MATCH ~firewine_bridge~ ~%firewine_bridge%~ ETC_ETC As long as you set up a percentage sign variable at some point so you can have "10 %percentage_sign% chance to do something" in your item descriptions it's perfectly safe You can certainly get by with REPLACE_TEXTUALLY (Cam never uses EVALUATE_BUFFER, and I should tell him how to code?) but I've found it quite helpful Letter recognition in .tp2 is certainly possible (and ACTION_READLN can take text as well as numbers if you want it to). ACTION_IF ((~%xan_timer%~ STRING_MATCHES_REGEXP ~[^pqr]~) = 0) THEN BEGIN LAUNCH_THE_MACRO_AGAIN_BECAUSE_USER_PICKED_SOMETHING_SILLY is how you'd do this in WeiDU. But yeah, that's sharp Link to comment
Kulyok Posted March 18, 2007 Author Share Posted March 18, 2007 Thank you! Thank you very much, this does make sense - and yeah, it all seems much clearer to me now. I'll stick with what I've got, I think - cmorgan has graciously allowed me to make do with TUTU side only - he'll pick up BGT side from there, so filename replacements will be on his conscience. (And it seems that one more good thing has come from all of this: I will now actually be able to read all this scary stuff you guys and gals post in "code" tags. And yay to that!) Link to comment
cmorgan Posted March 18, 2007 Share Posted March 18, 2007 Plus, Kulyok, when I get working code back from you, I will be tinkering and editing to see if we can actually move the whole deal to single-files with variable substitution for Imoen's DV, the banter/join files, etc. As long as you set up a percentage sign variable at some point so you can have "10 %percentage_sign% chance to do something" in your item descriptions it's perfectly safe You can certainly get by with REPLACE_TEXTUALLY (Cam never uses EVALUATE_BUFFER, and I should tell him how to code?) but I've found it quite helpful Nythrun, that is a smart idea... and no wonder I had the bigg and pro5 jumping me through hoops to get a R_T to work on tp2 code!!!! I should have set a variable for percentage sign. I can now go back and set up the initial tp2 and TRA files correctly, and actually use EVALUATE_BUFFER. I want to set the variables up front, then just roll through the install with everything in place. I think this will make things much easier. Just that one last question... ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN OUTER_SPRINT "BGT_VAR" "" END ELSE BEGIN OUTER_SPRINT "BGT_VAR" "!Global("ENDOFBG","GLOBAL",2)" END and then put materials like IF %BGT_VAR% Global("X#TiaxKicksImoen","GLOBAL",1) and CHAIN IF WEIGHT #-2 ~%BGT_VAR% Global("X#TiaxKicksImoen","GLOBAL",2)~ ~%TIAX_JOINED%~ X#TiaxKicksImoenStarts ~Tiaxs KICKS All!~ == ~%IMOEN_BANTER%~ IF ~InParty("%IMOEN_DV%) InMyArea("%IMOEN_DV%) !StateCheck("%IMOEN_DV%,CD_STATE_NOTVALID)~ THEN ~Ouch!!!~ END ++ ~Stop That. It's Silly.~ DO ~SetGlobal("X#TiaxKicksImoen","GLOBAL",3)~ EXIT If I have this set up correctly, then we really can just have the BGT variable (the last remaining code difference besides state numbering) put into one single master file... Link to comment
Nythrun Posted March 18, 2007 Share Posted March 18, 2007 Looks fine to me Actually - if the triggers necessary for BGT are all of the format !Global("ENDOFBG","GLOBAL",2) I don't see why you couldn't just add them in regardless - since this Global isn't set in Tutu it will always have a value of zero and this trigger will always return true. But as long as you're saving yourself icky grunt work, great Link to comment
cmorgan Posted March 18, 2007 Share Posted March 18, 2007 Would adding an always-true trigger slow the scripts/dialogue? The only reason I restrict this is to keep the Tutu side "clean" - if it does not delay processing, then we just add it and not worry. Or I stick with my drive to see things "clean" and put the darned variable in... those nested " s don't need any special treatment? Link to comment
Nythrun Posted March 18, 2007 Share Posted March 18, 2007 A single trigger? You'd never, ever notice it - but it's cleaner without spurious triggers, and you've already figured out how to avoid them, so I'm not recommending you change anything % is pretty much the only thing that will require special handling: BEGIN ~Examine EVALUATE_BUFFER~ <<<<<<<<asdf.file @ = ~This is a .tra string "with" (""a"",''lot'',0) of normally reserved characters $@!^&[]"'.+*~ >>>>>>>> COPY - ~asdf.file~ ~asdfasdf.file~ PATCH_IF SOURCE_SIZE THEN BEGIN SET initial_size = SOURCE_SIZE READ_ASCII 0x0 ~initial_file~ ("initial_size") EVALUATE_BUFFER END COPY - ~asdfasdf.file~ ~asdfasdf.file~ PATCH_IF SOURCE_SIZE THEN BEGIN SET post_evaluation_size = SOURCE_SIZE READ_ASCII 0x0 ~post_evaluation_file~ ("post_evaluation_size") PATCH_IF (~%post_evaluation_file%~ STRING_EQUAL ~%initial_file%~) THEN BEGIN PATCH_PRINT ~Hey, they're the same!~ END ELSE BEGIN PATCH_PRINT ~Oops, they're not the same!~ END END Link to comment
berelinde Posted March 18, 2007 Share Posted March 18, 2007 My vote is that we keep BGT-specific variables on the BGT side only, unless there's a way to get *everything* else to install from single files. As long as we're going to need separate BGT files for chapter numbers, area checks, DV's, or what-have-you, I would rather keep all the BGT stuff separate and not start mixing it up. I kind of like being able to tell which flavor file I'm looking at just from a quick glance at the globals. If that code for swapping areas, chapters, etc. ever works out and we *do* move to a single platform-independent file system, then I would say go ahead and put all those BG2 checks in. Link to comment
cmorgan Posted March 18, 2007 Share Posted March 18, 2007 Well, damn. Forgot Chapters. Another set of variables. OK, 2 hurdles left, both of which we can variable; chapter#s and state#s. Each can be done the hard way (for me not for you), so both of you can concentrate on the Tutu files only, and I will use your Tutu-fixed and tested versions as master files. Nythrun, you don't happen to know how to manipulate STATE_WHICH_SAYS in a reasonable fasion, so that I can finalize the darned I_T_Cs and R_Ts: on Tutu side REPLACE_STATE_TRIGGER _BYESLI 9 ~InteractingWith("kagain") RandomNum(8,1) Global("X#BIOYE1","LOCALS",0)~ ADD_TRANS_ACTION _BYESLI BEGIN 9 END BEGIN END ~SetGlobal("X#BIOYE1","LOCALS",1)~ REPLACE_STATE_TRIGGER _BMINSC 7 ~InteractingWith("dynaheir") RandomNum(2,1) Global("X#BIOMI1","LOCALS",0)~ ADD_TRANS_ACTION _BJAHEI BEGIN 0 END BEGIN END ~SetGlobal("X#BIOJA1","LOCALS",1)~ on BGT side REPLACE_STATE_TRIGGER BYESLI 9 ~InteractingWith("kagain") GlobalLT("ENDOFBG1","GLOBAL",2) RandomNum(8,1) Global("X#BIOYE1","LOCALS",0)~ ADD_TRANS_ACTION BYESLI BEGIN 9 END BEGIN END ~SetGlobal("X#BIOYE1","LOCALS",1)~ REPLACE_STATE_TRIGGER BMINSC 106 ~InteractingWith("dynaheir") GlobalLT("ENDOFBG1","GLOBAL",2) RandomNum(2,1) Global("X#BIOMI1","LOCALS",0)~ ADD_TRANS_ACTION BJAHEIR BEGIN 461 END BEGIN END ~SetGlobal("X#BIOJA1","LOCALS",1)~ If I could swap this out for some kind of STATE_WHICH_SAYS, I don't have to set a bunch of silly state number variables, plus it will work with those crazy people who actually like to mess upexpand their installs with all that BP stuff. Not that I'm volunteering to eer troubleshoot one of those - just want the widest possible audience for this work. so far I would have to do REPLACE_STATE_TRIGGER %YESLICK_BANTER% %TS_YES9% ~%BGT_VAR% InteractingWith("kagain") RandomNum(8,1) Global("X#BIOYE1","LOCALS",0)~ Link to comment
Nythrun Posted March 18, 2007 Share Posted March 18, 2007 Yes, but you'll not be able to use STATE_WHICH_SAYS alone for that dialogue, as the strref is used more than once. I honestly only know how to do this with a patch on the compiled .d file, there's probably better ways, because this gets ugly fast. OUTER_SET "this_is_normally_state_nine" = STATE_WHICH_SAYS @100000 FROM ~_byeslick.dlg~ ACTION_IF (("this_is_normally_state_nine" = (0-3)) OR ("this_is_normally_state_nine" = (0-1))) THEN BEGIN FAIL ~Yeslick dialogue changed beyond easy recognition.~ END ACTION_IF ("this_is_normally_state_nine" = (0-2)) THEN BEGIN OUTER_PATCH ~blargh~ BEGIN SAY 0x0 @100000 READ_LONG 0x0 "desired_state_strref" END COPY_EXISTING - ~_byeslick.dlg~ ~override~ READ_LONG 0x8 "count_of_states" READ_LONG 0xc "offset_to_states" FOR ("i1" = 0x0; "i1" < "count_of_states"; "i1" += 0x1) BEGIN READ_LONG ("offset_to_states" + ("i1" * 0x10) + 0x00) "strref" PATCH_IF ("strref" = "desired_state_strref") THEN BEGIN READ_LONG ("offset_to_states" + ("i1" * 0x10) + 0x0c) "trigger_count" PATCH_IF ("trigger_count" = 0x2) THEN BEGIN SET "this_is_normally_state_nine" = "i1" SET "i1" = "count_of_states" END END END END Somewhere in the .tra: @100000 = ~'Twould be good if you tithed a few coins now and then. The favor of gods is worth a few gold.~ Link to comment
cmorgan Posted March 19, 2007 Share Posted March 19, 2007 OK, that gives me a start... and makes my head hurt a little, so I will go back and do some more reading.In the meantime, for everyones's reading pleasure, we may be hitting the wall on OUTER_SPRINT. With combinations of these, and some more I keep running into we might just be able to keep one code set, built for both platforms, and easily upradeable should the New Improved Merger ever happen (just a matter of renaming the variables) http://dev.gibberlings3.net/index.php/Cate...atformVariables commentary welcome. Especially if someone can shed light on performance gain/loss over straight COPY. Link to comment
Nythrun Posted March 19, 2007 Share Posted March 19, 2007 I will say two caveats: No one is patching dialogues that way - even researching state numbers in advance and "hard coding" lookup table of state numbers in the .tp2 is still way, way more compatibility than you're going to get from the usual methods. It'll save you work. You really don't need a fully recursive macro for a single variable romance timer - I was going to mention this yesterday and forgot - very sorry. OUTER_SPRINT ~xan_romance_timer~ ~placeholder_value~ OUTER_WHILE (!(IS_AN_INT ~xan_romance_timer~) OR (~xan_romance_timer~ > 0x5)) BEGIN ACTION_READLN ~xan_romance_timer~ END is quite sufficient when you're only asking for a single value Link to comment
Kulyok Posted March 22, 2007 Author Share Posted March 22, 2007 Just wanted to say thank you for this thingy. So, in case someone wants some workable code: /* BRANWEN ROMANCE */BEGIN @1014 /* The BG1 NPC Project: Branwen's Romance Core (teen content) */ GROUP @1010 /* The BG1 NPC Project: Romances */ REQUIRE_FILE ~override/X#BG1NPCCore.G3~ @1004 /* BG1 NPC Required Changes component is not installed. */ /* Branwen romance timer */ PRINT ~Select Branwen's Romance Speed:~ PRINT ~ [1] 1 hour (standard) [2] 45 minutes [3] 30 minutes [4] 15 minutes [5] 1 hour 30 minutes (extended) Input your choice and press enter.~ OUTER_SPRINT ~brantimer~ ~placeholder_value~ OUTER_WHILE (!(IS_AN_INT ~brantimer~) OR (~brantimer~ > 0x5)) BEGIN ACTION_READLN ~brantimer~ END ACTION_IF ("brantimer" = 1) THEN BEGIN APPEND ~gtimes.ids~ ~3600 BRROM_TIMER~ END ACTION_IF ("brantimer" = 2) THEN BEGIN APPEND ~gtimes.ids~ ~2700 BRROM_TIMER~ END ACTION_IF ("brantimer" = 3) THEN BEGIN APPEND ~gtimes.ids~ ~1800 BRROM_TIMER~ END ACTION_IF ("brantimer" = 4) THEN BEGIN APPEND ~gtimes.ids~ ~900 BRROM_TIMER~ END ACTION_IF ("brantimer" = 5) THEN BEGIN APPEND ~gtimes.ids~ ~5400 BRROM_TIMER~ END COPY ~BG1NPC/Core/X#component.xx~ ~override/X#BranwenRomance.G3~ /* script */ ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN EXTEND_TOP ~_BRANWE.BCS~ ~BG1NPC/Phase3/BRROM/BAF/P#BRROM.baf~ EXTEND_TOP ~_BRANWD.BCS~ ~BG1NPC/Phase3/BRROM/BAF/P#BRROD.baf~ END ELSE BEGIN /* BGT Versions */ EXTEND_TOP ~BGBRANW.BCS~ ~BG1NPC/BGT/BAF/P#BRROM.baf~ EXTEND_TOP ~BRANWD.BCS~ ~BG1NPC/BGT/BAF/P#BRROD.baf~ END /* dialogue */ ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN COMPILE ~BG1NPC/Phase3/BRROM/DLG/P#BRLT.D~ END ELSE BEGIN /* BGT Versions */ COMPILE ~BG1NPC/BGT/DLG/P#BRLT.D~ END Note that the timer gets installed first, in case any files compiled below might need it. Link to comment
cmorgan Posted March 30, 2007 Share Posted March 30, 2007 OK, two follow-ups from successfully installed and tested code, and some checks with the bigg -- a reminder to anyone tinkering that if your variable uses one type of delimeter ("", %%, ~~) then you need to use a second one. While /* BGT-only shutdown of D and BAF after BG1 content */ OUTER_SPRINT ~BGT_VAR~ ~!Global("ENDOFBG1","GLOBAL",2)~ works, "BGT_VAR" "!Global("ENDOFBG1","GLOBAL",2)" fails to parse. #2 - the code OUTER_SPRINT ~brantimer~ ~placeholder_value~ OUTER_WHILE (!(IS_AN_INT ~brantimer~) OR (~brantimer~ > 0x5)) BEGIN ACTION_READLN ~brantimer~ END is beautiful, simple, etc... but for the end user, if you put an incorrect value in, it appears to the user as if the process has "stalled" - you hit return, and get a blank space. Most users would kill the process, FUBAR'ring their install. I understand the ACTION_IF's above, but modifying an OUTER_WHILE is a liitle more tricky... can i do something like /* DYNAHEIR ROMANCE */ BEGIN @1012 /* The BG1 NPC Project: Dynaheir's Romance Core (teen content) */ GROUP @1010 /* The BG1 NPC Project: Romances */ REQUIRE_FILE ~override/X#BG1NPCCore.G3~ @1004 /* BG1 NPC Required Changes component is not installed. */ /* makes sure PIDs go last */ UNINSTALL ~bg1npc.tp2~ 200 /* Dynaheir's romance timer */ PRINT @1104 PRINT @1102 OUTER_SPRINT ~dynatimer~ ~placeholder_value~ OUTER_WHILE (!(IS_AN_INT ~dynatimer~) OR (~dynatimer~ > 0x5)) BEGIN PRINT ~Please choose between 1, 2, 3, 4, or 5~ ACTION_READLN ~dynatimer~ END ACTION_IF ("dynatimer" = 1) THEN BEGIN APPEND ~gtimes.ids~ ~3600 DYROM_TIMER~ END ACTION_IF ("dynatimer" = 2) THEN BEGIN APPEND ~gtimes.ids~ ~2700 DYROM_TIMER~ END ACTION_IF ("dynatimer" = 3) THEN BEGIN APPEND ~gtimes.ids~ ~1800 DYROM_TIMER~ END ACTION_IF ("dynatimer" = 4) THEN BEGIN APPEND ~gtimes.ids~ ~900 DYROM_TIMER~ END ACTION_IF ("dynatimer" = 5) THEN BEGIN APPEND ~gtimes.ids~ ~5400 DYROM_TIMER~ END and how do I stop a 0 entry? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.