19,499
edits
Talk:History of Oni modding: Difference between revisions
m
-redlinks
Script 10k (talk | contribs) mNo edit summary |
m (-redlinks) |
||
| Line 27: | Line 27: | ||
Generally, scripts tend to suffer from lack of thorough testing and insufficient knowledge of BSL. BSL's variables and functions allow for some creative scripting (Oni Menu, [[OTA]]), but in the absence of binary modding, they are limited to the resources that an original level has to offer, which are intended for the original missions and may not be suited for much else. Then again, people often script "just for fun", with little or no commitment to debugging or support, so the limitations of BSL-only modding are easily overlooked. | Generally, scripts tend to suffer from lack of thorough testing and insufficient knowledge of BSL. BSL's variables and functions allow for some creative scripting (Oni Menu, [[OTA]]), but in the absence of binary modding, they are limited to the resources that an original level has to offer, which are intended for the original missions and may not be suited for much else. Then again, people often script "just for fun", with little or no commitment to debugging or support, so the limitations of BSL-only modding are easily overlooked. | ||
For a list of the scripts produced by the community, see | For a list of the scripts produced by the community, see "Category:Scripts". | ||
==Binary modding== | ==Binary modding== | ||
Soon enough it became clear (to some of us, at least) that scripts alone would not allow us to design radically new single-player missions. Entities like [[OBD:BINA/OBJC/TRGV|trigger volumes]] or [[OBD:BINA/OBJC/CHAR|character descriptions]], for example, were originally designed and fine-tuned in parallel with the scripts. The interplay is such that modders with 100% original ideas typically have to mod the binary resources to adapt them to their scripts. The first one to have consistently done so is [[User:Loser|Loser]], with a massively reshuffled Warehouse. Loser's Warehouse mod included a global component (modified level0_Final), level-specific binary modifications, and highly custom scripts that took full advantage of the modified binaries. | Soon enough it became clear (to some of us, at least) that scripts alone would not allow us to design radically new single-player missions. Entities like [[OBD:BINA/OBJC/TRGV|trigger volumes]] or [[OBD:BINA/OBJC/CHAR|character descriptions]], for example, were originally designed and fine-tuned in parallel with the scripts. The interplay is such that modders with 100% original ideas typically have to mod the binary resources to adapt them to their scripts. The first one to have consistently done so is [[User:Loser|Loser]], with a massively reshuffled Warehouse. Loser's Warehouse mod included a global component (modified level0_Final), level-specific binary modifications, and highly custom scripts that took full advantage of the modified binaries. | ||
Minor binary modding had already occurred before Loser's Warehouse (thus, while compiling the [[OBD]] database, ssg had released a version of level0_Final in which all of Konoko's combos were unlocked). Still, it was the Warehouse mod which first showed the "full" potential of binary modding. It inspired a short-lived initiative called the [[ | Minor binary modding had already occurred before Loser's Warehouse (thus, while compiling the [[OBD]] database, ssg had released a version of level0_Final in which all of Konoko's combos were unlocked). Still, it was the Warehouse mod which first showed the "full" potential of binary modding. It inspired a short-lived initiative called the [[AE:BIP|Binary Improvement Project]], aimed at providing upgraded binaries for all levels, not just level0_Final and level1_Final. BIP was hindered by large upload/download sizes as well as by the potential legal issues and was promptly put in standby. | ||
An equally short-lived alternative to supplying whole levels was developed in the form of [[OUP]]-based patches and was termed Oni ni Kanabô. The modder would edit his DAT/RAW files in [[OUP]], and then release a single binary resource. This was both bandwidth- and legalese-friendly, but suffered from one major limitation: the indexation of DAT resources and the offsets of RAW data vary a lot across the available versions of Oni. Thus, resources exported with OUP were not truly standalone or portable. Also, OUP still lacked the feature or generating or importing new resources alongside existing ones. | An equally short-lived alternative to supplying whole levels was developed in the form of [[OUP]]-based patches and was termed Oni ni Kanabô. The modder would edit his DAT/RAW files in [[OUP]], and then release a single binary resource. This was both bandwidth- and legalese-friendly, but suffered from one major limitation: the indexation of DAT resources and the offsets of RAW data vary a lot across the available versions of Oni. Thus, resources exported with OUP were not truly standalone or portable. Also, OUP still lacked the feature or generating or importing new resources alongside existing ones. | ||