It's for my friend's program.

Gamespy was a 3rd party that enabled people to play games multiplayer.

Gamespy shuts down and does not exist anymore but abandoning players and their game.

My friend wrote in perl code that would allow players to play unreal tournament game and found out some other games would function too.

The program has a main folder with 5 other folders which contain a number of files in them, and a start file.

#!/usr/bin/perl

package MasterServer;
use strict;
use warnings;
use Cwd 'abs_path';

our $ROOT;
BEGIN { ($ROOT = abs_path $0) =~ s{/util/masterserver\.pl$}{}; }
use lib $ROOT.'/lib';
use MasterServer;

our %S;
require "$ROOT/data/masterserver-config.pl";

#add %C from config.pl to OBJ
$MasterServer::OBJ->{$_}   = $S{$_} for (keys %S);

# load MasterServer core libs
MasterServer::load_recursive('MasterServer::Core', 
                                                'MasterServer::UDP',
                                                'MasterServer::TCP',
                                   'MasterServer::Util');

# Run the MasterServer process
MasterServer::run();
[download]

I can trace that out but I know there has to be a quicker way.

That is also the mean frame of the code.

I'm hoping to trace the whole program, from the maim to the sub-routines

I'm hoping to trace the whole program, from the maim to the sub-routines

You might be interested in Tool to record subroutine calls & return values and stevieb's followup here.

are you asking about what modules the program has loaded?

Then add just before MasterServer::run(); this line: use Data::Dumper; print Dumper(\%INC); . The (hashtable) variable %INC holds all the names of loaded packages (actually base-filenames) and their location on disk. Not to be confused with @INC which is the modules search path when loading modules by using use ... . Dumper() is a useful function for your purposes, it dumps the contents of complex variables, like hashtables. But it takes references to these variables (i.e. the use of \ in Dumper(\%INC))

Alternatively, find where the implementation of the method MasterServer::load_recursive is located (hint: it most likely is in a file called MasterServer.pm) and inject some print statements to see what's going on during execution.

Be warned that at various stages you may encounter an error message saying that a module, a package can not be found. That can actually be one of two problems: 1) this package does not exist in your system or 2) it does exist but perl can not find it because it is not in the @INC search path. Fix #1 by installing said module, like using a package manager (which you can install by cpan App::cpanminus;) using cpanm MyModule::XYZ or the already installed package manager cpan MyModule::XYZ . Fix #2 by adding more search-path-names to @INC, for example by adding use lib 'a-path-name'; at the beginning of your script.

By using print and print Dumper(\$some-variable) at strategic places in the script one will be able to get a sense of the code flow.

Also, in case you can't run this script and you are on a Unix/Linux system: find . -type f -iname '*.pm' will list all files ending in .pm or .PM in current dir and all its sub-dirs. If you can't run the program, getting the flow code is an exercise in meditation and zen.

edit: btw, there may be already a flag, a variable which turns logging and printing debugging messages ON. Keep an eye in case there is one.

edit: fixed a type in use Data::DumpER thanks to haukex

bw, bliako