MapExpressions

[greebo]

Ah, yes, I can reproduce that crash even in Windows. There seems to be a problem when inserting the worldspawn entity into the scenegraph, which is a bit weird. I'll check that out.

[greebo]

The crash seems to be related with the node resorting happening in Node_insertChildFirst(). This may or may not be related to my latest changes to the Traversable implementation, but I'm a bit sceptical here. It might be that this code has never been used up to this date, as this situation (model node is inserted into the scenegraph root before the worldspawn node) has never been encountered.

 

I'm still investigating, this takes time because my 32-bit machine is so slow.

[greebo]

Should be fixed, this was kind of tough. I recently changed the TraversableNodeset class to use std::vector instead of the home-grown UnsortedNodeset. What I missed was that the nodeset iterators have to stay valid even when a walker class removes an element during traversal. This is is obviously not provided by std::vector (an indication for this is also that the erase() method of std::vector runs in linear time), so I changed it to use std::list instead (whose erase() method runs in constant time).

 

Anyway, it should work fine now. Please check it out on your end.

[mohij]

It works great. :-) And now that I can test it, my patch also works.

[greebo]

Your patch is on SVN now. I think you can cross off the task from the tracker now.

 

What topic do you want to work on next?

[mohij]

I'm quite short on time atm, so I'm not sure if I can continue to programm as regular as I did until now, sorry about that. So some task that isn't time dependant and can be done as I have time would be cool.

 

Something that came into my mind yesterday is internationalization an UTF-8 (even though I have zero experience in that area).

[greebo]

Little time is not a problem at all. We don't have any deadlines for our tasks, so almost anything would be suitable.

 

What do you mean with internationalisation? Were you thinking about the language strings of the UI and such?

[mohij]

Yes, exactly that.

[greebo]

This would require a good concept, I reckon. OrbWeaver, what do you think about that?

[OrbWeaver]

To be honest I'm not really seeing the return on investment of that task -- it would be a very large amount of work to do properly, just so that people could view the menus in Japanese katakana or whatever.

[Crispy]

What languages does vanilla D3 support anyway? Just European ones? The patch notes for D3 1.3.1 suggest that at least English, French, Italian, and Spanish are supported.

 

I've had a little internationalisation (i18n for short) experience. There are lots of potential pitfalls and it is a bit of a pain; even more so if you're trying to retrofit existing code.

[mohij]

Then something else is fine too, it should be fun though ;-)

[greebo]

Depends on what you consider fun

 

Things that come into my mind:

• There are a few smaller user requests on the tracker (camera speed, language tweaks) - nothing spectacular, but needs doing sometime.
  
• Some code refactoring. This can be boring, but you can learn a lot about the DarkRadiant codebase this way (at least I did). The struct Winding class in winding.h is such an example, which could be moved into the brush/ folder into proper file pairs.
  
• Speaker radius rendering (tracker). This can be challenging, but would be a welcome addition for mappers. Would get you involved with how to add renderables to the shadercache plus OpenGL commands.
  

Maybe OrbWeaver has some more suggestions?

[mohij]

I think the speaker radius thing sounds cool. It's probably a lot of copy and paste from light radius I guess.

[greebo]

Yes, at least you'll have to read a lot of code from these classes. However, note that the light class might not be the best or clearest way to implement that type of things. Much code still is structured in GtkRadiant's style, which can express itself in things named in non-obvious ways, an obscure network of callbacks and base classes implemented as member variables instead of a clear class inheritance - sometimes complicated, where it could be easy and vice versa. You'll see that soon enough, I guess.

 

I'd suggest you just dive in and we discuss that topic in a new thread.