Hi,
is it possible to get latest mudlet code somewhere (e.g. code with all mapper changes).
Repository seems to only contain Mudlet 1.1.1 code.
(git://mudlet.git.sourceforge.net/gitroot/mudlet/mudlet)
Thanks,
Lex
PS: I would like to test all luaLglobal changes for next release
[available] Latest code
Re: Latest code
Heiko pushes code to the git repo infrequently. Mostly the code there will get updated several times shortly prior to a release and go through several pre release versions as we hammer at it to find and remove bugs. Right now the mapper stuff in particular is being distributed only in binary format, so far as I am aware. Heiko is very picky about what state the code is in before he pushes it to the public repository, so it may be awhile yet before we see this latest (and, might I say, greatest) feature release code pushed there.
Of course, there's a first time for everything, and I'm sure none of us who like to compile for ourselves would be saddened if he proved me wrong.
Of course, there's a first time for everything, and I'm sure none of us who like to compile for ourselves would be saddened if he proved me wrong.
Re: Latest code
Honestly, I wish he'd just keep git updated to current state and let us use it as "alpha" or "beta" software.
Re: Latest code
I haven't pushed the mapper code so far because it's in such an early stage right now. I'll push it as soon as it's got a more substantiated code base. It's been the same with all major modules in Mudlet.
As far as the new much improved LuaGlobal.lua loading is concerned we certainly do need new loading code. Right now I'm loading LuaGlobal.lua and db.lua as 2 seperate files and run them before the user profile is being loaded. These files are being extracted from the binary and copied to the mudlet home directory on each startup of Mudlet from where they are being loaded by Lua. However, this has proven to cause several problems - especially on Vista and Windows 7. The problem is that user rights on these 2 OS are preventing the updates of these 2 files - strangely enough, not always, but sometimes. I've tried to explicitely set appropriate user rights, but this doesn't work satisfactorily for whatever strange reasons. This is why we have to change the entire loading process and get away from actually copying the files. What I have in mind is including the entire LuaGlobal directory into Mudlet's resource file and compile it into the binary and then load and run each file as a string. This will do away with above problems, but the actual files will not be accessible from Lua which will impose certain restrictions.
The other big issue is that the next update needs to feature a user defined mudlet home dir path in order to support flash drives.
@ lex: please send me an email so we can discuss these issues in more detail and to send you the source code by email if you want to take on the new loading code etc.
As far as the new much improved LuaGlobal.lua loading is concerned we certainly do need new loading code. Right now I'm loading LuaGlobal.lua and db.lua as 2 seperate files and run them before the user profile is being loaded. These files are being extracted from the binary and copied to the mudlet home directory on each startup of Mudlet from where they are being loaded by Lua. However, this has proven to cause several problems - especially on Vista and Windows 7. The problem is that user rights on these 2 OS are preventing the updates of these 2 files - strangely enough, not always, but sometimes. I've tried to explicitely set appropriate user rights, but this doesn't work satisfactorily for whatever strange reasons. This is why we have to change the entire loading process and get away from actually copying the files. What I have in mind is including the entire LuaGlobal directory into Mudlet's resource file and compile it into the binary and then load and run each file as a string. This will do away with above problems, but the actual files will not be accessible from Lua which will impose certain restrictions.
The other big issue is that the next update needs to feature a user defined mudlet home dir path in order to support flash drives.
@ lex: please send me an email so we can discuss these issues in more detail and to send you the source code by email if you want to take on the new loading code etc.
Re: Latest code
@Heiko
sorry for delay, I did send you email long time ago, but it obviously get lost somewhere. Content is probably not relevant anymore, cause you already did amend Lua code loader.
I'll contact you differently.
sorry for delay, I did send you email long time ago, but it obviously get lost somewhere. Content is probably not relevant anymore, cause you already did amend Lua code loader.
I'll contact you differently.