Jump to content

mta.say & mta.msg overlap bug solution!

Oli

By Oli
in Add-ons

Recommended Posts

Oli Jacker

Oli

Posted
Posted

..:: Known MTA bugs ::..

Q. When I send text to the server, I get some part of the msg what i send before.

A. This is a known bug. It's not that MTA:mA is bugged but the server, the server can't handle so much text packets with no time space between it.

Ok, after a cunning idea i had last night i have solved this bug. Here is an example of what the bug is incase u didnt know or have forgotten:

[FMJ]Oli: !test

[FMJ]Oli thats my name, that name again is [FMJ]Oli

oh yeah!!!!!!!!!!!ame, that name again is [FMJ]Oli

Now, as aeron clearly states, he thinks this is an MTA Server bug. For a while i have thought otherwise.. and ppl were using timers to overcome this bug. However that is a very bad way of solving a simple thing.. and causes some new bugs of its own.

While making the Global Stats i noticed this bug cropping up in areas nothing to do with mta.say or mta.msg.. and i came to the conclusion that it is infact an mIRC bug.

I have now found a great way of stopping this bug from happening.

If you make the mta.say and mta.msg's from your script go through signals.. mIRC doesn't get these overlaps.

Here is an example of the code i would use:

on *:SIGNAL:mta.say:{
 mta.say $1-
}
on *:SIGNAL:mta.msg:{
 mta.msg $1-
}
on *:SIGNAL:mta.command:{
 if $3 == !test {
   !.signal mta.say $1 $mta.name($1,$2) thats my name, that name again is $mta.name($1,$2)
   !.signal mta.say $1 oh yeah!!!!!!!!!!!
 }
}

This will eliminate this overlap bug and result in the right text being displayed in the MTA server:

[FMJ]Oli: !test

[FMJ]Oli thats my name, that name again is [FMJ]Oli

oh yeah!!!!!!!!!!!

One draw back from this method is that if you have:

on *:SIGNAL:mta.say:{
 mta.say $1-
}
on *:SIGNAL:mta.msg:{
 mta.msg $1-
}

in more than one script.. you will get ure scripts repeating themselves, as the mta.say/mta.msg will go through more than one signal, and hance do more than 1 mta.say/mta.msg.

The latest version of MTA:mA:GRS (v4.04 - Not yet released) has this system in it, so if you have this in any other scripts you have loaded then you will get more than 1 mta.say/mta.msg from GRS. Please watch out for this.

Aeron: any way you can incorporate this into MTA:mA in the next update?

Ill speak with u about it on msn.

I hope this solves some peoples problems with this :)

Link to comment
Harry Mack

Harry

Posted
Posted

This is quite a good workaround Oli!

The problem is if it's smart to work around the problem this way, and introducing a possible deadlock situation for the 'dumb' scripter?

I vote this problem could better be worked around/fixed in MTA:mA itself, so the scripter dont need to change their current scripts, and possible add deadlock situations in them.

We'll talk about it iwth Aeron. This solution is noble, but i think the other solution would be better (and is easier for the scripters)

Link to comment
Aeron Hoodsta

Aeron

Posted
Posted (edited)

To proof again it MTA Server's fault:

bug.GIF

Well they got 0.5.1 in the make so i hope they take a look.

In meantime i'll take a look at the solution.

EDIT:

Sorry! My fault after all (again). :P

I didn't unset the binvar for the next packet so it uses the previouse packet, edits, and sends. so you could have information left of the previous packet.

I didn't notice that cause i thouth i know it was a mta server, and didn't explore it further with packet checking.

MTA Server cuts the message after he finds a null (0x00), client and mtama read further to the end of the packet

fixed in 3.21

Edited by Guest
Link to comment
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...