mta.mrc BROADCAST LOSTMAP ?

[23:26:11] MAPS: Started map 'Survival Of The Fittest'

[23:26:11] ADMINPM: coz to : BROADCAST coz LOSTMAP 3002

[23:27:21] CHAT: : !map

[23:27:21] ADMINCHAT: coz: Map name: Unknown

is there any way to fix this or work around it

it sure would be nice to have commands that work on more (than depends on amount%) of the maps

if there is no way to prevent it.maybe it shouldnt broadcast the map but store it in some nice array or something (and try again later ?)

well as ive said before the netcode has changed to TCP in the next release.. but it depends when that comes out.. we're working on dm atm so there is no guarentee of when the next race patch will come out.. but when it does this will be fixed

well as ive said before the netcode has changed to TCP in the next release.. but it depends when that comes out.. we're working on dm atm so there is no guarentee of when the next race patch will come out.. but when it does this will be fixed

k .. well ..yes true

thankes for that

but till the next version comes i just wanna know can it be fixed in some sort of way with the current version.. yes or no

my guess is yes .. at least .. i hope

and im not saying the mta team should do it either - im happy with you all trying your best to get dm out asap

if the broadcast can be send with the mapID it must be able to get it stored somewhere - hopefully retreived via some sort of index

i dont know how the mapnames and or ID's are send in the first place from and to script - and at what intervals

so far i did understand that all mapnames are send in one go in udp and some names get lost

but since all mapnames which get lost send out a mapID .. there has got to be something possible

or can anyone explain why its not possible

nope

The problem with it is that the maps are sent very quickly in giant packets through a UDP connection. Now you have to understand that UDP is unreliable. That is, it simply sends the packets and assumes they arrive on the other end. There is such a thing as packet loss across large networks (like the internet for example) and this is what causes the map list to be incomplete on connect to the server.

TCP fixes this as its reliable, but as i said, i dont know when the next version is out

The problem with it is that the maps are sent very quickly in giant packets through a UDP connection. Now you have to understand that UDP is unreliable. That is, it simply sends the packets and assumes they arrive on the other end. There is such a thing as packet loss across large networks (like the internet for example) and this is what causes the map list to be incomplete on connect to the server.

TCP fixes this as its reliable, but as i said, i dont know when the next version is out

i understood that part

but how do we make a index mapname-mapID with the use of mirc when the data IS properly received .. because the script works on a map or gives a mapID at the start of a map (i havent seen script loosing a mapname without being able to broadcast the map ID to someone) ... its not the end of the world that the sending part cant be fixed in this mta version which is causing it.. all im asking is .. is it possible to have a workaround now on the receiving side ..

is it freaking possible to make a mirc script that indexes the mapnames-mapIDs and responds to a broadcast lostmap .. with a >> hereIfoundit (aka replace the $mta.map() with correct data

or something .. anything

is it freaking possible to make a mirc script that indexes the mapnames-mapIDs and responds to a broadcast lostmap .. with a >> hereIfoundit (aka replace the $mta.map() with correct data

yes ... no ??

...

..

.

ps

do not get mad at me lol.

im not mad at any one .. just a bit frustrated

There is such a thing as packet loss across large networks (like the internet for example)

from localhost to localhost .. very large

im not blaming this on anyone. im not trying to be a utter basterd

i know the problem is UDP and the best way to fix it is have TCP in the next version of mta ..

but my bet is there is a better solution untill we get tcp

i just dont know everything about the mta server internally .. the way script receives data .. and i cant script besides a mta.text

i didnt code MTA:mA for MTA:SA R1, so i dont know what it does with the race list once it gets it. I coded the server part which sends the race list, and ive explained how that works..

i didnt code MTA:mA for MTA:SA R1, so i dont know what it does with the race list once it gets it. I coded the server part which sends the race list, and ive explained how that works..

ok .. thanks for that

again, dont feel as if im taking this out on someone..

ps .. does the server only sends the maps when asked for .. or does it broadcast it once in a while. or that plus when 'changes detected' .. ?

- also in what way the server assigns a mapID to a map ?

maybe its possible to trick server by cleaning the folder and filling it one with mapfiles one by one - and creating a index that way ??

so .. uhm .. i guess we need Aeron here for the scripting

The map id's are determined by how they are added to the server. The server sends the race list to admin when the admin connects and when the race list changes.

Index-Map name is impossible, it changes 'everytime'.

Now MTA:mA broadcasts to other MTA:mA's if they do have that map name, if so it replies. If not they spam again the next time they need the name. This can be turned of under options. It's recommended when you have only 1 MTA:mA

Index-Map name is impossible, it changes 'everytime'.

Now MTA:mA broadcasts to other MTA:mA's if they do have that map name, if so it replies. If not they spam again the next time they need the name. This can be turned of under options. It's recommended when you have only 1 MTA:mA

k .. my guess is mirc cant parse the data quickly enough when it is received

its not possible to store the data so if a map gets lost it can be recovered ?

maybe use a other program specific for the mapnames ?

what do you mean with mapIDs changing everytime ?

acording to Oli the IDs are depended on how they are added to server

when would it change ?

just to be clear .. so you all are basically saying its broken atm, it should be fixed in next version. and you dont know how to solve it / its not solvable in this version ?

Index-Map name is impossible, it changes 'everytime'.

Now MTA:mA broadcasts to other MTA:mA's if they do have that map name, if so it replies. If not they spam again the next time they need the name. This can be turned of under options. It's recommended when you have only 1 MTA:mA

k .. my guess is mirc cant parse the data quickly enough when it is received

its not possible to store the data so if a map gets lost it can be recovered ?

maybe use a other program specific for the mapnames ?

what do you mean with mapIDs changing everytime ?

acording to Oli the IDs are depended on how they are added to server

when would it change ?

just to be clear .. so you all are basically saying its broken atm, it should be fixed in next version. and you dont know how to solve it / its not solvable in this version ?

You could rejoin several times in a period to get all maps names. But feel free to fix it

so no hints at all ?

btw did you try to fix it once ?

ps ...

[13:24:56] MAPS: Started map 'Carbon3'

[13:24:56] ADMINPM: coz to SmalltownCynic: BROADCAST coz LOSTMAP 526

[13:24:56] ADMINPM: fdm to SmalltownCynic: coz fdm FOUNDMAP 526 Carbon3

[13:26:38] ADMINCHAT: Console: type !map please

[13:26:43] CHAT: SmalltownCynic: !map

[13:26:43] ADMINCHAT: coz: Map name: Unknown .. Total maps : (18-juli) 3516

maybe the foundmap can be a bit beter too ...

Mayabe becuase it is very hard to fix it in this version? The workaround would be very hard. Just wait for the next release.

well with my current script knowledge .. thats probably though unfortunately the best workaround ..

so...

will mta race be updated to tcp after mta dm is launched ? (because i doubt dm will replace race for racing)

will that solve the problem ? .. my guess its partly blameable on mirc .. it cant digest the data that fast

and .. im sorry for being impatient.. its just a bit frustrating having such a great mod/game/script (again: my compliments , keep up the good job) and not being able to do everything on all maps