Leaderboard

I decided to open a thread about the Spidermonkey upgrade. There are some design decisions to take and it's good to have a place to write down the pros and contras. This is meant for discussions to take place and for work in progress designs and ideas that aren't final yet. I intend to use ticket 1886 for documenting more "final" decisions and information. Each GUI page in its own compartment The first major change is having each GUI Page (CGUI Object) in its own compartment using its own ScriptInterface instance. Currently the GUI uses two global objects. One is a page global for each GUI page which should separate global variables between the pages. The other global is used for all pages and contains engine function definitions and such. The new Spidermonkey associates a compartment with each global object and this design doesn't work anymore. At least I didn't find a way to make it work with minor changes. Cross compartment calls and wrapper objects could provide a solution here but I decided the other approach looks more promising. At the moment the plan is to register all GUI functions for all pages. I don't think registering maybe 100 functions for each GUI page should be a performance problem or memory problem. If it becomes a problem we can still implement something that lets GUI pages include functions they need. I figured out that the music code passes information across pages by using the global object called "global" (for example "global.curr_music"). A grep for "global\." returned only music related code, so it doesn't seem to be an often used pattern and could be replaced by a state stored in the music manager itself that could be accessed by a function. Concerning the JS console, the idea is that it should always use the currently active GUI page. Getting rid of g_ScriptingHost We are still using the old ScriptingHost that had been created before ScriptInterface was developed. That's unneeded duplication and should be replaced by ScriptInterface. It's sometimes a bit tricky because a lot of code simply accesses this global object and some thoughts are required that this code uses the right context/ScriptInterface/compartment in the future. Standardizing scripting access It's possible to access and use the JSAPI in a lot of different ways and we use too many of them in my opinion. That's probably because it grew that way and partially because different code has different requirements. I don't want to do too much at the moment but after thinking about it a lot and after discussing it with Philip I think we should remove CJSObject and the associated classes. It's currently used by the CRenderer, CGameView and the Soundmanager and I'd try to apply the same new pattern also for the JS console. The general approach would be providing global functions to scripts instead of custom C++ objects with GetProperty and SetProperty overloads, custom properties and custom methods. That's more or less the same approach Philip has chosen for the Simulation code and it seems to work quite well there. Object oriented design is good, but I think it's enough to have an object oriented scripting language and an object oriented engine. The interface between JS and the engine benefits more from a clean separation than from OOP. If there are global functions that can be called like "Engine.DoWhatEver()" it's clear that it is an engine function. Properties on the other hand can be script properties or native properties with custom getter- and setter functions that do potentially unexpected things. It's not obvious when using an object if it's a JS object or a C++ object with some custom functionality. The deprecated interface itself (CJSObject) required some quite hacky bits of code to create a relatively smooth transition between global/static callback functions and the objects. It stores some pointers in private data fields of JS objects and has to take care of some rooting to avoid garbage collection. I have to admit that this is hidden pretty well from the class users but what it does is still quite ugly (necessarily for that approach). I thought about either extending or removing the CJSObject-approach and my conclusion was that the additional flexibility is not really needed and the simplicity of global functions is the better deal. Here are some pros and cons I listed if you're interested (+ for pro, - for contra, ? for unknown or to-be-analyzed): Changing CGameView from the old pattern with CJSObject to the new one with global functions was very straight forward. Here is a reference implementation of CGameView @stwf I asked you about changing the Soundmanager code. What I had in mind was something like the example above plus the required changes in JS-Code and something as a replacement for passing data across GUI pages using "global.". For the moment you could use g_ScriptingHost for calling RegisterFunction instead of passing the ScriptInterface as an argument like in the attached example. I can easily change that in my code without causing merging conflicts later. Some additional thoughts about a configuration system Especially the renderer makes a lot of properties available to scripts that are essentially settings. When an options-screen eventually will be implemented a lot more settings will have to be accessible to scripts. I didn't want to develop such a system for settings because it's actually quite complex and requires some more time thinking about it. That should basically also be possible with global functions or the JSAPI could be used directly (something like the GUI does). In the worst case it would still be possible to reintroduce CJSObject if there are good reasons. Edit: Leper and I discussed that on IRC and came to the conclusion that functions are probably better anyway for the settings because they can provide a return value if for example the setting can't be enabled because the hardware doesn't support it. Is anyone against any of these changes or do you have additional inputs to consider? I've spent a lot of time thinking about it and I'm sure enough to write that post, but I still don't understand everything in detail and could be wrong about some aspects.

Locked again, as this didn't go anywhere.

There actually are archaeological traces of the First Temple. Not a whole lot, but various artifacts that would have been used in it have been dated to that time. Solomon was actually quite rich, I think he would have been able to afford the temple. According to National Geographic it seems likely that he would have had access to enough copper and other metals to build it. I think it's pretty reasonable to assume a large temple stood there. The Old Testament is historically reliable (Egyptian and Babylonian carvings confirm some Old Testament events, the Tel Dan stele proves King David existed). Certainly other sources should be used as well though. So yeah, I think there's nothing wrong with using the Bible as a historical account simply because it's also a religious text. There's not a lot of reason to doubt most of the stuff in the Old Testament. Besides, it would just look cool in the game to have this huge temple.... In the interest of full disclosure, I am a Christian and so that almost certainly biases my opinion of the Bible a bit. However, I would probably not be Christian if the Bible was obviously historically inaccurate.

There is no "multiplayer system". The networking model is something integral to how the engine is designed. If someone wants to create a new engine from scratch we obviously can't stop them, but people would probably be reluctant to commit something that would tear up all existing gameplay and AI functionality. Especially given that the gains overall are questionable.

I always loved Warcraft 3 TFT's world editor because it was really powerful and easy to learn. The ability to change unit names, stats, model, responses, weapon type, moving speed, abilities, nature (flesh/mechanic/magic/ethereal), etc. with but a click was an amazing achievement for many people and the why even today the game lives on with DotA (which second version is coming soon, to retire the War3's one) and other custom maps. BTW Starcraft 2 brings an even more powerful editor, but considerably harder to learn, too.