At this moment it's a one-player problem. I'm using a delayed Sub (PrivDelayed) from within the OnResult-event.

Quote from YamaSuba.NL :

At this moment it's a one-player problem. I'm using a delayed Sub (PrivDelayed) from within the OnResult-event.

What is his userName, delayed command is bugged in previous version, take the last version, put your code here

I have a request that should be fairly easy to implement....

Could you please add fuinctionality to the GetListOfPlayers function to accept 1 or 2 parameters, with the second paramter being an optional array size.

When rewriting the !handicapper function I found that I had to use a globalvar to store the handicap user array, else the subfunctions would not have the same data to work from. The GetListOfPlayers function only returns an array the size of the number of players that are online, and once a GlobalVar array has been set, any further attempts to write to it cannot resize the array, hench I had to write a function to call GetListOfPlayers and iterate through it, populating the GlobalVar with NULL records until I had a 32 element array.

If I could call is like this: $HcPlayerList = GetListOfPlayers("N", 32);
then that would solve all my problems.

Thanks

the array siz

Heu sorry, but i don't understand what do you want to say.

You can resize an array adding new elements. Why you say you can't?


if i am alone this work and add "toto" as new player
Gai-Luron

Quote from Gai-Luron :

Heu sorry, but i don't understand what do you want to say.

You can resize an array adding new elements. Why you say you can't?

$MyVar = GetListOfPlayers( );
$MyVar[1] = "toto";
dumpVar( $MyVar );


if i am alone this work and add "toto" as new player
Gai-Luron

Locals are fine, but if $MyVar is a global array, then it cannot be resized. i.e. If a player leaves, then the array will have 1 less element and the script will abort:

12/27/2009 10:21:55 PM -> Syntax error in cfg file "./handicapper.lpr" at line #60
You can't change the dimension of an array...
Function 'dohandicapper' script aborted

Wich version of LFSLapper do you use? here it work fine with this test. In older version, i correct some thing in array

EDIT Ok, i understand what you said ( i exit to my bed to write this, i had a flash ), this occur when you want to assign a newly GetListOfPlayer to a previous used global var, before to assign a new value don't forget to use "unset" to free var.


Result in console

Quote :

---- Dump of MyVar ----
$MyVar[0] = "gai-luron"
$MyVar[1] = "toto"
---- End Dump of MyVar ----

---- Dump of MyVar ----
$MyVar[0] = "gai-luron"
$MyVar[1] = "toto"
$MyVar[2] = "tata"
---- End Dump of MyVar ----

---- Dump of MyVar ----
$MyVar[0] = "gai-luron"
$MyVar[1] = "toto"
$MyVar[2] = "tata"
$MyVar[3] = "titi"
---- End Dump of MyVar ----

Unset would work...thanks for that.

Quote from Gai-Luron :

What is his userName, delayed command is bugged in previous version, take the last version, put your code here

The guy in question is the notorious "Mad Dog"..
For the newest version I'll have to consult Dean, to have it installed at 500servers. I understand there's a lot of changed stuff in there, so I'll have to get some work done there.. I'll be feedbacking after all that is done..

Hello,

I have an practical idea which is pretty easy to realise.

Now we have allready 4 languages for LFSLapper and more to come, the LFSLapper.lpr file is going to be very large. I thought it might be good to remove the 'Lang ".."' sections out of LFSLapper.lpr and replace it for
Then put the 'Lang".."' section in the languages.lpr files.

It might be good to implement the 'Lang' sections of the files such as driftDef.lpr and driftmeter.lpr.
To make the language.lpr file easy to edit, I think the language entries of the files must not be main_...., but for driftDef.lpr, driftdef_.....

I'd like to hear your opinion about this.
If you like the idea Gai, but you don't have time for it, i can do it for you and send it

Greets,

Tim

hello,

Yes it's a good idea to have a language file for LFSLapper.lpr, maybe it's also a good idea that this file have the same name as original file but with an another extension. "LFSlapper.lg". In this case, it's more easy to localize lang file for a specific .lpr file.

You have to include


But for small file script, it's not an obligation

You are also rigth when you say, item lang must be prefixed with file basename.
"driftdef_" for driftDef.lpr
"winnerflags_" for winnerflags.lpr
and so on

But i'am writing doc for now and i don't have time. your help was a good thing. ( last script file are in 5.9.2.0 )

Thank's

Gai-Luron

Quote from Gai-Luron :

hello,

Yes it's a good idea to have a language file for LFSLapper.lpr, maybe it's also a good idea that this file have the same name as original file but with an another extension. "LFSlapper.lg". In this case, it's more easy to localize lang file for a specific .lpr file.

You have to include

include( "./includes/LFSLapper.lg");

But for small file script, it's not an obligation

You are also rigth when you say, item lang must be prefixed with file basename.
"driftdef_" for driftDef.lpr
"winnerflags_" for winnerflags.lpr
and so on

But i'am writing doc for now and i don't have time. your help was a good thing. ( last script file are in 5.9.2.0 )

Thank's

Gai-Luron

this is what i do at the moment but its in a .lpr file i have done this since u added catch events and i started cleaning out my main lpr i moved the lang section to its own area

Quote from Gai-Luron :

hello,

Yes it's a good idea to have a language file for LFSLapper.lpr, maybe it's also a good idea that this file have the same name as original file but with an another extension. "LFSlapper.lg". In this case, it's more easy to localize lang file for a specific .lpr file.

You have to include

