Page 9 of 10
Re: cMud Map Importer
Posted: Fri Oct 06, 2017 8:36 pm
by Nyyrazzilyss
Download luabit from
http://files.luaforge.net/releases/bit/bit/luabitv0.4
Copy bit.lua to the mudlet install directory.
You can also paste bit.lua into a script in your package.
Re: cMud Map Importer
Posted: Sun Oct 08, 2017 5:12 pm
by mordisko
Nyyrazzilyss wrote: ↑Fri Oct 06, 2017 8:36 pm
Download luabit from ********
Copy bit.lua to the mudlet install directory.
You can also paste bit.lua into a script in your package.
That worked (although some methods did change their name). Thank you very much.
Re: cMud Map Importer
Posted: Mon Oct 09, 2017 2:23 pm
by SlySven
mordisko wrote: ↑Mon Oct 02, 2017 10:37 pm
Hey there.
Having trouble to run this under Mudlet 3.4.0 as it seems unable to load the bit module needed to perform bitwise operations (they are used on the color checks).
Code: Select all
00:22:33.054 LUA: ERROR running script Color rooms (Alias53) ERROR:[string "Script: 24bit to 8bit color
-------------converter"]:7: module 'bit' not found:
00:22:33.054 no field package.preload['bit']
00:22:33.054 no file '.\bit.lua'
00:22:33.054 no file 'C:\Program Files (x86)\Mudlet\lua\bit.lua'
00:22:33.054 no file 'C:\Program Files (x86)\Mudlet\lua\bit\init.lua'
00:22:33.054 no file 'C:\Program Files (x86)\Mudlet\bit.lua'
00:22:33.054 no file 'C:\Program Files (x86)\Mudlet\bit\init.lua'
00:22:33.054 no file '.\bit.dll'
00:22:33.054 no file 'C:\Program Files (x86)\Mudlet\bit.dll'
00:22:33.054 no file 'C:\Program Files (x86)\Mudlet\loadall.dll'
does anyone know if there is a fix for this?
For the record, that is the standard Lua response when you use ("require") a module that is not currently loaded - and basically it is telling you all the file names and places in the file system that it has looked for a file to provide it - apart from the line "no field package.preload['bit']" which is a reference to the internal global package table where it would hope to find it if it had already been loaded and where it looks first before trying to find the module in the filesystem(s)...
There will be some slight differences on other OS platforms (I had a go at porting Mudlet to Cygwin and had to frob those entries a fair bit to get them to work because Cygwin is like Windows in some aspects and like Unix in others!)
Re: cMud Map Importer
Posted: Thu Mar 15, 2018 3:40 pm
by Eraene
Would anyone know why this script is importing all rooms into Mudlet's default area regardless of the areas created by the script? I end up with every single imported area layered on top of each other and having to manually separate them into their respective areas, and all the labels (which are far too large) clumped up together. Can this be fixed somehow?
Re: cMud Map Importer
Posted: Thu Mar 15, 2018 3:58 pm
by Vadi
Does that happen right after an import, or after you restart Mudlet?
Re: cMud Map Importer
Posted: Thu Mar 15, 2018 5:11 pm
by Eraene
Right after an import.
Re: cMud Map Importer
Posted: Fri Mar 16, 2018 5:46 pm
by SlySven
I'm just looking at the script of the "cMud Map Importer.xml" on the first page of this topic and I notice that in
function cmi:importAll() the rooms are read before the areas - IIRC that is suspect as I think the `setRoomArea(room number, area number)` Mudlet lua command will not set the area to a non-existent one - it might once have done but some time around Mudlet 3.0.0 I think we tightened up the code so that the rooms had to be in an area and they could be claimed by only one area at a time. If the area does not exist then the room will be assigned to the default area which always exists (-1) - also, in the
function cmi:addRooms(con) function in that script is the fragment:
Code: Select all
if zone == -1 or not zone then
zone = 0
end
setRoomArea( roomID, zone )
which is just wrong, zone (the area Id) is not allowed to be zero, it must be a positive integer or -1 (in the past I'm sure I argued that zero should have been the "default" area but that idea didn't get off the ground) - so the end result would be that if the area does not exist it would cause the room to be put in the default area - which sounds like what is happening to you..
It might be worth noting that at the time the change I referred to happened I also added in map auditing code to fix up the sort of issues that previous Mudlet versions allowed to develop or caused to happen. One of those bugs meant that several areas could claim ownership of a room (they each have a list - or rather for speed now, a
QSet<int> of rooms that they contain) and that is checked together with what area the room believes it is in - so that nowadays it is impossible to lose rooms which was one of the side effects of the old code...
Anyhow, I would change the following in that script
Code: Select all
182 if zone == -1 or not zone then
183 zone = 0
184 end
to
Code: Select all
182 if not zone then
183 zone = -1
184 end
and
Code: Select all
293 cmi:addRooms(cmi.con)
294 --cmi:colorRooms(cmi.con)
295 cmi:addExits(cmi.con)
296 --set area names
297 cmi:addAreas(cmi.con)
to
Code: Select all
293 --set area names
294 cmi:addAreas(cmi.con)
285 cmi:addRooms(cmi.con)
296 cmi:addExits(cmi.con)
297 --cmi:colorRooms(cmi.con)
and see if that works any better...!
Re: cMud Map Importer
Posted: Fri Mar 16, 2018 9:25 pm
by Eraene
As best as I can tell, this is a perfect fix. Those lines being out of order seems really odd.
Thanks for having a look! Areas look like they're all in the right places now.
Re: cMud Map Importer
Posted: Mon Mar 19, 2018 11:44 am
by SlySven
In the past those lines would have worked because it would not have been an issue that the rooms were allocated to an area that was not known about at the time the room was put into the "map"...
Re: cMud Map Importer
Posted: Mon May 21, 2018 7:04 pm
by Vadi
I've updated the original script to include the fix, so you don't need to do this anymore!