mohij

It's quite relieving to hear that, I already felt bad a little bit So till monday then.

I'm away over the weekend, so sadly I won't be able to continue on this before monday. I hope this won't break any timelines.

Hey, that is what I tried to do before, but then the compiler told me that it is plainly impossible to call functions from non instantiated classes, now I know better . Cool, learned another thing, thanks. This way it is of course nicer.

I want to create it as a global function. It shouldn't associate to some class, just because I made it friend of one, should it?

Would a boost::shared_ptr<IMapExpression> createForToken(parser::DefTokeniser& tok) external friend function also be acceptable instead of another class? I got stuck while trying to use this function as a member of class IMapExpression, because you can't instanciate a class that is has vitual, but need to, because the createForToken is member of it. So simplest solution would be to make it external, but friend. Is that acceptable?

With such a createForToken function I wouldn't even need an extra factory class. The method would simply be called for the base class by the Shader code, that's cool. And I think that this single function should already suffice as the public interface for the class. I will try/start to implement it tomorrow, I guess the next big task will be the MapExpressions themselves.

After thinking about a service class, I am not sure anymore whether it would be easier with an extra service class. This extra service class would have to seperate between the different Tokens and work differently for different MapExpressions (as the different MapExpressions need different input). So I think implementing a service class that differenciates between the different MapExpressions and parses them the input they need would end in one big service class that does all the work and very small MapExpression classes that could as well be only functions. (the polymorphism wouldn't get used). MapExpressions that call each other are perhaps still better.

Sound works very fine for me. Except that some sounds show: "Error: File not found." But that's another issue I guess.

I think an extra "parsing class" that creates the MapExpressions would be better. I think it would be easier to handle as things are seperated.

The MapExpressions are only implemented on a very basic level at the moment. They should be reimplemented in a better way. At the moment I need to understand how they are used (or should be used) and how the new design should look. OrbWeaver said something about a hierarchy of polymorphic objects and an IMapExpression interface. The IMapExpression interface sounds like a module, I'm not sure whether a completely new module is appropriate for such a special thing as MapExpressions. Polymorphic objects sound good, but I'm not sure how the hierarchy should be done, the current implementation seems a bit trival, perhaps there is a better solution. Is the functionality of the MapExpressions (addnormals, hightmap, etc.) implemented somewhere already, or do I have to write those from scratch too? So that's where I currently am, tell me what you think.

The forum is quite big, wow Is there already a topic about the MapExpressions or should I open a new one? I already read through this one.

Okay, I totally missed the point, I think I understand it now.

So a refactoring of the interface, to be based on Shaders and not Textures would be appropriate? That would in some way be related to the MapExpression refactor, I think.

Ah, ok, understood, another question: Why are Materials still represented by Textures? Doom3 uses only Materials (if I got it right). So why does Radiant do anything with them?

I took a look for into the shadersystem. If I understand correctly, the MapExpressions are simple modifications to textures, to enhance them on demand. And they are specified in the .mtr (Material) files. What I don't understand is, what Radiant has to do with it. It doesn't display them (does it?).

I think I will try the Map Expressions as they are more useful. If I really get stuck, well, then I can still try the other. I'm away in school, will be back in about four hours.

Well, as I don't have that much insight in what is needed or not, I'm not sure what would be better to do. The object counter seems doable. The Map Expressions support sounds complicated, but I could at least give it a try. So tell me what you think.

It's great to get such feedback, it really helps understanding things more, thanks. So, I guess I'm free for another task...

I think it is fixed in latest HEAD. But I'm not sure what exactly fixed it.

Will take a look. Just some random thoughts: dynamic_cast() returns NULL when downcast wasn't successful. MinGW has gcc 3, Linux generally version 4.

Error message HEAD shows when creating entities: libs/scenelib.h:739 assertion failure: findInstance: path not found in scene-graph ... Depending on the entity I try to create, I also get the old error.

I tried version 1760 and it works.

Yes, I am on Linux. (Gentoo x86, mostly stable)

I finished programming this feature. My problem is that radiant segfaults on any operation on entities. As this also happens also without using my new button, this is probably not related to my changes. So I can't test my button (and remove all those bugs that are surely in there ;-). Sometimes it just segfaults other times it shows: /plugins/entity/eclassmodel/../modelskinkey.h:114 assertion failure: pointer "instantiable" is null ---------------- ---------------- Please report this error to the developers I guess it is related to greebos recent changes. I have no idea what I should do...

Are there any policies regarding exact coding style? like int func() {vs int func() { Or indent size? Can I use two spaces as indents?