greebo

I created a new thread as this deserves its own thread: Did you create this snapshot folder on your own or has this been automatically created by radiant? Can you give me a directory listing of this folder (Screenshot or "dir >list.txt" in the dosbox)? Could you put a map with a simplistic box room plus the texture plus the material file into a pk4 and send it to me? Then tell me what steps I will have to do to reliably produce the crash. I can look into it, but I still am a bit of green regarding the texture code, so I can't give you any promises. But if the problem is properly documented, I'm confident that there will be a remedy available in the future. :-)

Hm, the autosave is working for me, I just checked. Can you provide a sample map with exact steps to reproduce the problem? Does this also occur on newly created maps? edit: Just saw your edit. What the heck is snapshot? My file is named bonehoard.autosave.map, in the map folder.

I'm somehow feeling where this thread is leading to... I think I will be able to choose my distro myself. Concerning the toolbar icons: it looks like there is light at the end of the tunnel; it seemed that I forgot to call a gtk_widget_show on the added icon, which is strange, because in ModelPreview.cpp there is not a single call to gtk_widget_show() whatsoever and it's obviously working without problems.

I'm not afraid . There was just no real excuse for me to switch over (till now). I know that Linux is powerful and I planned to try it out (more than just inserting a Live-CD) several times, but I always postponed this as I will certainly need some time to get everything set up the way I want it to be - I've always been too lazy/busy, but I'm still planning to switch over completely some day.

My goodness, I will try this, I tell you. I have a shiny ubuntu 6.06 i386 ISO lying on my table for exactly this very moment, now I just need to find another hard drive to throw it on (this one is too small for a dual-boot, I'm afraid.)

Man, is there a way to make DarkRadiant linking any faster? It takes ages to link up the exe, I would be a lot faster if changing a single line would not entail three to four minutes of waiting.

Yes that did work, thanks! I'll look into the icon thing in the evening, have to leave now (plasma pysics lecture)...

Ok, I just wanted to try it out, but it seems the new brushexport plugin is not compiling: gplusplus -Wl,--kill-at -shared -o build\debug\brushexport.dll build\debug\contrib\brushexport\plugin.os -Lbuild\debug\libs -Llibs -llibxml2 -lz -liconv -lglew32 -lglu32 -lopengl32 -lgdi32 -lglib-2.0 -lgobject-2.0 -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lpango-1.0 -lpangowin32-1.0 -lgdk_pixbuf-2.0 -Wl,--output-def,build\debug\brushexport.def c:\programme\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibxml2 collect2: ld returned 1 exit status scons: *** [build\debug\brushexport.dll] Error 1 scons: building terminated because of errors. I tried to use "brushexport_env.useXML2()", but that didn't help. Is this just me?

I'm not sure, but I think I finally will have to use such a "association table", where all the icon paths are stored for each of the internal radiant commands (but it is possible to outsource this into an XML file as well). I have to create GtkActions for all of the radiant commands anyways, so this is not the main issue. The problem I ran into yesterday was how to get some icons to be displayed in the toolbar in the first place. I played around a bit, but I haven't found the right way to do this. Most probably because of my lack of experience with GTK, but I'm working on that. Basically, I get a GtkWidget from the GtkUiManager when I tell it the right path into the XML file (like "/toolbar", which returns a toolbar widget). This toolbar can be added to an existing container (in my case a vbox), this works, but no icons are there (just text buttons). I can change the display_mode of the toolbar to "GTK_DISPLAY_ICONS" (can't recall the exact name of the constant right now), but as there are no icons created by the UiManager, I have to set them on my own, which is where I'm stuck.

This is how "far" I got till sunday evening: I could load a simplistic toolbar from my XML file and could successfully connect the actions to the existing commands of Radiant. However, I'm chewing on adding the icons to my toolbar, as there is no possibility to assign icons via the XML. From the rather sparse documentation I found on the net, I assume it has to be done somehow via the GTkActions (there is even a function for creating icons for the action), but I could not figure it out before I stopped working yesterday.

I think the command you're looking for is called Patch>Thicken... in DoomEdit, which kind of extrudes your patch mesh. Other than that I can only suggest that everything is perfectly aligned on the grid, otherwise you're lost when aligning patch meshes.

My fresh and shiny sourceforge Username is: greebo_darkmod (greebo was already in use...) And I will take a look at this UIManager. edit: Heh, looks like my idea is not so new after all, this UIManager is exactly what I had in mind. I will implement it, but this maybe take the whole next week as I will be quite busy (as usual) the next five days.

