[stevie trent]

OH YOU'VE GONE AND DONE IT NOW

*dusts Morrowind case off*

edit: I'll be ready to help playtest OpenMW once it's at version 1.0 ^_^

[Kelsey Anna Farley]

Parallax mapping is definitely possible with OpenMW, since the OGRE engine supports it. You can even do parallax occlusion mapping and relief mapping... though you need high end graphics cards for those.

As for a new editor, well you could always open the entire OpenMW project in Eclipse, as well as all of its assorted dependencies like the graphics engine and physics engine. For the time being you would create mods the same way using the TES Construction Set and MWEdit... though since the scripting is much more advanced, it would be nice to get a new editor eventually. Though, as far as I know, you will be able to type all the new scripting capabilities right into TES CS, so a new editor isn't a super high priority.

[Khamaji Taylor]

I doubt making the editor would be all that complicated. All that is required is a working understanding of esp/esm files, nifs/kfs and also the ability to display all that stuff in a 3d environment (so an understanding of DirectX or OpenGL). We could do the UI in http://en.wikipedia.org/wiki/Qt_(toolkit)#Applications_built_using_Qt or http://www.gtk.org/screenshots.html and use OpenGL for the 3D portions. I disagree about using Eclipse to write a new editor. I'd rather see it written in C++ instead of Java (one of the reasons I oppose Eclipse).

Anyway, I think one of the best reasons to create an OpenMW Construction Set is because the vanilla CS is very much out of date. There are tons of features that could be added to it. You could put all the capabilities of the third-party MW utilities, plus add in things that are missing from the original CS such as more intuitive controls. Take a look at the Oblivion CS or the Fallout 3 CS (or The G.E.C.K.) and see what kind of improvements Bethesda made to the editor over time. We could implement the ability to directly choose the kf files (animations) or to edit the game's AI (which would be written in Monster Script for OpenMW).

[Barbequtie]

Greendogo definitely has a point regarding the Construction Set.
And so, we won't need an editor because we'll be able to make our own scripting language from scratch? :blink:

[Michelle Smith]

Greendogo definitely has a point regarding the Construction Set.
And so, we won't need an editor because we'll be able to make our own scripting language from scratch? :blink:

Well, we'll still need an editor for everything to be in one place. Until the time comes when we have a full fledged alternative to the vanilla construction set could you imagine making a mod without it?
Tbrick will have to check me on this, but I think that Monster Script is the gaming script that OpenMW is going to use for all the scripting that underlies all of the game play interactions. The scripting language we use now and which is extended by things such as MWSE will still be used (minus MWSE, because hopefully Tbrick will implement those scripting libraries by default), Monster Script is supposed to be the underlying language to everything and that's why I'm thinking it's also what the AI will be written in.

Tes96, I'm confused by this: "And so, we won't need an editor ... ?", of course we will, don't you think? I mean, we 'could' use the original editor provided by Bethesda. It will still be 100% effective at creating mods (all current and future mods that work with vanilla MW's engine will also work with OpenMW). I'm only suggesting a new editor so that any new abilities of the OpenMW engine can be taken advantage of in newer mods without the need to use several third-party programs plus the original CS. For example, an improved CS could allow easy manipulation of AI scripts. Vanilla Morrowind's AI is mostly inaccessible, but in OpenMW this won't be the case. It follows that anything that was hard or impossible to change due to hardcoding in the vanilla MW engine will be easily accessible under OpenMW's open source style implementation. A new editor would just facilitate its manipulation for people not versed in programming because editors provide an intuitive user interface.

[Yonah]

Edit: Also, what about a new editor to take advantage of OpenMW's extended capabilities?

What about being able to do it in game?

[Rachael Williams]

