greebo

The first step is done: I can select the light center (at the moment at 0,0,0) and all the callbacks to the SelectionSystem are up and running. The only drawback is, that the light center has to be located within the small rectangle that represents the light origin. I will look into this.

If I get it right, the SelectionSystem does handle this itself. It's a network of callbacks that is constructed and at the end there is a RadiantSelectionSystem::pivotChanged() method, that should take care of this . *fingers crossed*

This is my progress so far: I was able to successfully add an LightCenterInstance together with the selectionTestComponents routine to the LightInstance class. This means that I the light center can be selected and highlighted. I now need to add the required callbacks to the SelectionSystem so that the light center is rendered immediately and not after a forced SceneChangeNotify. This will be a bit tricky, but at least I know now what I need to do (at least I think I do). An ObservedSelectable should do the trick.

Orbweaver, I noticed you moved some of the light code into a separate file. Are you still working on that section or should I continue disentangling that section?

Thanks guys!

Yes, it definitely would make it easier. I think I suggested this before, but we agreed on having everything in one user.xml file, but I'm not sure, perhaps I only thought about it. However, I believe it would be quite easy to export/import things to and from separate files and I will happily implement this, if we think this helps. We can add this to the ToDo-List.

Just committed the reorganised patch files. I again added tons of comments, some sure will be helpful, some maybe not I also removed Quake3 and Wolfenstein stuff from plugins/entity, as I assumed them to be unneccessary. I'm still not entirely sure where to start with the light center, but I'm (slowly) getting there...

Ah, it is used in Patch::updateFiltered() but this function itself is not called anywhere. This explains everything. I thought, the compiler would immediately stop if the actual implementation is missing. Good to know.

I'm somehow unable to find the function bool patch_filtered(Patch& patch); anywhere in the codebase. There is this forward declaration in patch.h that refers to this function, but it isn't declared anywhere. Strangely enough, everything is compiling fine, so it has to be somewhere. Same for add_patch_filter. Exactly 1 Match in the whole darkradiant/ source tree. Is there something I missed?

I don't fully understand it neither, but at least I could learn a lot about the selection system and how the manipulators are used. The next thing I will document is the file patch.cpp, as the information about how the control vertices are handled will come in handy for the light center.

The reorganised SelectionSystem has been committed this afternoon, hopefully I didn't miss anything and everything compiles fine. I reorganised quite a bit, removed some unused code, changed some names to better fit the conventions, removed a global and added approx. a megabyte of comments.

Have a nice Birthday! I hope you find some time to relax and do the things you really want to do!

I tend to agree with New Horizon, that the Stim/Response editor is somewhat more important than the particle editor. And I would add one more thing to the list: better handling of copy & paste of Textures from Brushes onto Patches. This is one thing DoomEdit does better than DarkRadiant. Currently, if you copy the texture from a brush onto a adjacent patch (an inverted bevel, for example), only the texture name (and perhaps the scale) is copied, but the thing is misaligned. In DoomEdit, the textures get perfectly aligned. I needed this a lot in my bonehoard section with all those bevels and I always switched to DoomEdit, because it is so much more convenient than aligning it by hand with the patch surface inspector. Apart from that, the roadmap seems good. Should we go into more detail which of those parts should be tackled first / priorities / what the versions till 1.0.0 should cover?

I just found a section in selection.cpp, that is responsible for the selection modes (Shift-Click, Alt-Shift-Click and so on) and what happens for each of the these. It's not trivial to change the (hardcoded) modifier flags, as the actual selection behaviour depends on the control structures like switch and if conditions but it would definitely be feasible to alter the controls. This section is quite interesting for me and I will continue to document it. I just thought I should drop a note here, because this reminded me of the "Radiant-style vs. Blender-style controls" discussion we recently had.

I should have thought of that before and I hope that didn't stop the show for you, I will look out for this next time. I've picked up the disentangling and documentation of the selection.cpp classes and functions again, I had left this task half-finished. Hopefully I gain some insight from this that might help for the draggable light center. If not, at least the codebase is a bit cleaner than it was before...

Sorry, I forgot to remove this include, commit is on the way! The compiler didn't complain that this file is missing on my system till I did a complete recompile.

Both the BrushExportOBJ and the refactored PluginManager are committed. ad BrushExportOBJ: This can be found under "Edit" now. ad PluginManager: I split the old pluginmanager.cpp into separate files according to the class structure, removed the CopiedString stuff and the global variables as well. I also added some comments to the most important functions and classes.

I can perfectly live with any decision and I agree with having a roadmap to DarkRadiant 1.0, which should be covering all those things to make DarkRadiant the better DoomEdit (and the latter completely obsolete). I'm not sure if I would be much of a help with the main mod, but I will try at some time, probably around the time DarkRadiant 0.9-1.x or a bit earlier. I'm curious how much different SDK coding would be in comparison to the stuff I do now. Thanks for sharing your thoughts though, now I'm off to Eclipse again

Ok, so for the moment being, I will move this into the radiant core (it's not very large, so it won't have much impact on build times). I also have registered a command so that it can be used in both the menus as in the customisable toolbars. I will still have a look at the plugin manager code and perhaps make some additions, but at least we can tick this off the list.

This is something I'm thinking about for some days now and I better get it off my chest, so sorry for being off-topic. What about us implementing the current DR ToDo-List and heading off to SDK coding afterwards? Don't get me wrong, I really enjoy coding on DarkRadiant (I'm learning a lot) and I believe the editor to be really important for TDM's success, but if we extrapolate the current Overall MOD Progress™ into the next year or so, I'm afraid we end up having a top-gun editor with the mod staying somewhat behind. What do you (Orbweaver, Crispy) think?

I agree, using the xpath syntax is probably a good idea. We should take this into the todo list and also assign priorities to the various tasks. (I would consider the customisable menu rather a "nice to have" instead of a "must-have".) The brushexport code is de facto working and nearly commitable, but not a module yet. How important is the module bit?

If we speak of names for menus, then we would perhaps need to reorganise the "standard" menu creation code as well (which is (of course) hardcoded at the moment). Unless I created a function like PlugInManager().getPluginMenuItems("edit"), which would return all the menu items for the "edit" menu bar, but the issue of the actual location would remain and the menu names would still be hardcoded. Hm. First comes first, so I will try to document the PlugInManager for now and then look into some possibilites.

And yet again, another question. I found this global: CPlugInManager g_PlugInMgr; CPlugInManager& GetPlugInMgr() { return g_PlugInMgr; } And the function below returns it, obviously. Is it an improvement doing this with a static like this: CPlugInManager& GetPlugInMgr() { static CPlugInManager _plugInMgr; return _plugInMgr; } or is it not worth the hassle? Or should this be done in a completely different way?

IRadiant it is then! edit: committed.

I found a bunch of classes in pluginmanager.h and pluginmanager.cpp that already seem to be doing some of the things you suggested. I will try to analyse this part and document these two files, so that I know more about how the pluginmanagement works.