include( "./includes/LFSLapper.lg");

But for small file script, it's not an obligation

You are also rigth when you say, item lang must be prefixed with file basename.
"driftdef_" for driftDef.lpr
"winnerflags_" for winnerflags.lpr
and so on

But i'am writing doc for now and i don't have time. your help was a good thing. ( last script file are in 5.9.2.0 )

Thank's

Gai-Luron

Is it OK with you if I realise this idea and post it in here? (or in another threat? you can say..!)

Do you mean you want to have a LFSLapper.lg and also a driftDef.lg, winnerflags.lg and so on.. or just one file, LFSLapper.lg with all 'Lang' sections in it?
I think the second is the best, because you can have all language codes in one file.
It is also possible to make a language file for every language; LFSLapper_en.lg(or LFSLapper.en), LFSLapper_fr.lg, LFSLapper_nl.lg and so on.. or is this too overdone? (I think it maybe is xD)

If you agree I will fix the lang bases also. (main_..., driftmeter_..., winnerflag_...) In the language section aswell in the script.

Greets,
Tim

I think one big file language (.lg),for LFSLapper.lpr, and language file included in all other script because there are smaller. It's not good to have many file, and it's not good to have big file. We can try to have a mixed, two file ( script + language ) for big script and one for smaller script.

Quote from Gai-Luron :

I think one big file language (.lg),for LFSLapper.lpr, and language file included in all other script because there are smaller. It's not good to have many file, and it's not good to have big file. We can try to have a mixed, two file ( script + language ) for big script and one for smaller script.

OK, so I'm going to make a LFSLapper.lg and a includes.lg for all other files with 'Lang' sections?
The LFSLapper.lg is coming in the bin directory and the includes.lg file is coming in the includes directory. Is this right?

If this is right, I think I will post it next weekend.

Tim

This also raises the pproblem of maintenance. If there is one large lang file with all the language definitions in it, then if someone changes a module to have a slightly different text, then its a global update rather than just their .lpr module. If a user wants to have a spearate file, then it is a very simple matter to just cut & paste the Lang sections of a number of lapper files out if they are kept at the end of the modules.

I agree with keeping things tidy, but in reality you should never need to move the Lang sections out of the main files for anything other than to segregate them, as it makes no operational difference to lapper.

Also, module makers should look at chnaging their language definitions to <module>_<name> instead of main_<name> to differentiate between the main lapper definitions and their custom ones. This would also aid in debugging so that we could track down any typographic errors faster.

i think we should only make one for the main Lapper.lpr cause that way it keeps it tidy but it does not make a diffrence to me because all my small scripts have there lang in them while the big ones hvae them seperate

Hey gai,

you know how there is a Sub for when u enter a Zone what about when u leave?

so like

RegisterZoneAction( "Name" , "Track" , X, Y, 5, Enter Sub, Exit sub (optional) );

Hi everyone!

I'm finished with the ideas for language files.
I made 2 versions.. so you can choose which one you like better..

version1: Like Gai-Luron suggested it would be good. One language file for LFSLapper.lpr and one for all files in the includes folder that uses the lang-engine. The name of the files for the languages is 'languages.lg'.

version2: This is how I like it the best. There is one file for every language. The files are stored in the folder: 'includes/languages/'. The filenames are like: en_english.lg.

WARNING! I did not test it.. because I haven't that much time this week and I prommised to release it this week.


I hope it all works and you like it.
I'd like to hear which option you like the best.

Greets,
Tim

Hello,


My choice was

one lang file for LFSLapper.lpr ( LFSLapper.lg ) and lang included in lpr file for rest of file or a lang associated for each lpr file.

Why?
Because, when change to one script file, no need to modify lang file, only add .lpr and maybe .lg associated with the .lpr
The best way is no modify any file, only add file or remove file, no edit

Gai-Luron

Quote from fire_optikz001 :

hey gai,

you know how there is a sub for when u enter a zone what about when u leave?

So like

registerzoneaction( "name" , "track" , x, y, 5, enter sub, exit sub (optional) );

Aah ok, sorry for the misunderstanding.
Do you think it is useful to use this, with your ideas in LFSLapper or is it better to leave it the way LFSLapper is now? Then users can decide and make want they want themselves..

Like to hear your opinion

Tim

is there a way to add it so that Lost conection and timed outs are not classified as dissconect like make a new ec=event for timing out/Lost connection

Quote from Fire_optikz001 :

is there a way to add it so that Lost conection and timed outs are not classified as dissconect like make a new ec=event for timing out/Lost connection

The InSim docs describe the following reasons for a session disconnect:

// Leave reasons

enum
{
LEAVR_DISCO, // 0 - disconnect
LEAVR_TIMEOUT, // 1 - timed out
LEAVR_LOSTCONN, // 2 - lost connection
LEAVR_KICKED, // 3 - kicked
LEAVR_BANNED, // 4 - banned
LEAVR_SECURITY, // 5 - OOS or cheat protection
LEAVR_NUM
};

Currently Lapper executes the OnDisConnect function but only supplies the Username as an argument. If Gai can add another argument that is the reason number of the disconnect, then you could use a CASE/SWITCH statement to do different things when a disconnect occurs.

Helo,

Yes it execute onDisconnect put provide $reason as parameter

Bye

EDIT : Heu, in new version that i'am not released yet. . You have view doc before my release 5.9.2.3
http://www.lfs-lapper.org/help/ondisconnect.htm

cool cant wait this will fix a bug i have in my cruise addon