I doubt making the editor would be all that complicated. All that is required is a working understanding of esp/esm files, nifs/kfs and also the ability to display all that stuff in a 3d environment (so an understanding of DirectX or OpenGL). We could do the UI in http://en.wikipedia.org/wiki/Qt_(toolkit)#Applications_built_using_Qt or http://www.gtk.org/screenshots.html and use OpenGL for the 3D portions. I disagree about using Eclipse to write a new editor. I'd rather see it written in C++ instead of Java (one of the reasons I oppose Eclipse).

Anyway, I think one of the best reasons to create an OpenMW Construction Set is because the vanilla CS is very much out of date. There are tons of features that could be added to it. You could put all the capabilities of the third-party MW utilities, plus add in things that are missing from the original CS such as more intuitive controls. Take a look at the Oblivion CS or the Fallout 3 CS (or The G.E.C.K.) and see what kind of improvements Bethesda made to the editor over time. We could implement the ability to directly choose the kf files (animations) or to edit the game's AI (which would be written in Monster Script for OpenMW).

Actually Eclipse does much much more than Java. OpenMW is actually written in D... which is basically an updated version of C++. There is a D plugin for Eclipse, which is why I mentioned it... but you could just use a good ol text editor. Whatever works.

I definitely agree that a nice Qt editor would be sweet, but it is a ton of work. We can worry about that once everything is working. OpenMW still doesn't have animations, quests, sky, or water. Though, all the tools, knowledge, and scripting capabilities are there... so I am excited. However, it is still months away from a 1.0 release.

To speed things up, please help beta test... and if you have any programming skills, Nicolay is looking for people to just go ahead and code standalone examples of whatever feature they want, and then send it in for inclusion. The only caveat is everything must work with OGRE.

http://www.ogre3d.org/

What about being able to do it in game?

Forgot about this! Nicolay just implemented this capability, so it should allow for dynamic scripting. Much more powerful than vanilla Morrowind! hehe

[Heather M]

What about being able to do it in game?

That is another thing to remind me to do... Make the landscape editable at run time. Although I am not sure if I could apply the effect up the pyramid to the distant land at runtime.

[SexyPimpAss]

That is another thing to remind me to do... Make the landscape editable at run time. Although I am not sure if I could apply the effect up the pyramid to the distant land at runtime.

I'm sure you'll think of something Jacob.

I still believe a good ol' fashioned stand alone editor would be a good addition to the Morrowind engine update, even if we can edit during runtime of the engine, like you propose, Yacoby. The engine will undoubtedly take up more system resources than a traditional stand alone editor. Except for that little maybe-problem, I'm sure that we could implement anything in the runtime editor that we could implement in a non-runtime stand alone editor, so I don't see a problem with a lack of features. Just an abuse of system resources for some people with weaker machines.

I'm interested in how an in-game engine would change project workflow on a mod. I can imagine a situation where someone is testing out a texture on a mesh and must repeatedly close out of OpenMW (if obligated to use an in-game editor) and switch to Photoshop (or gimp, whatev'...). The time it would take to load the finished OpenMW would surely be about the same as the time it would take to load the plugins for Adobe Photoshop (if you've used it, you'd know ). I can also imagine a scenario where an in-game editor would save time and increase productivity by allowing terrain designing and housing conception to be demo-ed on the fly.

[Stat Wrecker]

Whatever happens, the terrain needs to be editable, as if we have an editor, we need to be able to render the terrain in it.

I still believe a good ol' fashioned stand alone editor would be a good addition to the Morrowind engine update, even if we can edit during runtime of the engine, like you propose, Yacoby. The engine will undoubtedly take up more system resources than a traditional stand alone editor. Except for that little maybe-problem, I'm sure that we could implement anything in the runtime editor that we could implement in a non-runtime stand alone editor, so I don't see a problem with a lack of features. Just an abuse of system resources for some people with weaker machines.

I would imagine that it shouldn't take up too many resources beyond what is default, as all that is really needed is some dialogs for adding objects etc. It would be slower than a standalone editor though. It could be annoying if there is a slight bit of lag with the dialogs though, and we would have to do a lot more frame updates (With a editor, you can avoid rendering a frame when nothing changes, as the menus are outside the render)

