View unanswered posts | View active topics It is currently Wed Apr 22, 2026 11:19 pm



Reply to topic  [ 6 posts ] 
 Script menu input from another script. 
Author Message
Lance Corporal

Joined: Wed Apr 09, 2008 7:15 am
Posts: 3
Unread post Script menu input from another script.
I would like use one scripts with another script (sub-script). The problem is that the sub-script has a menu in it. I would like to automatically send the menu commands to the sub-script from the first script. Is there a way to do this and/or are there any plans on making changes to TWX so that it can be done?

I have found that you might be able to do this by running one TWX looking at Second TWX.
Ex. Client(Swath) > TWX > TWX > GameServer
The first TWX would reply to the script running in the second TWX. I have not tried this but I would rather not do it this way if I don’t have too.

Thanks,
Spaz


Tue Jul 14, 2009 2:40 pm
Profile
Commander
User avatar

Joined: Tue Oct 07, 2003 2:00 am
Posts: 1134
Location: Augusta, GA
Unread post Re: Script menu input from another script.
The burden is on the script writer to specify the type of input their script requires, and twx will not be altered to circumvent their design. If they chose to implement a menu with no way to bypass it, then you will have to do one of the following:
1. Input the selections by hand
2. Modify the script
3. Get the author to modify the script
4. Use a solution like you outlined, with two instances of twx.

+EP+

_________________
Claim to Fame: only guy to ever crack the TW haggle algorithm, and fig/shield/hold price formula, twice.


Tue Jul 14, 2009 5:35 pm
Profile WWW
Ambassador
User avatar

Joined: Mon Feb 09, 2004 3:00 am
Posts: 3141
Location: Kansas
Unread post Re: Script menu input from another script.
Spazomatic wrote:
I would like use one scripts with another script (sub-script). The problem is that the sub-script has a menu in it. I would like to automatically send the menu commands to the sub-script from the first script. Is there a way to do this and/or are there any plans on making changes to TWX so that it can be done?

I have found that you might be able to do this by running one TWX looking at Second TWX.
Ex. Client(Swath) > TWX > TWX > GameServer
The first TWX would reply to the script running in the second TWX. I have not tried this but I would rather not do it this way if I don’t have too.

Thanks,
Spaz


Do you have the sub-script source? If so and you want to keep it intact, you can use a timer to detect that it is being called, and then set the default values you want if the timer is activated. I use this method for my ztm script - no user input in 5 seconds, run the default values.

_________________
               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."


Tue Jul 14, 2009 5:57 pm
Profile ICQ
1st Sergeant

Joined: Wed Jan 26, 2005 3:00 am
Posts: 36
Location: Argentina
Unread post Re: Script menu input from another script.
There's a simpler way.

You can modify script #2 to check for the data in a file. If it finds the file and the data, it runs with those parameters. If not, you can have it display the menu. When the script completes the auto run, it clears the data in the external file. The only tedious part would be modifying the scripts in question to first check for data and run with it, then clear it when finished and the modification of the original script to write the data to the file and call the script in question.

EDIT: I believe you can have a simple textline trigger that script #1 will recognize and that script #2 will display to indicate passing control back to script #1.

Angoth


Tue Jul 14, 2009 11:03 pm
Profile
Commander
User avatar

Joined: Fri Jun 09, 2006 2:00 am
Posts: 1401
Location: Canada
Unread post Re: Script menu input from another script.
Code:
#Script1: Redirects key inputs: P, O  so Script 2 can capture them
:TOP
setTextOutTrigger   go   :go
pause
:go
getOutText $out
uppercase $out
if ($out = "P")
   processout "("
elseif ($out = "O")
   processout ")"
else
   processout $out
end
Goto :TOP


Code:
:Top
#Script2: This is the so called 'Menu'
setTextOutTrigger   go2   :go2 "("
setTextOutTrigger   go3   :go3 ")"
pause
:go2
killalltriggers
send "#"
goto :TOP
:go3
killalltriggers
send "\"
goto :TOP


Setting TWX1 to any TWGS Server, listening on Port 23, and then TWX2 to server 127.0.0.1, port 23 (listening on port 24, for example).. will work.

_________________
----------------------------
-= QUANTUM Computing 101: 15 = 3 x 5 ... 48% of the time.


Wed Jul 15, 2009 9:15 am
Profile ICQ YIM
Lance Corporal

Joined: Wed Apr 09, 2008 7:15 am
Posts: 3
Unread post Re: Script menu input from another script.
Thanks for the replys.

I am lucky that Rammer finally provided his source code. I was going to start working on his TSDT. As may have experienced, it is sometimes hard to get your corpies online at the same time to get this thing started. It would be easier to bot them with the startup settings. I will probably do a combination of all of the suggested. Make a default setting file and put a pause in the menu so that you can use it as it was designed, and since I will probably use something like MOMBot to call it, import the $Parms if they are there.

The reason that I asked is because I wanted to know if there was a easier way. Maybe a way to use one script that would input for all types of menu prompts. The only way that I see of doing it is if you do it like LoneStar and EP said, having two instances of TWX running. The problem with this is getting all of your corpies set up properly.


Wed Jul 15, 2009 1:43 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 6 posts ] 

Who is online

Users browsing this forum: No registered users and 36 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 © 2000, 2002, 2005, 2007 phpBB Group.
Designed by wSTSoftware.