I'll look into the crash, Gregori. I've been using this code for a couple months and it hasn't crashed once on me. I know I've used survey, but maybe there's some odd circumstance. I see your ATCP packet got in there, which may have caused it to overflow some buffer in the parse_survey function.

Forren, something must not be correct because my 'lmap status' shows 'Room title color: brown' and the word brown actually appears in brown. Try moving your current config.mapper.txt out of the way and let the mapper module create a new one in its place, see if that works any differently for you.

Quick follow up, that crash happened with the wrapwidth 0 binaries download. I grabbed the source later on and did the makefile on it and it mapped perfectly fine.

I double checked the executable by running the downloadable binaries on my machine and I have no troubles with it crashing. Maybe there was some version conflict with your system DLLs or something, if re-compiling fixed it for you. I honestly don't know, but if it happens again (for anyone), be sure to give me details on what you did up to the crash, including any data files you think may be necessary to re-create it, and I'll try to fix it. Otherwise, I leave it up to the users to debug, compile, or do whatever is needed to get it working for them...

mhmm my mudbot crashed when i try to edit some project...



here the screenshot:


EDIT: by the way, I am running on LMTS2 binary with wrapwidth 0. :3

Yes, you cannot edit projects, help files, anything involving the editor with this version. It crashes with a segmentation fault error.

Bleh. Well, something else to work on, I guess. Even as a guild leader, I hated news posts, journals, projects, or anything involving that editor.

If I figure anything out, I'll let you know, but don't hold your breath. Conversely, if anyone has any suggestions for specific changes to the code, let me know. It is nice that MudBot tells you what functions crashed and in what way.

Does it need any more files? I was compiling it on Debian Linux.

I tried compiling it and found that imperian.so required imperian.h
OK, so changed that line in the Makefile

SO_FILES = i_mapper.so i_script.so i_lua.so

Then sense_message was not defined, uncommented the line where it is defined as an int.

Then it all got very cranky with the i_lua module.

OK, so you need to download and install liblua5.1-0-dev and its all good. Well it compiles anyhow.

Like I said, I do my development and testing on Windows only. Compiling for other platforms is unsupported by me, but it shouldn't be difficult to figure out (as you found).

The "imperian" module can be removed from the makefile, of course, because we don't need Imperian curing or offense scripts to play Lusternia. The sense_message variable should be uncommented in the currently available LMTS, unless I forgot to upload that version. You may need certain libraries installed to compile things. Obviously, you've gotten all these already...

Thanks, I tried it out last night briefly and it works fine. I'm too low-level to be able to edit any help files so I don't see that other bug.

If you do get people asking about compiling it on Linux or problems that look like Linux-specific then let me know, I can probably help them.

I just had it crash on me with a segmentation error - and all I was doing was forging.

One thing that the extra linewidth mucks up is the block messages.

I was trying to work out why the heck my map was going crazy near the rivers. The problem is you go, say south get the "there is water ahead.." message and of course you don't move. But the mapper does. The reason is that the full line now appears and the mapper tries to map the 80 character internal string with the line from the mud and they don't match.

Easy fix was to add the whole line to block_messages but probably it should trim the line its checking.

Post the crash dump output?




Thanks for the report.

My crash.log was blank afterwards. Which is what really had me stumped.

Latest LMTS version seems to have issues with sprinting, or else sprinting has issues with sprinting.





This happened a number of times on a speedwalk from my manse to presidio and back. While the locations are not important, as it happened on other paths, I just picked those two as a test due to a number of straight paths to sprint on.

Using Mushclient, though, if that does matter.

Yeah. The auto-dash/sprint/gallop thing is still not working properly in this version. In the other games, they can track which rooms they move through as they see all the titles. We don't get that, so it makes it harder to track where you ended up. I just disable the option in my map config file and walk everywhere without auto-sprinting. If I'm ever able to get this feature working in Lusternia, I'll try to let you know.

This could actually happen, I believe, before these modifications were made. I'm going to guess that you probably tried to use II or IH with a large number of long named and identical items and it crashed, although I could be wrong.

Nope, it happened mid-forge. So all I was doing was forging (it was on the refining process) repeatedly. I figured out why there was no log though, I didn't think to check immediately, and LMTS crashes out every time you `disconnect.

Anyone having problems with this particular issue who use the default room color should do "lmap color brown" and it will start working. Pro-tip!

This only happens at work, but I just keep randomly losing connection. It happens quite a bit when I first connect, then once it stabilizes it seems to stick for a good few hours.

process_server: Connection reset by peer.
Restarting.
Sock.sinaddr: 127.0.0.1 (localhost)
Connecting to: lusternia.com 23.
Connected.

Is the report from the console.

I've been randomly losing all my connectivity from both work and home over the last couple weeks. I just figured the Internet was beginning to collapse... At any rate, there's nothing I can do to help you because it's not an issue with the application.