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)

Original Post with Discussion

I rewrote the request on the article page and moved the original text with all related comments to this page. If anyone has a problem with this just look at the very top of the Wish List, it clearly states to keep the discussion on this page. I doubt they care if it hits a hundred pages as long as the main Wish List article remains short and to the point. This is an "archive section" please do not edit. --MegaBurn 19:27, 27 April 2006 (EDT)

However unlikely, I request that Bethsoft release all Oblivion engine and Construction Set source code (which they own full rights to). The proprietary middleware can be readily left in closed sourced linked libraries. This would allow the modding community to expand into the realm of engine tweaking and further software development. Its clear that Bethsoft will get a full return on their investment in developing the Oblivion engine, if they haven't already (note the record sales announcements). So effectively there is nothing to lose and this is already paid for, by us, their customers. If done correctly this can become a major "win win" move for Bethsoft.

The best case scenario, as I see it, is the development community this release creates would be able to develop open source replacements to the proprietary closed source middleware and then expand the engine to support other RPG sub-genres, and implement full multiplayer. In effect that would save Bethsoft the licensing fees for the middleware, and possibly development time (big money) on adapting the engine for future expansion packs, and possibly Fallout 3. The worst case scenario is the development community does not form (unlikely) and some of the source code is stolen by open source projects (likely) or maybe non-US based game developers (unlikely). (see notes on the discussion page) --MegaBurn 11:43, 20 April 2006 (EDT)

Extremely, if not absolutely unlikely. It makes no business sense to provide the public with the very tools that would allow them to compete with you. Every company understands that the modding communities are capable of producing conversions that can even match the quality of the commercial product by using the sheer unpaid and often professional will and manpower. Why would Bethsoft allow someone else access to the technology, when they can create, given time and resources, a better game for free. That would tarnish their image and dellutes the value of the IP the company owns and this is very important in the corporate world. We can expect some goodwill when one or two generations of the engine have passed (that's how iD releases their Quake engines, when no body needs them but for educational or hobby purposes). I hope that Bethesta does that with Morrowind to allow her megahit title to live on, tho... ---RaynerApe

True, its extremely unlikely and a rather unconventional approach, but even releasing the full construction set is unconventional. More importantly, you hit the nail on the head in terms of what the modding community can do. Its all a matter of how this is structured. If they just blindly released the source code then, yeah, sales would suffer and IP control would be lost. Being smart about it, tapping the community, and managing access to some sort of developer's network would do it. Think about the sheer man power aspect, really tapping into the community could turn Bethsoft into a game production power house shipping titles with hundreds of hours of game play every year rather than every 4 yours. In time it could even get to the point where content is being released faster than people can play it (thats true of mods now). IP control is all in the fine print, if signing up for a developers network program required signing a non-compete with clearly stated ownership rules then in asset terms Bethsoft would wholly own contributed IP so theres no real risk there. I really don't like the concept of having to pay for access something like that, but it would filter out people who aren't serious about working on it or who might seek to exploit it, so maybe paid access could come with discounts/vouchers on game orders placed with Bethsoft directly. Bethsoft has done extremely well for themselves by taking the road less traveled, this is more like blazing a trail through thick underbrush. If they're smart about it and work with the community directly, they could do great things for the future of the game industry while getting even richer in the process. Given Oblivion's success there is no question about their having the wherewithal to fund another web server (or three), dedicated CVS/SVN server, RPC based compile server (TES@Home!), a T3 (or two) to link it all, and hire a few people to manage it all. Not cheap but certainly feasible.

I'm serious about this, they release the source code and I'll gladly sign on to commit my free time to improving their AI engine and probably a half dozen other things. For starters they're missing decent NPC companions (think real character development, not just script functions), faction level AI, and I think a custom chatter bot paired a TTS engine could handle dynamic dialog without voice acting... (even if they didn't release the source code I'd sign on if asked, have to finish Openlancer first, it will have the best AI engine seen in a game to date or I'll die trying). --MegaBurn 06:47, 22 April 2006 (EDT)

The Elder Scrolls V: WikiTamriel? Silly as it seems at first, you raise a very good point, MegaBurn. A whole heap of dedicated fans familiar with programming (of which Oblivion seems to have plenty) could generate suggestions for improving code much faster than the original coders could. I don't know enough to be certain, but I could almost see releasing the source code with no way to compile: sort of a "Look, but don't touch" thing. Then it falls to BethSoft to actually edit the code for release, but the community can point out errors or pointers for improvement. (Plus, think about how releasing source code to a game currently on the market would change the gaming industry. It'd be crazy...) The largest good-faith issue I can see (piracy being an obvious issue, but related to system abuse rather than improvement) would be the source code's complexity. It would take a dedicated team of programmers just to make sure that issues with complexity don't arise. Sounds very interesting, though. Grundulum 15:59, 22 April 2006 (EDT)

