Itches, Glitches & Anything Else...

[OrbWeaver]

Speeking of Menus, how about that extension that I mentioned earlier, where def objects can be grouped into a menu hierarchy, instead of having a flat menu whenever you want to assign an entity?

 

That was implemented weeks ago. There was even a screenshot of it in the announcement.

[sparhawk]

That must have been posted by a hacker, I don't recall asking such a question.

[SneaksieDave]

Should the entity list be grouped in subdirs now? I still get a flat listing, but I assume that could either be because,

 

a.) the ability to do it exists; it just hasn't been applied to the list yet, or

 

b.) I have to delete my XML files

[OrbWeaver]

a.) the ability to do it exists; it just hasn't been applied to the list yet

 

Correct. It is up to developers to add the correct key to their entityDef so DarkRadiant knows where to put it in the tree. This is currently set as editor_displayFolder but it could be changed in the .game file if necessary.

[greebo]

I just noticed that the HashedCache is gone. This deserves a hooray!

[OrbWeaver]

The ShaderCache has now been changed to use a std::map instead of HashedCache, and the HashedCache itself has been removed altogether. The ShaderCache now returns boost::shared_ptrs instead of raw pointers, and the stupid "release-by-name" requirement is gone as well.

[SneaksieDave]

Mmmmmmm... hash and cash.

[greebo]

I just a weird experience concerning the static member MediaBrowser::getInstance(), which had its definition in the header file MediaBrowser.h. This of course worked fine up until now.

 

I tried to include the MediaBrowser.h header in the ShaderClipboard.cpp file to get access to MediaBrowser::setSelection() via the getInstance() method. The function was executed fine, but crashed as soon as I tried to access any member variable (_treeView for instance).

 

I checked the this pointer from within the member MediaBrowser::setSelection() and it turned out to be NULL, which I first thought was not possible (some googling about this revealed that this can of course be the case).

 

The resolution of this problem was to move the MediaBrowser::getInstance() definition from the header into the source file MediaBrowser.cpp and the this pointer suddenly become non-NULL and the program executed fine.

 

My guess is that the static method definition in the header file works as long as the header file is included only once in the project. Now that I included it a second time from the ShaderClipboard.cpp file, the compiler/linker/whatever seemed to fail. I tried to move the static method back to the header and could instantly reproduce the crash. I don't know if this is platform-specific or not.

 

Another one and a half hour and another hard lesson learned: don't define static member methods in the header (especially if they contain a static instance of class).

[sparhawk]

If it's a static, then it would be instantiated in each file that it is included with, which means, that you owuld have to initialize it in all the files that you included it. That doesn't really sound like how a getInstance() function should work like.

 

basically it would be the same as defining in each cpp file a static variable, unless that getinstance function access a global pointer, which would make sense. Can you post the getInstance() function?

 

Sounds to me as if they tried to create a kind of singleton pattern this way.

[OrbWeaver]

Yep, you need to think in terms of the translation unit that a declaration appears in. A translation unit is a CPP file with all of the header files included in it -- i.e. a single line of GCC output when it is compiling. If your static object is defined in the header file and included more than once, you will get a static object in EACH translation unit that the header file is part of.

 

In short, a static object should always exist in a single .cpp file.

[greebo]

Yep, I know of that translation unit viewpoint, I already had to struggle with it back in October, when I had problems with the #include statements.

 

I usually move all the definitions of all the classes I write into the .cpp files, with a few exceptions (walkers or library methods and such), that's probably the reason why I never ran into that kind of problem before.

 

I already moved the MediaBrowser::getInstance() stuff to the .cpp file, so that's ok now. I don't know if there are more static members in the headers, I haven't looked through all of them.

[greebo]

OrbWeaver, I think I squashed most of the bugs in the tracker. I'd like to move on with either the Sound Selector or the Stim/Response Editor. What do you suggest?

[OrbWeaver]

OrbWeaver, I think I squashed most of the bugs in the tracker. I'd like to move on with either the Sound Selector or the Stim/Response Editor. What do you suggest?

 

