Latest Bug Crop

[SneaksieDave]

Okay will try this shortly.

[SneaksieDave]

Nah, it doesn't run. After adding file after file it complained about, I end up with that below.

 

What about a full build zip? This was missing a lot, so I assume it's not a full one.

[greebo]

Problem is, I don't really know myself which DLL files are needed to run DarkRadiant as stand-alone. My dev environment is running a full GTK+ install, that's why I don't need any of these DLLs in my installation folder.

 

@Orbweaver: you know probably best what's needed for a installation package? How much work is it to assemble a "private" release for SneaksieDave?

[OrbWeaver]

As far as I know, the only required DLLs are those that are packaged in the 0.8.1. release distribution, along with the lib and etc directories which contain GTK configuration stuff.

[greebo]

Ok, I'll upload a package for SneaksieDave then.

 

edit: New package is on FTP in 5 minutes, this should include all the etc/, lib/ and DLL stuff.

[SneaksieDave]

Sorry

 

[shaders] Loaded texture: textures/alphalabs/a_lfwall12a2
setShader
Module Initialising: 'imageloader' 'tga'
Module Ready: 'imageloader' 'tga'
Module Initialising: 'imageloader' 'jpg'
Module Ready: 'imageloader' 'jpg'
Module Initialising: 'imageloader' 'dds'
Module Ready: 'imageloader' 'dds'
brushDragNew
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = none
Module Initialising: 'imageloader' 'tga'
Module Ready: 'imageloader' 'tga'
Module Initialising: 'imageloader' 'jpg'
Module Ready: 'imageloader' 'jpg'
Module Initialising: 'imageloader' 'dds'
Module Ready: 'imageloader' 'dds'
[shaders] Loaded texture: textures/alphalabs/a_enwall13c
setShader
Module Initialising: 'imageloader' 'tga'
Module Ready: 'imageloader' 'tga'
Module Initialising: 'imageloader' 'jpg'
Module Ready: 'imageloader' 'jpg'
Module Initialising: 'imageloader' 'dds'
Module Ready: 'imageloader' 'dds'
setShader
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = none
Module Initialising: 'imageloader' 'tga'
Module Ready: 'imageloader' 'tga'
Module Initialising: 'imageloader' 'jpg'
Module Ready: 'imageloader' 'jpg'
Module Initialising: 'imageloader' 'dds'
Module Ready: 'imageloader' 'dds'
[shaders] Loaded texture: textures/alphalabs/a_lfwall13b
setShader
Module Initialising: 'imageloader' 'tga'
Module Ready: 'imageloader' 'tga'
Module Initialising: 'imageloader' 'jpg'
Module Ready: 'imageloader' 'jpg'
Module Initialising: 'imageloader' 'dds'
Module Ready: 'imageloader' 'dds'

For a while, it wasn't happening. I was about to report back saying that, and that I'd try it for a bit more through the day, but then it happened.

[greebo]

I'm a bit out of ideas here. I won't go as far as saying that this is related to your drivers, but this leaves me puzzled. Orbweaver, any ideas what we may try next? How easy it's to re-route the globalOutputStream() to std::cout? The radiant.log file tends to get truncated when DarkRadiant crashes, the last few lines are usually missing. With std::cout everything is printed out fine.

[OrbWeaver]

Orbweaver, any ideas what we may try next? How easy it's to re-route the globalOutputStream() to std::cout? The radiant.log file tends to get truncated when DarkRadiant crashes, the last few lines are usually missing. With std::cout everything is printed out fine.

 

Unfortunately, globalOutputStream is -- you guessed it -- a stupid re-implemention of std::ostream and not directly compatible. I suspect it would be non-trivial to rewrite it to use an std::ostream, although it would certainly be valuable (not just because of the log file issue you mention, but also because you could pass std::strings to it without getting an error, and probably remove a load of legacy crap in the process).

 

I'll see if I can recreate this crash, but if I can't (as I suspect will be the case), improved log facilities are probably the only option.

[SneaksieDave]

Since we have a large pool of potential other testers, it'd also be nice if they tried to repro it too. It can't just be us three (or four) on the whole development of this project.

[sparhawk]

What exactly needs to be tested? I don't follow these threads so closely as I don't do anything with DR. I want to in time, but's quite emberrasing what I can produce when I see all that great maps here.

[SneaksieDave]

Well, I don't mean anyone (or anything) in particular of course, but we have a bunch of betamappers who aren't commenting much on it (even though that's part of the task). Experienced mappers are most likely to find functional problems and to have opinions on design. All they've really gotta do is use it, and when they run into a problem, report it (bug, design opinion, or otherwise). We've crossed the 200 mark for DR entries, so no one can claim that there's nothing to be found, and there's plenty to do ahead.

 

I do my best to represent the voice of mapping, but first I don't know everything (for instance, thank goodness Schatt and Pink know S/R, because I don't well at all - though I will be learning), and second, more voices lend more credence. As an example of that (I'm trying to think of a diplomatic way to say this without ticking off the dev team) - it's easy for one tester to sell a simple or uber-cool idea to development. When the implementation starts getting more tricky and troublesome and the importance comes into question (generally Dev VS QA), it really helps to have a chorus backing it up.

[sparhawk]

If you report a problem then there is 'ticking off the dev team'. At least not where I'm concerned. Depends on how you do it though. If you phrase a bug report as a personal insult, it's different, but I don't see this happening. I know that there are programmers who take each bug report as a personal attack though, but as long as the bug is valid and phrased as a bug report, that's the programmers problem if he can't deal with it.