ok, here is my code problem in a nutshell:


This is lines 30-33 of the worldtrade include that comes with twx. I kept the 'sys_check' because it is a side puzzler, I'm assuming a remnant from an older version of twx?

My main question is with includes and the ~ key, which is not even alluded to in the include description in the script reference. I'm assuming that the above is assigning an address (:WorldTrade~Sub_MoveCheck) to a variable. So the variable $CheckSub in the Move include is now :WorldTrade, an address in the Sub_MoveCheck subroutine?

I guess I just want a better reference for INCLUDE than:

INCLUDE scriptname

Description:

This macro will include the code from another script or pack2 include file during compilation.

Example:

include "includemove"

the syscheck is a remnant from older TWX's.

when workign with Includes, a routine in one Include file may need the result(s) from another Include file. The safest way to pass variables from one include to another is the method you quoted above. It is possible for one include to access variables directly from another 'Include' file. It's a good idea to think of the Main file as the controller, sending tasks to routines, and sending the variable-results as required. If your Includes start accessing variables directly from Include to Include.. debugging will become a nightmare.

In terms of Memory. :WorldTrade~CheckSub and say :Haggle~CheckSub, are two independant variables. In much the same fashion as:

SetVar CheckSub1 "Good"
SetVar CheckSub2 "No Good"

varabiles are seperate and independant. The Tilde '~' Differentiates between which 'CheckSub' your working with. Remember, that when the script is compiled, the code from all files are placed into one contiguous segment/file.

A good tip I learned from Mind Dagger: Keep your Includes at the bottom of the main file. TWX works Top-Down when searching for Labels (beit a Goto or Gosub). Keep your most critical routines as close to the top as possible.

...basic template I usually work with:

I only have time for a quick answer now, but ask further questions.

In TWX, when you include a file within your main file, you are essentially copy/pasting the contents of that include file into your main file. Got it?

This could create problems though because $variable names and :routine names might conflict. To avoid this, TWX basically renames all variables and headers that were in the include by prepending "includename~" to them. So if you had an include called "ep_include.ts", and in it you had a variable "$holds" and a header ":figrefresh", these would become "$ep_include~holds" for the variable and ":ep_include~figrefresh" for the header, all still within a single main script.

Code within an include can reference variables and headers within the calling or main script by using a blank include name, as in "$~variablename" and ":~headername". However, this isn't really advisable. The caller-include relationship should be:
1. the calling script sets any necessary variables in the include script (passes in variables).
2. the calling script gosubs a header/routine in the include.
3. the include returns after doing whatever
4. the calling script checks the value of variables in the include for the results (returns a value).

Now, please test this, as I could be wrong and haven't used includes in a while.

+EP+

I've had problems with that and saveVar tho. I had a routine that would exit out, pull the * stats, and import them into a file. Before the file, I was trying to save to variables. I couldn't saveVar from a routine and loadVar from main, it wouldn't load the right var.

This is what I use to help give the system time to 'catch up'



Also handy for breaking out of time intensive routines. You can actually $SX, no problem

It wasn't a matter of time, it was that variables read via loadVar don't translate $~var as $var. They're treated as two different variables.

Yeah. 'time' was bit of a misnomer. Should have said 'free the CPU'. I'm sure that if you tried a delay, it would resolve.

[Edit] 10ms would be too quick. A minimum of 100ms would give the CPU enough opportunity to do it's job

No, it wouldn't. I'm talking about saveVar, then later, many hours or days later, doing a loadVar. The problem isn't a matter of timing or CPU, it's a matter of variable name resolution.

Oops. Sorry. Your original response gave me the impression that the problem occured at run time.

Well technically it does, everything happens at run-time. But it's really an issue of what's getting written to, and read from, the .cfg file.