dummy profile

[silvercoon]

Running Win8.1 (w/the update). AFAIK I haven't loaded any scripts - but there is a folder named Scripts that appears when I click the Scripts button. But it doesn't appear in the Mudlet directory, so it must be something that's loaded into memory when the program runs. (I found out I installed 'Scripts' through the 'Package Manager', but I'm hesitant about editing/creating until I fix this.)
I tried some maps I downloaded from Akaya's link, but I don't know where to put them. I tried putting them in its own folder in the Mudlet directory, and also dropping them directly in main directory, but I've been unable to detect them through the menu.

[demonnic]

in %USERPROFILE%\.config\mudlet\profiles there will be a folder which matches the name of the profile you're using when you load up mudlet. Generally, files you need will go in there. If the map file you have is a .dat, it likely goes in the map subdirectory there. Otherwise, it will depend on the script. I haven't gone and looked at what Akaya did with the tiling maps in the other thread though. He may be better situated to help with that stuff.

Have you tried a clean profile to see if the map displays there properly? It seems unlikely, the "Scripts" directory is likely the base scripting thing and nothing is actually running there. But it's worth a try.

Have you tried un-maximizing Mudlet to see if you get the ability to control the docking window then?

[silvercoon]

I found ./profiles and after some testing of the two profiles I've created, I thought it'd be more productive to delete the one that has the glitch - since the other one doesn't have it. Now I'm going to pick on Akaya so I can dissect his work.

[demonnic]

Glad it's working for you then

[silvercoon]

Now the next step:
Having Mudlet recognize an external program, such as DOSBox (or even the DOS game file). I've tried putting the path to the executable in the 'Website' box, but this is another aspect I don't know whether or not it's working.
Also, determining how Mudlet would get the map data: keypresses, or by monitoring an external file, or getting data from system memory.
There may be other concerns that will present themselves, but these two are foremost.

[Akaya]

If you're still looking to utilize the script I posted, you can install it with the Package Manager on the toolbar.

[silvercoon]

The mapper tutorial appears to have several errors in it. Also Lua error messages are not consistent. Running
the code is fine until setAreaName.

For example, I typed the code as follows:

-- setAreaName(areaID, newName)
setAreaName(1, City)

Which returned this result:

Lua syntax error:setAreaName: wrong argument type

The Lua Demo at lua.org/cgi.bin.demo returns the following for the same code:

input:2: attempt to call a nil value (global 'setAreaName')

I typed the code exactly as laid out in the tutorial - character type (caps or not), position, and spacing... and
just to be sure, no whitespace at the end. The code is presented as correct in the tutorial - so why am I getting
script errors?

[SlySven]

Um, is the second argument City a variable name that has been defined or a string which should be entered in (at least) double quotes as "City"? It looks as though it is a variable as shown and if that has not been defined then it will be the nil value that the Lua Demo explicitly reports and Mudlet moans about as the second argument is a nil when it is expecting a string!

Yes the Lua error messages are inconsistent - but then functions that produce them have developed over the years and the guiding rule is backward compatibility so where an argument type is not optimum for the job (or reflects and older way of doing things) we can't change that. Usually what happens then is that extra arguments get grafted on to the end; or alternative types (out of the set of number, boolean, string, table or, theoretically nil) also become acceptable for; the argument list - to do things that weren't thought of when a function was first introduced.

Agreed there ARE current error messages that refer to the wrong function name (a sloppy coder copied an existing function written in C++, modified it to do a new thing and didn't update the name in the error messages)...!

On the bright side we are slowly working our way through the monstrous TLuaInterpreter.cpp file that is the home for most of the Mudlet specific functions made available and fixing things (and standardising the error message format) but ultimately if you need to work out how to use a function and it isn't entirely clear from the documentation what arguments it will take (or needs to have) to be happy - that is the place to look:
The function

Code: Select all

<functionName>(arg1, arg2, ....)

you type in your Lua scripts should (there could be one or two odd exceptions to this rule) appear there as a C++ method:

Code: Select all

(int)TLuaInterpreter::<functionName>( lua_State * L )
{
... lines of code ...
return <number>;
}

At all the points that execution can leave those types of code the number returned is the number of values the are returned to the Lua system, the standard we are gradually adopting is that where the Lua function is invoked with the wrong type of argument e.g. a string when a number is required or a required argument is missing (and Lua implicitly supplies a nil as a place-holder), a Lua error will be generated; this will have an error messages that gets shown in the debug console, at least,saying which was the first argument that was a problem as the single string return value. In the case where a detectable bad value or a value that does not produce any results for that particular value, we are going over to returning, besides a nil value, a second string which is an informational string about what went wrong, not many functions currently do this but it is intended to increase this as time goes on with the newer/developement version of Mudlet.

Use the source, Luke

[Vadi]

The mapper tutorial appears to have several errors in it. Also Lua error messages are not consistent. Running
the code is fine until setAreaName.

For example, I typed the code as follows:

-- setAreaName(areaID, newName)
setAreaName(1, City)

Which returned this result:

Lua syntax error:setAreaName: wrong argument type

The Lua Demo at lua.org/cgi.bin.demo returns the following for the same code:

input:2: attempt to call a nil value (global 'setAreaName')

I typed the code exactly as laid out in the tutorial - character type (caps or not), position, and spacing... and
just to be sure, no whitespace at the end. The code is presented as correct in the tutorial - so why am I getting
script errors?

Where is this?