Jump to content

MTA:MA Not retriving the entire map list.


Recommended Posts

  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

ok, the readme has totally fucked me on my part.

im up to this part.....

7. Disconnect MTA:mA and load mtaplus.mrc as a script in mIRC. Reconnect 
MTA:mA. You should see a new line in the log on the MTA:mA dialog that says it 
is connecting to MTAServer+ and another line if the connection has been 
successfully made. You can now use the MTAServer+ mIRC identifiers, commands 
and events (see below). Other mIRC scripts probably need some adjustments to 
make them work with the MTAServer+ identifiers/events instead of the MTA:mA 
ones. 
  
  
*** Scripting *** 
  
Identifiers 
  
$mtaplus.connected(Server) 
Returns $true if the script is connected to MTAServer+ for the specified 
server, and $false otherwise. 
  
$mtaplus.currentrace(Server) 
Returns the name of the current race of the server. Note that if not connected 
to MTAServer+, it is equivalent to using $mta.race(Server). 
  
Commands 
  
/mtaplus.connect <Server> 
Connect to MTAServer+ for the specified server. Connecting will only work if 
the MTAServer+ Ruby script is running on the server's machine. 
  
/mtaplus.disconnect <Server> 
Disconnect from MTAServer+ for the specified server. 
  
Events 
  
on *:SIGNAL:mtaplus.connect:command 
This event is triggered after a connection with MTAServer+ has been made. 
Parameters: $1 = Server 
  
on *:SIGNAL:mtaplus.disconnect:command 
This event is triggered after a connection with MTAServer+ has been closed. 
Parameters: $1 = Server 
  
on *:SIGNAL:mtaplus.startrace:command 
This event is triggered when MTAServer+ sends a map started-notification, or 
when MTA:mA triggers the mta.startrace-event if there is no connection with 
MTAServer+ at the moment for the server. 
Parameters: $1 = Server, $2- = Race name 
  

But i have No bloody clue in what files and where to add / replace whatever.

im running PRS 1.3 (Customised for us By Scooby)

But yeah..... im not no Scripting god or nothing. im auctually a Scripting Nub.

So where do i add all the commands?

Link to comment

I can't really help you with adjusting scripts to make them use the mtaplus* identifiers/events instead of the standard mta* ones. I have zero experience with big all-in-one scripts like PRS or GUS, and it could be a lot of work, for which I currently don't have the time. Maybe you can kindly ask Scooby to do it for you, or anyone else good at scripting.

However, in general, it should come down to replacing every instance of "$mta.race($1)" with "$mtaplus.currentrace($1)" in the script, and every "SIGNAL:mta.startrace" with "SIGNAL:mtaplus.startrace". The code handling the startrace-signal will have to be changed too, because the parameters don't match. Also don't forget to make a backup of the script first.

Link to comment

Sure, of course you can also create your own script that uses my workaround.

For example, the following script will show a message whenever a new map starts, and will show the current map when someone types !map:

  
on *:SIGNAL:mtaplus.startrace:{ 
  mta.text $1 Race started: $2- 
} 
  
on *:SIGNAL:mta.command:{ 
  if ($3 == !map) { 
    mta.text $1 Current race: $mtaplus.currentrace($1) 
  } 
} 
  

Link to comment

Which would completley interfere with PRS cos theres allreadt a !map command that is used to change map.....

and now im even more confused... as i have just realised that there is no brackets or anything in them commands or whatever in the scripting part of the readme....

all i want it to do is to retrive the map list shortly after MTAMA connects, and also after a new map is uploaded / removed from the server.

Link to comment

Well, I didn't think about PRS already having a !map command, but nothing prevents you to change it to something like !tellmethecurrentmapname, it can quickly be changed in the script itself.

If you want to have the whole maplist then I'm afraid my workaround won't do it for you; all it does is giving you the current mapname, but with a guarantee that it's not gonna be "Unknown".

Link to comment

I thaught this was supposed to send the maplist via TCP instead of dealing with the broken UDP system that the server comes with... which is what causes the "unknown" maps in the first place....

Well, if that dosent work then i will have to wait for Toady to get back to me about the FTP maplist retrival idea he had.

Link to comment

No, the workaround only sends the name of the new map on every mapchange, through TCP.

I highly doubt that the FTP maplist retrieval will be a solution for this. Sure, you will have a nice and complete list of all the maps on the server, but you still won't have any map id's. And it's exactly these id's that you need, for example, to change the map. The mta.startrace command only takes map id's, there's no way to send a command to the server like "start race named Smash", you can only send commands like "start race with id 45". This means that the only way to start an unknown map, is to enter something like "startrace Smash" manually into the server console itself.

Believe me, I have thought a lot about this and I'm afraid that there isn't really any other way to work around it than the method my scripts use. That, or waiting patiently for MTA:DM, of course :P

Link to comment
Toady said it could be done.
oh pal, this has been discussed many times and there's nothing you can do. The only thing i can help you with is a script that helps to retrieve maps, but still it doesn't guarantee that you will get them all.

Doesn't really look like it...

Link to comment
I have lots of ways to get full maps list on connect without a loss, here's one: having an ftp access to the maps folder i can connect mirc to it and just get all the maps that are there with not loss, but not actually having my own race server never bothered to do something like that. Racelist updater is a script that just tries to do it via mta:ma itself. (How it works: Since admin connection recieves maps list only on connect and you cant request it, racelist updater just opens new admin sockets to the server recieving maps list, it wont get all of them at once as like as you dont get em when you just connect mtama, not a perfect way, but at least it worked for Scooby who i wrote the script for but afaik he did not have that many maps)

P.S: you can pm me your server details and ill test it out.

in this post.

Link to comment

So far so good...... works fine if you rin a Windows Based server... as the windows based server gives out the map id number in Alphabeticall order

BUT because the Linux based servers hand out the Mpa ID number in "Date Modified" order instead of AlphaBetical., it dosent work too well on our server.... but theres an update being made.

I will post back when it works 100%

Link to comment

sorry, i meant race 1.2. The problem is that in order to release the 1.2 patch the whole race mod would need to be made compatible with the current core dll's, which would take quite a lot of time as they have been radically changed since dm was started. I'm sorry about this bug, but there is nothing i can really do to help you out with it atm :(

Link to comment

Well at the moment im Beta Testing a Fix for the issue and i must say.. 99.99% Success rate so far.

its a complete Prick to set up for Linux Servers.... but it works.

---------------------------------------------------------

But in the mean time...

How is this for a Retarded sounding idea....

An application that rund on Both the Server and the Scripts maching, That how it works is it captures anything sent on the Admin Port of MTA, and Resends it across TCP to the scripts, Which then converts it back.

Link to comment
How is this for a Retarded sounding idea....

An application that rund on Both the Server and the Scripts maching, That how it works is it captures anything sent on the Admin Port of MTA, and Resends it across TCP to the scripts, Which then converts it back.

That is called "UDP Over TCP Tunnel", it could help if you are losing UDP packets.

Link to comment

It would work fine for this case, since there's not much data being transferred and no packet is supposed to be dropped anyway, but it could cause trouble on situations where the UDP protocol should really be used, like on connections that can overload the bandwidth and data integrity is not important, so packets can be dropped to avoid lagging.

Link to comment
So.... basically... only Tunneling the Admin port?

Yes, packets could still be dropped before entering the tunnel or after getting out of it, but there's more chances for it to happen with a direct UDP connection over the internet.

Link to comment
  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...