Sound working on Win10 Mudlet from latest source

[Vadi]

Thanks for doing this work!

What is the status of the compiled from scratch on Windows Mudlet now - are there issues?

[Nyyrazzilyss]

It builds/runs....

Actually, I have a huge custom script package I use on the mud I play that's typically logged in/bot/farming/etc 24/7, with activity at keys for an hour or so a day. I'll switch to using -dev instead of delta, and will be able to report back on stability under windows/any missing files/etc fairly quickly.

Just as a related aside - Sound was one of the trinity of bugs I had a huge desire to see fixed in Mudlet on windows. PR301 is the second (which i'm going to to start using also with a 40k mapfile!), with zipfile handling being the third.

[SlySven]

That IS good news - especially if the sound is working. From what I remember on the Windows platform by default it tries to build both debug and release versions and the debug version could result in an extra CLI window that is used to display the debug output that other platforms would stuff out on stderr - or perhaps that only happens if the CONFIG QT/qmake variable includes "console" let me check - ah, ha - yes - if you're using Qt Creator read through the documentation page "qmake tutorial" which explains it better than I can whilst it is actually talking about nests conditions in the qmake project file (./src/src.pro):

Checking for More than One Condition

Suppose you use Windows and you want to be able to see statement output with qDebug() when you run your application on the command line. Unless you build your application with the appropriate console setting, you won't see the output. We can easily put console on the CONFIG line so that on Windows the makefile will have this setting. However, let's say that we only want to add the CONFIG line if we are running on Windows and when debug is already on the CONFIG line. This requires using two nested scopes; just create one scope, then create the other inside it. Put the settings to be processed inside the last scope, like this:

Code: Select all

win32 {
     debug {
         CONFIG += console
     }
 }

There is a slight complication in that I suspect that the preferred project build system on 'Doze is CMake not QMake - so YMMV!

[Nyyrazzilyss]

I uploaded a zip file containing the Qt 5.3.2 DLLs to my github.

https://github.com/Nyyrazzilyss/NyyLIB/ ... dpatch.zip

[Vadi]

So just new dll files from Qt, without any recompilation of Mudlet, work ok?

[Nyyrazzilyss]

Yes - No recompile needed. It's quite possible that I included more DLLs then were needed, it's also quite possible though that mixed versioning would make having only used a couple of them crash mudlet. I didn't really test. I do know that it works with 5.3.2, crashes with 5.6 (I didn't try any versions between that)

At this time i've got 3.0-delta running (Windows 10) with all the DLL files replaced, no other changes. Sound is working just fine, and it hasn't crashed on me yet.

[Vadi]

K, sounds like to complete the confirmation, we need to compile Mudlet on 5.3.2 version of Qt, use those DLLs, and it it all works, issue solved.

[SlySven]

From what I recall of Qt libraries - there is a certain leeway allowed between the libraries used when compiling and when executing a Qt application - so all you are doing is changing the run-time libraries.

Non-windows users of Mudlet can run "mudlet --version" from the command line and instead of starting up normally it will report the details of the Mudlet version AND the version of the Qt Libraries it was compiled against and those that it is/will be using when it runs normally. {The application version reporting is one of the GNU mandated command line switches that I put in code for - the other being "--help" BTW!}

I boobed when I did that code in main.cpp in that I thought that Windows would use '/' as the command line argument introducer - in hindsight I now think it should be the same '-' that the other platforms use - but since I have yet to get a 'Doze build platform up and running (I very rarely run 'Doze'!) I never got around to fixing Bug 1375449 - someone with a working build system could probably simplify the code (no need for that #define OPT_PREFIX stuff) and fix that bug...!

[Nyyrazzilyss]

What is the status of the compiled from scratch on Windows Mudlet now - are there issues?

I might have spoke to soon on that one - It does build/run, however, I took it a bit further and am having similar difficulties to dicene from earlier in this thread - Lua.

I've followed the lua installation instructions, and it appeared to work properly/files are present, however, it would appear that the compiled mudlet can't load any of the lua. Just took a quick look, and LuaGlobal.lua looks to be where those modules are loaded: I should be able to take a closer look either this afternoon or tomorrow.

[ ERROR ] - Cannot find Lua module rex_pcre.
Some functions may not be available.
Lua error:error loading module 'rex_pcre' from file '.\rex_pcre.dll':
The specified module could not be found.
[ ERROR ] - Cannot find Lua module zip.
Lua error:[string "require "zip""]:1: module 'zip' not found:
no field package.preload['zip']
no file '.\zip.lua'
no file 'C:\release\lua\zip.lua'
no file 'C:\release\lua\zip\init.lua'
no file 'C:\release\zip.lua'
no file 'C:\release\zip\init.lua'
no file '.\zip.dll'
no file 'C:\release\zip.dll'
no file 'C:\release\loadall.dll'
[ ERROR ] - Cannot find Lua module lfs (Lua File System).
Probably will not be able to access Mudlet Lua code.
Lua error:error loading module 'lfs' from file '.\lfs.dll':
The specified module could not be found.
[ ERROR ] - Cannot find Lua module luasql.sqlite3.
Database support will not be available.
Lua error:error loading module 'luasql.sqlite3' from file '.\luasql\sqlite3.dll':
The specified module could not be found.
[ ERROR ] - LuaGlobal.lua compile error - please report!
Error from Lua: cannot open /LuaGlobal.lua: No such file or directory

Directory of C:\release

04/15/2016 12:12 AM <DIR> .
04/15/2016 12:12 AM <DIR> ..
01/15/2014 04:36 AM 23,544,786 icudt52.dll
01/15/2014 04:36 AM 3,347,428 icuin52.dll
01/15/2014 04:36 AM 1,992,280 icuuc52.dll
04/14/2016 10:08 PM 55,537 lfs.dll
04/14/2016 11:47 PM 96,359 libyajl.dll
04/15/2016 12:12 AM <DIR> luasql
04/15/2016 12:10 AM <DIR> mudlet-lua
04/15/2016 12:03 AM 6,001,678 mudlet.exe
04/14/2016 12:23 AM 4,786,176 Qt5Core.dll
09/11/2014 09:40 AM 4,597,248 Qt5Gui.dll
09/11/2014 09:37 AM 1,412,608 Qt5Network.dll
09/11/2014 09:55 AM 323,584 Qt5OpenGL.dll
09/11/2014 09:49 AM 5,883,904 Qt5Widgets.dll
04/14/2016 10:47 PM 73,709 rex_pcre.dll

Edit (1)

I took a look at what was happening, and first thing that popped up was a mixture of various versions of lua/header files. I've (I think!) got rid of everything that wasn't 5.1.5, and i'll recompile with that version. I also downgraded luarocks to 2.1.12 (which would likely be the version that was in use when the instructions were written, he didn't say)

[Sake]

I uploaded a zip file containing the Qt 5.3.2 DLLs to my github.

https://github.com/Nyyrazzilyss/NyyLIB/ ... dpatch.zip

Using these DLLs on the latest Mudlet 3.0.0 Delta on Windows 7 does not work. The program just crashes as soon as I try to start it up. I just put the DLLs in the instructed place, overwriting the existing ones.