I would guess that the rest of the team would consider the S/R editor the higher priority, although I am not bothered either way myself. As it happens I have already committed a dummy Stim/Response plugin, as a way to test that multiple plugins can be loaded, which you could either use as a base or copy into a new plugin if you wanted to make the Sound Selector as a plugin.

[greebo]

As for the Sound Selector, I would say we could proceed in a similar way as with the ShaderSystem: make the actual SoundShaderSystem a module, but leave the rest of the UI in the main app, like the ShaderChooser stuff is.

 

I personally would prefer starting with the Stim/Response Editor, so I'll open a new topic about it.

[OrbWeaver]

As for the Sound Selector, I would say we could proceed in a similar way as with the ShaderSystem: make the actual SoundShaderSystem a module, but leave the rest of the UI in the main app, like the ShaderChooser stuff is.

 

Yep, that sounds good. The Sound Selector is not DarkMod specific so there is no reason why it needs to be a separate plugin.

 

I personally would prefer starting with the Stim/Response Editor, so I'll open a new topic about it.

 

Fine by me

[sparhawk]

That sounds great. DR is shaping up nicely quite fast. If you continue this pace you can help with the mod, once you are finished with DR. At the current pace, I expect that it will only take a few weeks more.

[New Horizon]

Once we get Objectives and SR in place, we'll really be able to push mapping in new directions. Should be much more user friendly to setup a playable mission.

[sparhawk]

Yes, and with these features I hope to have a playable demo out soon. Welol, I think we should definitely aim for end of the year with an early alpha demo. What do you think? Maybe not bonehoard though, as it is rather big, and we should keep such a maps for our first official release. Something smaller though, should be possible.

 

BTW: Today I saw one thread on TTLG in the dromed forum where a mapper alyready said that he will switch to Darkmod when he is finished with his latest FM.

[OrbWeaver]

A couple of comments on the UI manager.

 

1. I have changed getMenuManager() to return a reference rather than a pointer (use references when you can, and pointers when you have to). This avoids the confusing syntax of GlobalUIManager().getMenuManager->blah(), where both types of dereferencing are used in the same statement.

2. The UI manager would be a candidate for an external module -- using the rule that a module which is EITHER used by other external modules OR needs to change from game to game should be external, whilst all others should be internal. In this case the UIManager is used by external modules (namely the S/R and Objectives editors). This is obviously not a priority issue, but if you were wondering whether it should be a separate module or not, my opinion is that it should be.

[greebo]

Ok, thanks for changing it. If I recall, I first feared about slicing issues and chose to return a pointer, but given that all the important stuff is defined in the interface, that's of course not a problem.

 

I'll open an issue for moving the UI manager into a module.

[OrbWeaver]

Slicing only happens when you return (or pass) by value. Both pointers and references work the same way with polymorphism.

[greebo]

Obviously the gtkutil::getLocalPixBuf() method doesn't work correctly when called from plugins, unless you call the BitmapsPath_set method from within the module.

 

This is a bit annoying and cost me at least one hour searching why the damn icons didn't get rendered.

 

What solution do you suggest here? Should this be incorporated into the UIManager or should a method be added to the qerplugin.h allowing to retrieve the absolute install/bitmaps/ folder location?

[OrbWeaver]

You're right, there's a horrible global CopiedString variable in that function. I suggest replacing all of the getXXXPath() functions on GlobalRadiant with a single getPath() method, which takes a single string argument detailing which path is required (e.g. "application", "bitmaps", "maps" etc). This would slim down the already-bloated IRadiant interface and allow additional paths to be added without changing the interface.

[OrbWeaver]

Do you want to track all design/architectural issues on the bug tracker? I tend to only raise issues that are user visible, but raising issues of design or implementation seems perfectly reasonable as well. Perhaps we should have a separate category for Design/Code issues, so they can be tracked separately and given a lower priority than actual user-visible bugs and features?

[greebo]

Fine for me, feel free to add the according category.

 

I think we should track all the stuff we're talking about here that can't be immediately changed, otherwise it will soon be forgotten.