I'm interested in how an in-game engine would change project workflow on a mod. I can imagine a situation where someone is testing out a texture on a mesh and must repeatedly close out of OpenMW (if obligated to use an in-game editor) and switch to Photoshop (or gimp, whatev'...).

Well.... It is funny you should mention that. Someone on the Ogre forums has some code that watches for file changes in the resource tree, and reloads the resource on a change. I am tempted to go grab that and see if I can implement it (maybe enable it with a bool so it isn't running unless needed), as it would allow you to run the game in a window (or another screen) and work on the model/texture. Hit save, switch to openmw, and take a look.

Basically the PT command from Morrowind on steroids.


Even if I can't be bothered writing it in D, I can always write it in C++ with a C interface and throw it over to Nicolay

I can also imagine a scenario where an in-game editor would save time and increase productivity by allowing terrain designing and housing conception to be demo-ed on the fly.

:nod:

[Quick draw II]

Well, we'll still need an editor for everything to be in one place. Until the time comes when we have a full fledged alternative to the vanilla construction set could you imagine making a mod without it?
Tbrick will have to check me on this, but I think that Monster Script is the gaming script that OpenMW is going to use for all the scripting that underlies all of the game play interactions. The scripting language we use now and which is extended by things such as MWSE will still be used (minus MWSE, because hopefully Tbrick will implement those scripting libraries by default), Monster Script is supposed to be the underlying language to everything and that's why I'm thinking it's also what the AI will be written in.

And so you go from one obscure language, namely Bethesda's ghoulish home-grown TES3 scripting language, to another obscure language, namely Monster Script. Monster is currently at version 0.12(!) and 'growing': their own wiki doesn't even document the language structure and the latest news posts indicate that language features like classes and enums are 'brand new'.

Danger, Will Robinson, Danger!

You're heading into WTF territory here. I strongly suggest you use Lua or ECMAscript (you know; 'Javascript') as scripting languages instead. Those are mature, powerful languages with C/C++ bindings available. Lua in particular is aimed at game scripting. Monster Script may be written in D, just as OpenMW apparantly is, but that does not make it a good choice.

Speaking of which: why the heck code OpenMW in D anyway? Besides the obvious 'because we can' argument, I mean. Having it in D will seriously limit outside contribution, requiring each and every bit of general C++ to be wrapped and made interface capable with D or demands people mostly familiar with C++ to adapt to the D language and install and use a compiler that is in alpha stages. Bad choice, imho.

[Kill Bill]

And so you go from one obscure language, namely Bethesda's ghoulish home-grown TES3 scripting language, to another obscure language, namely Monster Script. Monster is currently at version 0.12(!) and 'growing': their own wiki doesn't even document the language structure and the latest news posts indicate that language features like classes and enums are 'brand new'.

Danger, Will Robinson, Danger!

You're heading into WTF territory here. I strongly suggest you use Lua or ECMAscript (you know; 'Javascript') as scripting languages instead. Those are mature, powerful languages with C/C++ bindings available. Lua in particular is aimed at game scripting. Monster Script may be written in D, just as OpenMW apparantly is, but that does not make it a good choice.

Speaking of which: why the heck code OpenMW in D anyway? Besides the obvious 'because we can' argument, I mean. Having it in D will seriously limit outside contribution, requiring each and every bit of general C++ to be wrapped and made interface capable with D or demands people mostly familiar with C++ to adapt to the D language and install and use a compiler that is in alpha stages. Bad choice, imho.

Except that tbrick is the author of Monster. Monster and OpenMW are inextricably linked.

[Quick draw II]

And so you go from one obscure language, namely Bethesda's ghoulish home-grown TES3 scripting language, to another obscure language, namely Monster Script. Monster is currently at version 0.12(!) and 'growing': their own wiki doesn't even document the language structure and the latest news posts indicate that language features like classes and enums are 'brand new'.

[...]

You're heading into WTF territory here. I strongly suggest you use Lua or ECMAscript (you know; 'Javascript') as scripting languages instead. Those are mature, powerful languages with C/C++ bindings available. Lua in particular is aimed at game scripting. Monster Script may be written in D, just as OpenMW apparantly is, but that does not make it a good choice.

:shrug:
The idea is that Nicolay wanted something closer to Unreal Script, and couldn't find anything open source to fit his needs.

[Mari martnez Martinez]

:shrug:
The idea is that Nicolay wanted something closer to Unreal Script, and couldn't find anything open source to fit his needs.

Use Javascript and something like http://www.jquery.com? Where jQuery handles event delegation to the DOM and DOM traversal, you could substitute DOM nodes for game objects.

For instance: How about getting rid of Fargoth the creative way?

$(":cell[name='SeydaNeen'] :npc[name='Fargoth'])  .find('inventory')	.empty()	.end()  .attr("currentHealth", 1)  .moveTo(":cell[name='RedMountain']");

This would select all game objects that are npcs with their name attribute set to 'Fargoth', that are children (aka reside in, are attached to) the game object of type cell with the name attribute set to 'SeydaNeen'. It would select the 'inventory' child objects of said selected game objects and empty them out, revert to the last selection (the Fargoth NPCs themselves), set the NPCs' currentHealth attribute to 1, then move them to another game object, which is a cell with the name attribute 'RedMountain'.


How about attaching a script that will autokill any NPC in the world when struck with a weapon?

$.bind("struck", function(event){  if ($(event.target).is(":npc"))  {	$(event.target).kill();	event.preventDefault();  }});

This binds the 'struck' event to the root of the game world. Any game object when struck with a weapon would propagate this event all the way up to the root (unless propegation is stopped by a previously attached event handler) and the root would execute the attached function. The event parameter contains a target field which holds the object that was originally struck. If that target object is an NPC, we execute the kill() function on it and then prevent the default action (wounding the NPC) from occuring by calling the event object's preventDefault().



A jQuery-like solution comes very close to how UnrealScript has certain functions (really; events) called by the Unreal Engine (though OpenMW would fire events which your script could bind() to), but it offers much more expressive power. You can easily pick game objects out of the entire tree of objects in the world and manipulate them. You can isolate code using namespaces and closures, etc. Something like this would really pull Morrowind scripting to the next level. Really, the only thing this doesn't work with is UnrealScript's concept of state, where one particular event may be defined multiple times for the various states (ie walking, attacking, standing still) an object can be in. However...

(function($){  function StruckAttacking(event){	 // continue attacking  };  function StruckFleeing(event){	$(this)	  .unbind("struck.aipack")	  .bind("struck.aipack", StruckAttacking)	  .attack(":player");  }  function StruckWalking(event){	$(this)	  .unbind("struck.aipack");	  .bind("struck.aipack", StruckFleeing);	  .fleeFrom(":player");  };  function StruckDamage(event, points){	$(this).attr("currentHealth", this.attr("currentHealth") - points));	if ($(this).attr("currentHealth"  <= 0)) {	  this	   .kill()	   .unbind(".aipack");	}  };  $(":creature[name='Rat']")	.bind("struck.aipack", StruckWalking)	.bind("struck.damage", ReceiveDamage);}(openMW));

Configures all rats to walk about, flee when first struck, then start attacking when struck again and continue attacking while struck after that. Meanwhile they will receive damage with the bound "struck.damage" event.

Comes quite close to emulating UnrealScript's states, no?

[Andy durkan]

I didn't make the choice. Nor have I used unreal scripts. I just reported vaguely what was said

[Kellymarie Heppell]

I didn't make the choice. Nor have I used unreal scripts. I just reported vaguely what was said

Even if you didn't, I'm just tossing out ideas here.

Imho what I gave is still a better alternative than inventing your own language as that can be very tricky to do right. If you take javascript off the shelf, you already have a complete language definition, interpreters, compilers, memory managers, etc.

Then you can implement a light-weight version of how jQuery or similar DOM traversing / event handling libraries work and adjust it towards use with game objects rather than DOM nodes, like I said. Such a little library on top would complete the package. Infact, for additional speed you could implement part of the top library in native D or C/C++ code, like the query selector engine or the event delegation system, and only expose black box APIs for those parts to the javascript environment.

[KiiSsez jdgaf Benzler]

Speaking of which: why the heck code OpenMW in D anyway? Besides the obvious 'because we can' argument, I mean. Having it in D will seriously limit outside contribution, requiring each and every bit of general C++ to be wrapped and made interface capable with D or demands people mostly familiar with C++ to adapt to the D language and install and use a compiler that is in alpha stages. Bad choice, imho.

Well we're going to have to eventually move forward. We can't stay stuck on C++ forever and ever. Hell, we might not even be using scripting in the next 20 years.

Remember the telegram? Western Union officially discontinued it years ago. So we should always be trying to push ourselves to learn the latest technology since that's the only way we advance, which in turn, will help us advance OpenMW more and more.

OGRE, too, will be replaced by something better in the years to come.

[Katie Samuel]

I'm pretty sure the scripting that most people will do will still be in Morrowind's original language. I think Tbrick is going to use a vm or something to spit it through and convert it to MS. That's why I said tbrick needs to check me on that, because I'm not the man with the plan. He is.

On another note, using D and Monster Script is for the best. The reason being because tbrick/Nicolay is the one who wanted to do it that way and he is the one doing the brunt of the work and the one who concieved of OpenMW to begin with. In addition, he'll probably be the one to finish it. So unless you don't want OpenMW because of a [not so unreasonable] request that it be done in another language, then we should probably stick with his ground plans.

Also, Java, and everything associated with it, should imho be wiped from the face of the earth. But I'm only an engineering student, so what do I know yet?

[emily grieve]

Monster is currently at version 0.12(!) and 'growing': their own wiki doesn't even document the language structure and the latest news posts indicate that language features like classes and enums are 'brand new'.

You're right about Monster being a new language, and definitely right about the documentation. The language is at a more stable point than the web pages betray though, and it's already used in several places in OpenMW to great effect. I decided to temporarily pause the general development of the language when all the key features were in place (OO/polymorphism, packages, virtual threads, states) and instead concentrate on OpenMW and let the language development be guided by that for a while.

Also, classes have existed since Monster's inception, but some aspects of polymorphism are new. Enums are new, mostly because I didn't even know if I wanted them at all (Lua doesn't have enums, for example.) I'm not saying this to score "easy points" on you or anything (I know you haven't looked at the details yet), just thought I'd clear it up.

I strongly suggest you use Lua or ECMAscript (you know; 'Javascript') as scripting languages instead. Those are mature, powerful languages with C/C++ bindings available. Lua in particular is aimed at game scripting.

I did consider Lua when I first started, and found it underpowered for what I had in mind with OpenMW. Not that it's not a great language, it is, especially for small stand-alone scripts. But it's just not designed for the kind of object oriented system building that I want to do. Squirrel or GameMonkey (other game languages) are much closer to this than Lua (and Javascript), but they still lack several essential features besides being somewhat clunky.

Having it in D will seriously limit outside contribution, requiring each and every bit of general C++ to be wrapped and made interface capable with D or demands people mostly familiar with C++ to adapt to the D language and install and use a compiler that is in alpha stages.

The D compiler is way past the alpha stages, DMD 1.0 was released over two years ago and I've been using the language closer to six years myself.

I absolutely agree with you about outside contributions though, that's the biggest drawback of not using C++. Probably the biggest problem is that it scares some people away from even looking. My experience so far however is that people who actually want to contribute just do it anyway. Either with C++ code (which is fine) or by modifying the D code (the languages are pretty similar.)

[Pawel Platek]

I spilled [censored] onto my laptop last week. Damn me to Oblivion! Err, at least I remember what I did on it.

Anyway, yay progress!

[Rebekah Rebekah Nicole]

Well we're going to have to eventually move forward. We can't stay stuck on C++ forever and ever.

We won't. The successor to C++ is called C++0x and the standard is currently in development with the C++ standards committee. It'll probably be a few years until it'll show up in real life, given that compiler vendors also have to update their compilers, unless they're working in parallel with the committee refining the draft standard. Until then libraries like Boost give C++ plenty of staying power. Infact: Ogre uses parts of Boost as well, though it offers a compiler switch to drop back to its own constructs if you don't want to download and install Boost to compile Ogre.

You're right about Monster being a new language, and definitely right about the documentation. The language is at a more stable point than the web pages betray though, and it's already used in several places in OpenMW to great effect. I decided to temporarily pause the general development of the language when all the key features were in place (OO/polymorphism, packages, virtual threads, states) and instead concentrate on OpenMW and let the language development be guided by that for a while.
Also, classes have existed since Monster's inception, but some aspects of polymorphism are new. Enums are new, mostly because I didn't even know if I wanted them at all (Lua doesn't have enums, for example.) I'm not saying this to score "easy points" on you or anything (I know you haven't looked at the details yet), just thought I'd clear it up.

That's part of the problem: you're iteratively adding to the language. I don't mean to step on anyone's toes with this, but I'll warn you now: that will eventually lead to a language design problem you missed. PHP and its many quirks and idiosyncrasies are often cited as the canonical example for why iterative language design doesn't work. If you think you can keep it under control and manage to keep things working, and working well (especially an efficient script compiler or runtime), more power to you though.

I did consider Lua when I first started, and found it underpowered for what I had in mind with OpenMW. Not that it's not a great language, it is, especially for small stand-alone scripts. But it's just not designed for the kind of object oriented system building that I want to do. Squirrel or GameMonkey (other game languages) are much closer to this than Lua (and Javascript), but they still lack several essential features besides being somewhat clunky.

Imho what you really need is a well established, well known, easily accessible language that is centered around mutating (nodes in) your scene tree. Because that's what your entire game world is: a tree of nodes. Hence why I cited the example of jQuery which does this really, really well with the html DOM tree by making effective use of javascript's closures and first class functions.

The D compiler is way past the alpha stages, DMD 1.0 was released over two years ago and I've been using the language closer to six years myself.

My source was outdated: D is indeed stable now.

I absolutely agree with you about outside contributions though, that's the biggest drawback of not using C++. Probably the biggest problem is that it scares some people away from even looking. My experience so far however is that people who actually want to contribute just do it anyway. Either with C++ code (which is fine) or by modifying the D code (the languages are pretty similar.)

From D's FAQ itself I gather that it is not compatible with C++ proper. C++ can be massaged to work with it: D only works with functions or classes in the root namespace (aka 'no namespace at all'). It can only work with single inheritance due to the layout of the virtual function table. It can't access classes by value (which is how you are supposed to work with C++ if you use RAII). And there are oversimplified, optimistic assumptions about the non-standard C++ name mangling. That all leaves you with one reliable option: make simplified gateway interfaces in a format compatible with flat C to bridge C++ with D. In the process you lose all OO-aspects and everything goes down to flat functions and structs.

That is a major, major detracting point when you consider all the pre-made facilities in Ogre for timers, event callbacks, resource management systems, etc. You simply can't leverage those effectively anymore, unless you perform everything through pre-built flat functions and only share 'handles' to those objects with D. Infact: that's probably what you should end up doing. I suggest you take a look at how Quake 3 handled its VM trap calls, which is a similar system and from personal experience works quite well. (It's GPL, incase you didn't know.)

Imho if you want an 'easy' language that can bind to C++ and retain more of the OO goodness, you should use C#. A glue layer made from managed C++ can interface to native C++ libraries like Ogre. Actually such a library already exists: OgreDotNet. Anything D does, C# probably can do as well. Performance wise it also isn't that bad considering MSIL bytecode is compiled down to native code by the runtime before it is executed.



Personally, I would've used C# for my own Ogre related project if I hadn't decided to invest time in learning about the C++ STL classes and common C++ design patterns (such as the factory pattern on which Ogre relies, which helps ensuring proper resource de-allocation, meaning you don't need a garbage collector). I'm much too happy working directly with C++ and Ogre's facilities to start contributing actual 'massaged' C++ code or D code. If you need some insights into architecture I can always give a few pointers though.

Well, best of luck to you, I guess.

[Jaki Birch]

We won't. The successor to C++ is called C++x00 and the standard is currently in development with the C++ standards committee. It'll probably be a few years until it'll show up in real life, given that compiler vendors also have to update their compilers

To be honest I can't see any major improvements in C++0x - there's some interesting template improvements in there, but D already surpassed them in that area years ago.

That's part of the problem: you're iteratively adding to the language. I don't mean to step on anyone's toes with this, but I'll warn you now: that will eventually lead to a language design problem you missed. PHP and its many quirks and idiosyncrasies are often cited as the canonical example for why iterative language design doesn't work.

PHP strikes me as a language that: A) was badly designed from the start (or at least, not designed to scale) and B ) is constantly stuck in the compatibility trap, with the dilemma of fixing the language vs. supporting older code. Unfortunately they seem to choose the middle ground, ie. to make everybody unhappy. This is a far cry from growing a language that hasn't reached 1.0 yet (having zero compatibility issues), and that has a clear plan of exactly what it is and where it's going.

That is a major, major detracting point when you consider all the pre-made facilities in Ogre for timers, event callbacks, resource management systems, etc. You simply can't leverage those effectively anymore, unless you perform everything through pre-built flat functions and only share 'handles' to those objects with D. Infact: that's probably what you should end up doing. I suggest you take a look at how Quake 3 handled its VM trap calls, which is a similar system and from personal experience works quite well. (It's GPL, incase you didn't know.)

This is pretty much what we do, yes. You're absolutely right about what you say, we don't (and can't) use various Ogre (or Bullet, or FFmpeg, or MyGUI) constructs throughout the engine. This does have drawbacks. But so far it has worked surprisingly well. If anything, the C++/D split has forced the code to be much more modular, which has come in handy the two times (and possibly coming third) we've switched audio libraries.

Imho if you want an 'easy' language that can bind to C++ and retain more of the OO goodness, you should use C#. [...] Anything D does, C# probably can do as well. Performance wise it also isn't that bad considering MSIL bytecode is compiled down to native code by the runtime before it is executed.

Sure, C# would probably have worked well too. I'm not saying D is better than everything else, language is a matter of taste too. But in my very biased opinion, D is so much better to use than C++ that it's worth all the hassles you've mentioned and more. If I had to do OpenMW in C++ there's no chance in heck I would have stuck to it as long as I have. Coding C++ has become directly painful.

BTW you can find a rough feature comparison of various languages here: http://prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD . Looks like I should have picked Lisp

[Fiori Pra]

I love this. It's a programming throw down!





... java still svcks!

[Sarah Unwin]

We won't. The successor to C++ is called C++x00 and the standard is currently in development with the C++ standards committee.

C++0x

[WYatt REed]

C++0x

You're right. I must have completely brainfarted when I typed that. D'oh! ::fixes previous post::

Anyway. I'll think of some more concrete points to add to OpenMW's wiki wishlist.

I might not feel like doing the actual code work, but I can contribute in other ways.