Ok, I will go through the class and look where I can add the const. edit: I added some const qualifiers to most of the strings, should be better now. The patch is already in your inbox. Wouldn't it be easier if I directly sent this into SVN? Not that I plan to go an a SVN rampage as soon as I have access - I can ask you for permission before I commit anything, so that you can still control the commits. I'm currently working on outsourcing the toolbar icons to an XML file so that it is a bit more customisable. At the moment the icons are added to the GTKToolbar in mainframe.cpp line after line. I had something like this in mind: <?xml version="1.0"?> <project version="2.0"/> <toolbardescription> <settings> <!-- future settings go here --> </settings> <toolbars> <toolbar name="basic"> <item type="icon" caption="Open an existing map" bitmap="file_open.bmp" command="OpenMap" /> <item type="icon" caption="Save the active map" bitmap="file_save.bmp" command="SaveMap" /> <item type="spacer" /> <item type="icon" caption="x-axis Flip" bitmap="brush_flipx.bmp" command="MirrorSelectionX" /> </toolbar> </toolbars> </toolbardescription> What do you think? (Should I open a new thread for this?)

You've got mail!

I tried a few but I'm afraid I will have to use google. The changed files are on their way, I manually figured out which ones have been changed. Just a line in sconscript, and a few changed files in libs/parser and plugins/shaders. edit: found it, it's "create patch". This creates some unified diff file with all the changes. Next time...

Ok, I'm dumb , how do I do this with TortoiseSVN? The Diff-Command seems to be available for files only, not for folders. The "check for modifications" just lists the files that are modified, but not the differences themselves.

Ok, I think I'm done with a first version of the new parser. It is in principle a re-write of the parsing code that is capable of everything the old parser was, but this one is more structured and does not get confused with the image program functions like heightmap() etc. There is probably a lot that still can be improved, so a proofread and comments/suggestions from you would be appreciated! Which way do you want me to send them to you?

There was a useOpenGL() missing in the sconscript, after adding this to module_env it was resolved (add module_env.useOpenGL() after sconscript:108). I implemented the new constructor to DefTokeniser. It has now two optional arguments (const char* delims and keptDelims) apart from the inStr. This seems to work for me.

Ok, I will test it out right now! I have another question: I want to add the comma character "," to the list of kept delimiters of the DefTokeniser, but I somehow don't know how to do this elegantly (copying the whole DefTokenser to my own Tokeniser just doesn't feel right ). So at the moment _keptDelimiters is initialised by the DefTokeniserFunc constructor. Is there a way to change the _keptDelims later on (i.e. after instantiating it)? Apart from that, I'm nearly done with the parsing algorithm for the shaders, so hopefully I have something for you to proofread this weekend, if you don't mind ;-)

What happens with all this Quake3-specific stuff (à la ShaderTemplate::parseQuake3)? Should we keep this multi-engine support or strip these functions?

Maybe this is some bug in MinGW with this special scenario? We could try to compile it with a different version or cygwin?

Could you reproduce the linker error? I'm a little stuck a the moment, I tried to google about this problem, but could not find anything. Are you using MinGW or cygwin?

So the thing to avoid is multiple classes in one file, that sounds reasonable. Currently I'm working on shaders.cpp, where multiple classes and non-class functions are defined. Should I extract the texture parser from this file and pack it into a separate file and class?

Hm, I still get a linker error. Is there some LINKFLAG missing? The md3model.env is already using the useOpenGL() command. gplusplus -Wl,--kill-at -shared -o build\debug\md3model.dll build\debug\plugins\md3model\plugin.os build\debug\plugins\md3model\md5.os -Lboost.w32\lib -Lbuild\debug\libs -Llibs -Llibxml2.w32\lib -Lzlib.w32\lib -Llibiconv.w32\lib -Lw32\glew\lib -llibxml2 -lz -liconv -lglew32 -lglu32 -lopengl32 -lgdi32 -lmath -Wl,--output-def,build\debug\md3model.def build\debug\libs/libmath.a(aabb.o)(.text+0x263): In function `ZNK4AABB6renderEj': G:/Dark Mod/darkradiant/libs/math/aabb.cpp:49: undefined reference to `glVertex3f@12' build\debug\libs/libmath.a(aabb.o)(.text+0x2b2):G:/Dark Mod/darkradiant/libs/math/aabb.cpp:50: undefined reference to `glVertex3f@12' ... build\debug\libs/libmath.a(aabb.o)(.text+0x3ee):G:/Dark Mod/darkradiant/libs/math/aabb.cpp:56: more undefined references to `glVertex3f@12' follow collect2: ld returned 1 exit status scons: *** [build\debug\md3model.dll] Error 1 scons: building terminated because of errors. Regarding coding guidelines: This is a good idea, I will put them on the Wiki, as soon as you have them ready. At the moment I'm imitating whatever coding style I find in the existing source. Most important to know for me would be some naming conventions, upper and lower case and opening/closing brackets indentation guidelines (after if, else, while, void blabla() statements).

Ok, thanks for that! This week will be quite busy for me, but I hope that I can get some things to work in the evening hours.