Talk:Wish List
Sign additions to page?
Should we sign our additions to this page? Mrflippy 12:54, 10 April 2006 (EDT)
- I don't know, I signed mine but I also referenced them in another talk page (Magic Effects). I think a got a little carried away with my list. I tried starting a thread on the forum for new functions a week ago but it was generally ignored. Too much traffic on there anyway, this list is better... I should note the reasoning for everything I suggested is point blank to simplify scripting. The more we can minimize the required use of hacks, workarounds, and excessively large scripts the better. At the same time there is a lot of room for improvement and a number of nearly required functions that are just missing (e.g. companion share). --MegaBurn 04:38, 13 April 2006 (EDT)
Sort list by priority?
I'd want a list sorted by priority. The Item/Inventory Scan (is in list, but missing proper description) and Object/Cell Scan (not on list so far) functions are almost mandatory functions. The possibility to determine the type of a ref (e.g. potion, weapon, armor, ...) also is (and not on the list).
- Also missing is GetSoundPlayed. I'd like to have sections "(was) in Morrowind" and maybe "(was) in MW Script Extenders". I will add the missing ones later, but I wanted to state that Devs should see what is HIGHLY important (companion share is, too).
- There could be an engine-bug priority listing (broken functions to be fixed) for both CS and Scripting. No Quest Bugs.
- I'd suggest in order to determine the priority we list the nicknames here and everyone can choose 3 top priority wishes in every category (General/Scripting). All four paragraphs by -- Grey 21:54, 16 April 2006 (EDT)
- Priority listing sounds to me like a great excuse for an edit war. Maybe I'm just being pessimistic. I like the thought of "Was in Morrowind/Script Extender", though. Grundulum 23:01, 19 April 2006 (EDT)
- I agree. Whats important to one person may not be important to another. I think just asking people to think long and hard on the stuff they request would be a better solution. Increasing the amount of discussion for this list would be good too. Then when someone makes a request they had better be ready to justify the need for implementing it. That said, I'll read over everything I suggested and move stuff that seems less important or unrealistic to the discussion page. --MegaBurn 10:05, 20 April 2006 (EDT)
Moved Requests
I moved a request here for reference, its low priority as far as I'm concerned and it can be deleted. I suggest other people do the same to clean up the wish list. Moving, removing, or rewriting the mini-discussion threads would also be a good idea. I think "seconding" a request is important and can have a petition type of effect but it should be kept short. Like just "I second this request." and sign it.
- Object Stats Window
- A window that displays the full stats of a character. Mainly for companions and pets, but could be useful elsewhere. This can be done now via dialog and/or message text, but a nicely formatted stats window would be much better. Adding a button for entering companion share mode would be good too. --MegaBurn 03:28, 13 April 2006 (EDT)
--MegaBurn 10:32, 20 April 2006 (EDT)
Someone moved this higher up on the wish list but its just too unrealistic. Without an extensive understanding of the inner workings of the game engine it would be near impossible to create new functions. I seriously doubt Bethsoft will ever release any source code at all or open the engine up to "force loading" other libraries (granted they really have nothing to lose, the script engine source can't be used on its own or with other game engines). Anyway, here the request for reference...
- Custom Functions
- An added CS subsystem used to create new script functions. I'm not sure how realistic this is, if it were "done right" it would require the script engine to be fully modular. If the existing script engine isn't modular then implementing this would require the programmers to completely rewrite the script engine. If it were implemented then new modules could be created in the CS. Could be very useful.
- Alternatively the script engine source code itself could be released and any C++ IDE could be used to create new functions. That would require the script engine in the game engine as well as the compiler in the CS to be moved to DLL's. But at the same time that could be used to load other libraries, thus Bethsoft would lose a great deal of control over the game engine. Stuff like loading new middleware, trainers, expernal bots, and external programs could be linked directly to the game engine (e.g. someone could implement a crude multiplayer system with RakNet). --MegaBurn 03:28, 13 April 2006 (EDT)
Also, in the range of "asking for a dollar, getting turned down, and then asking for a hundred...", I'm adding a request for Bethsoft to release the full Oblivion and CS source code excluding the 3rd party stuff (stuff they don't own the rights to). --MegaBurn 10:56, 20 April 2006 (EDT)
Source Code Release Notes and Comments
Bethsoft has maintained a remarkable level of support for modding over the years and this is the logical next step. While to date they haven't used mod content in their official products, that could certainly change as well. By creating a rigidly structured licensing system they can certainly take full advantage of the efforts of the modding community. If at the same time they were to release the engine and construction set source code then the community could effectively do a fair amount of the development work for them. This would allow them to increase the release rate, improve product quality, decrease development overhead, and otherwise make more money while also making the fans happy.
Major points in open source development will probably include: Implementing the entire wish list. Moving all hard coded game data over to ESM/ESP files (e,g, magic effects). Porting the engine to Linux and other OS's. Implementing multiplayer. Tweaking the engine to improve performance. Eventually replacing the closed source middleware with open source equivalents that Bethsoft can use in future games. Hopefully allowing the development community to build a fair amount of Bethsoft's next game engine for them.
Popular criticisms of game engine source code releases have, historically, been unfounded. Piracy, reduced sales, increased technical support costs, exploitation (viruses/trojans), etc have not been consistently reported as a result of releasing a product's source code, however stolen code has and will always be a problem (was a problem for Valve too so thats not limited to open source products, its a constant threat). It won't cost anyone their job either, much on the contrary, it could create a few jobs if source code or developer network access is sold as a product.
Few commercial developers have yet to take full advantage of open source development communities but as game development costs increase this will become a necessity in time. Fact of the matter is adding hundreds new “unofficial developers” to their development team will only have a net positive impact on everyone involved. This maybe idealistic, but a program like this could also drive people to learn C++ and game development, giving Bethsoft a near endless pool of experienced programmers to recruit from. I think the only major barrier to releasing the source code will be micro$oft (the evil empire doesn't play nice with anything having to do with open source).
To do this I suggest they create a development network similar to Red Hat's setup with Fedora (or for that matter Mandrake's model would work too, so would a dozen others). It would serve as a filtering process to give them most of the benefits of open source development without many of the headaches. If you think of it as an intellectual investment, it might take a year (or more) for this to actually produce something but in the long run it will yield significant returns.
It will work if they decide to take this route. --MegaBurn 12:48, 20 April 2006 (EDT)
How about spitting the page into several sections?
I mean, wishlist for modeling, wishlist for scripting, etc. I suspect this page will become really long later on... especially if requests will not get addressed, heh.
I'm not sure this will be addressed any time soon, but I think the sections of the page are growing a little too long again. Perhaps it's time to subdivide the sections, such as "Scripting -> User Interface", "Scripting -> Physics-related", or "Scripting -> TES Script Limitations". Grundulum 03:02, 26 April 2006 (EDT)