Read only source code is semi-possible. Some of the middleware source code cannot be released, Bethsoft cannot release anything they don't own. So without the middleware code a functional engine build can't be compiled. Theres nothing to prevent someone (or a team) from replacing the missing middleware with an open source package or developing one themselves. As for piracy, this would have zero effect on piracy, without the 4 gig of game data the source code or even main game executable is near useless to the average player. Releasing the source code isn't really crazy, it might be within the game industry but lots of programs ship with the source code. However m$ and some other greedy multinationals would have you believe open source is evil communism or some such. Open source is the future, nothing can it stop that now. Even m$ will give in one day and go full open source, just as soon as it costs them more to remain closed source than go open source. For Bethsoft to go open source now its just jumping on the bandwagon before most of the other major players in the game industry. Also keep in mind open source doesn't mean free, they will have to write their own license or tweak an existing one. --MegaBurn 18:54, 27 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)

I'll rewrite some of my requests, again, and use a little force with the discussion. Who ever wrote the page intro was either a sysop, dev, or both, its clearly says to keep the discussion on the this page. So there better be no complaints when I move their comments on my suggests to this page. If everyone else does the same the article length will drop, significantly. --MegaBurn 19:16, 27 April 2006 (EDT)

Justed finished with my edits. Not sure I can get it any shorter without moving comments to other people's requests. I'm really not sure if thats an issue or not, normally when stuff is signed its like saying "mine, don't touch". Someone really needs to do something with the Longer MAX_SCRIPT_SIZE! request, thats gotten way out of hand. Maybe signing these at all was a bad idea. If people can't clean up their own requests, own comments, and comments on their requests then, yeah, split it up into more topics. Or just wholesale move all discussion to this page.--MegaBurn 19:58, 27 April 2006 (EDT)

Moved Discussions

I suggest people move discussion content to this section to help reduce the overall Wish List size. The top of the Wish List clearly states that we are to keep the discussion on the discussion page. Please use subsections for each request discussion added to this section. --MegaBurn 20:19, 27 April 2006 (EDT)

Add UI Option Elements Discussion Snips

I'm moving this discussion to help clean up the Wish List.

Moved reply to Callie on Add UI Option Elements:

Or being able to create new UI windows/menus with the CS, just like creating new cells. Thats about the only major thing still missing from the CS, by adding that you could finally call the CS a full blown IDE. --MegaBurn 03:28, 13 April 2006 (EDT)

Moved replies to Maian on Add UI Option Elements:

Dropping the external XML files so everything is in the ESM/ESP would be better. Its certainly workable since it doesn't really matter where that data is stored. The strings could be moved to a global list (e.g. under Settings in the Gameplay menu) or added to the Settings as another string data list section. If they really want to get creative it could be turned into a full GUI IDE, something akin to VB. The result of that would be very cool, I can easily see someone doing a desktop mod, where if sit at a desk you get a dynamic OS style desktop (e.g. if the desk contains a quill, ink well, and parchment a UI button for scroll writing pops up, or an alchemy button if the desk contains all the required alchemy equipment). Not sure if thats possible now with on-activate/message box menu scripts, might be. --MegaBurn 01:21, 15 April 2006 (EDT)

I bet that's very unlikely to happen. They've already invested plenty into creating their menu XML dialect and interpreter. In any case, the XML format is actually pretty ideal for describing UIs, since many people are familiar with it, including web developers (like me). Not everything should go into an esp file. External resources should be put into bsa files, and the esp should somehow be able to get the game to import that bsa file. --Maian 06:49, 20 April 2006 (EDT)

This really should be moved into the talk page, but... Its not unlikely at all and would be a vast improvement. If you think I mean dropping the XML format then you misunderstood, again, I'm saying just move the UI XML data into the ESM/ESP files. Technically it should makes no different if the XML data is stored in a BSA or a ESM/ESP. Adapting the CS to include an XML editor similar to the script editor should be fairly simple, it would make the XML data more accessible to modders and forgo having to even mess with the BSA files (assuming some of the other items on this list are implemented). Generating the XML data for UI windows created in an UI editor should be fairly simple too. I'm not sure if the CS includes an XML parser or not, I'd assume it does but if not, porting the parser from the game engine over to the CS would, again, be a fairly simple task. --MegaBurn 08:42, 20 April 2006 (EDT)