diff --git a/doc/src/advanced/Building NVGT For Linux.md b/doc/src/advanced/Building NVGT For Linux.md index d39985e7..7de81b92 100644 --- a/doc/src/advanced/Building NVGT For Linux.md +++ b/doc/src/advanced/Building NVGT For Linux.md @@ -87,7 +87,7 @@ git clone https://github.com/bulletphysics/bullet3 cd bullet3 ./build_cmake_pybullet_double.sh cd cmake_build -sudo camke --install . +sudo cmake --install . ``` ```bash diff --git a/doc/src/advanced/Debugging Scripts.md b/doc/src/advanced/Debugging Scripts.md index b77cb253..982d2a3b 100644 --- a/doc/src/advanced/Debugging Scripts.md +++ b/doc/src/advanced/Debugging Scripts.md @@ -9,11 +9,11 @@ There is a command line argument you must pass to nvgt.exe along with the script So for example, open a command prompt or terminal and change directory to the place where you have stored your game. You could then run, for example, `nvgt -d mygame.nvgt` assuming a correct installation of nvgt, which would cause mygame.nvgt to be launched with the Angelscript debugger getting initialized. ## the debugging interpreter -When you run a script with the debugger, it will not start immedietly. Instead, you will be informed that debugging is in progress, that the system is waiting for commands, and that you can type h for help. +When you run a script with the debugger, it will not start immediately. Instead, you will be informed that debugging is in progress, that the system is waiting for commands, and that you can type h for help. If the last line on your terminal is \[dbg\]\> , you can be sure that the system is waiting for a debug command. -If you press enter here without first typing a command, the last major debugger action is repeated. This is not nesessarily the last command you have typed, but is instead the last major action (continue, step into, step over, step out). The default action is to continue, meaning that unless you have changed the debugger action, pressing enter without typing a command will simply cause the execution of your script to either begin or resume where it left off. +If you press enter here without first typing a command, the last major debugger action is repeated. This is not necessarily the last command you have typed, but is instead the last major action (continue, step into, step over, step out). The default action is to continue, meaning that unless you have changed the debugger action, pressing enter without typing a command will simply cause the execution of your script to either begin or resume where it left off. Pressing ctrl+c while the debug interpreter is open will exit out of nvgt completely similar to how it works if the debugger is not attached. Pressing this keystroke while the interpreter is not active will perform a user break into the debugger, meaning that your script will immediately stop executing and the debug interpreter will appear. @@ -31,11 +31,11 @@ To list all available commands, type h and enter. We won't talk about all of the * a: abort execution (more graceful version of ctrl+c) ## registered debugging functions -If you are working with a troublesome bit of code, you may find that breaking into the debugger at a specific point is a very helpful thing to do. For this situation, NVGT has the debug_break() function. +If you are working with a troublesome bit of code, you may find that breaking into the debugger at a specific point is a very helpful thing to do. For this situation, NVGT has the `debug_break()` function. This function will do nothing if called without a debugger attached or from a compiled binary, so it is OK to leave some calls to this around in your application so long as you are aware of them for when you run your script with the debugger. This function will immediately halt the execution of your script and cause the debugger interpreter to appear. -You can also programatically add file and function breakpoints with the functions void debug_add_file_breakpoint(string filename, int line_number) and void debug_add_func_breakpoint(string function_name). +You can also programmatically add file and function breakpoints with the functions `void debug_add_file_breakpoint(string filename, int line_number)` and `void debug_add_func_breakpoint(string function_name)`. ## breakpoints To describe breakpoints, we'll break (pun intended) the word into it's 2 parts and describe what the words mean in this context. diff --git a/doc/src/advanced/Plugin Creation.md b/doc/src/advanced/Plugin Creation.md index 0b2dc20c..3ebabf62 100644 --- a/doc/src/advanced/Plugin Creation.md +++ b/doc/src/advanced/Plugin Creation.md @@ -45,7 +45,7 @@ We shall forgo any general comments or teaching about the c++ language itself he The first thing that you probably noticed was this include directive which includes "../../src/nvgt_plugin.h". Why there? While this will be described later, the gist is that NVGT's build setup already has some infrastructure set up to build plugins. NVGT's github repository has a plugin folder, and in there are folders for each plugin. This example is using such a structure. We will talk more in detail about this later, but for now it is enough to know that nvgt_plugin.h does not include anything else in nvgt's source tree, and can be safely copy pasted where ever you feel is best for your particular project (though we do recommend building plugins with NVGT's workspace). -The next oddity here, why doesn't the plugin_main function declaration include a return type? This is because it is a macro defined in nvgt_plugin.h. It is required because the name of the entry point will internally changed based on whether you are compiling your plugin statically or dynamically. If you are building your plugin as a shared library, the function that ends up exporting is called nvgt_plugin. However since one of course cannot link 2 static libraries with the same symbol names in each to a final executable, the entry point for a static plugin ends up being called nvgt_plugin_\ where \ is replaced with the value of the NVGT_PLUGIN_STATIC preprocessor define (set at plugin build time). In the future even dynamic libraries may possibly contain the plugin name in their entry point function signatures such that more than one plugin could be loaded from one dll file, but for now we instead recommend simply registering functions from multiple plugins in one common entry point if you really want to do that. +The next oddity here, why doesn't the plugin_main function declaration include a return type? This is because it is a macro defined in nvgt_plugin.h. It is required because the name of the entry point will internally change based on whether you are compiling your plugin statically or dynamically. If you are building your plugin as a shared library, the function that ends up exporting is called nvgt_plugin. However since one of course cannot link 2 static libraries with the same symbol names in each to a final executable, the entry point for a static plugin ends up being called nvgt_plugin_\ where \ is replaced with the value of the NVGT_PLUGIN_STATIC preprocessor define (set at plugin build time). In the future even dynamic libraries may possibly contain the plugin name in their entry point function signatures such that more than one plugin could be loaded from one dll file, but for now we instead recommend simply registering functions from multiple plugins in one common entry point if you really want to do that. Finally, remember to call prepare_plugin(shared) as the first thing in your plugin, and note that if your entry point does not return true, this indicates an error condition and your plugin is not loaded. @@ -53,11 +53,11 @@ Finally, remember to call prepare_plugin(shared) as the first thing in your plug As mentioned a couple of times above, NVGT's official repository already contains the infrastructure required to build plugins and integrate them with NVGT's existing build system, complete with the ability to exclude some of your more private plugins from being picked up by the repository. While it is not required that one use this setup and in fact one may not want to if they have a better workspace set up for themselves, we certainly recommend it especially if you are making a plugin that you may want to share with the NVGT community. ### The plugin directory -In nvgt's main repository, the plugin directory contains all publically available plugins. Either if you have downloaded NVGT's repository outside of version control (such as a public release artifact) or if you intend to contribute your plugin to the community by submitting a pull request, you can feel free to use this directory as well. +In nvgt's main repository, the plugin directory contains all publicly available plugins. Either if you have downloaded NVGT's repository outside of version control (such as a public release artifact) or if you intend to contribute your plugin to the community by submitting a pull request, you can feel free to use this directory as well. Here, each directory is typically one plugin. It is not required that this be the case, other directories that are not plugins can also exist here, however any directory within the plugin folder that contains a file called _SConscript will automatically be considered as a plugin by the SConstruct script that builds NVGT. -The source code in these plugins can be aranged any way you like, as it is the _SConscript file you provide that instructs the system how to build your plugin. +The source code in these plugins can be arranged any way you like, as it is the _SConscript file you provide that instructs the system how to build your plugin. An example _SConscript file for such a plugin might look like this: ``` @@ -68,7 +68,7 @@ Import("env") if ARGUMENTS.get("no_shared_plugins", "0") == "0": env.SharedLibrary("#release/lib/test_plugin", ["test.cpp"], libs = ["user32"]) -# If we want to make a static version along side our shared one, we need to specifically rebuild the object file containing the plugin's entry point with a different name so that SCons can maintain a proper dependancy graph. Note the NVGT_PLUGIN_STATIC define. +# If we want to make a static version along side our shared one, we need to specifically rebuild the object file containing the plugin's entry point with a different name so that SCons can maintain a proper dependency graph. Note the NVGT_PLUGIN_STATIC define. static = env.Object("test_plugin_static", "test.cpp", CPPDEFINES = [("NVGT_PLUGIN_STATIC", "test_plugin")]) # now actually build the static library, reusing the same variable from above for fewer declarations. static = env.StaticLibrary("#build/lib/test_plugin", [static]) @@ -76,7 +76,7 @@ static = env.StaticLibrary("#build/lib/test_plugin", [static]) # Tell NVGT's SConstruct script that the static version of this plugin needs symbols from the user32 library. static = [static, "user32"] -# What is being returned to NVGT's SConstruct in the end is a list of aditional static library objects that should be linked. +# What is being returned to NVGT's SConstruct in the end is a list of additional static library objects that should be linked. Return("static") ``` @@ -91,10 +91,10 @@ Second, if a _SConscript file is present in this directory, NVGT's main build sc Last but not least, if a file called nvgt_config.h is present in the user folder, this will also be loaded in place of the nvgt_config.h in the repo's src directory. -You can do whatever you want within this user directory, choosing to either follow or ignore any convensions you wish. Below is an example of a working setup that employs the user directory, but keep in mind that you can set up your user directory any way you wish and don't nesessarily have to follow the example exactly. +You can do whatever you want within this user directory, choosing to either follow or ignore any conventions you wish. Below is an example of a working setup that employs the user directory, but keep in mind that you can set up your user directory any way you wish and don't necessarily have to follow the example exactly. #### user directory example -The following setup is used for Survive the Wild development. That game requires a couple of propriatary plugins to work, such as a private encryption layer. +The following setup is used for Survive the Wild development. That game requires a couple of proprietary plugins to work, such as a private encryption layer. In this case, what was set up was a second github repository that exists within the user directory. It's not a good idea to make a github repository out of the root user folder itself because git will not appreciate this, but instead a folder should be created within the user directory that could contain a subrepository. We'll call it nvgt_user. @@ -155,7 +155,7 @@ If you are only building plugins for projects that are intended to run on one pl There are a couple of things that should be considered when creating plugins intended to run on all platforms, but only one really big one. In short, it is important that a cross platform plugin's registered Angelscript interface looks exactly the same on all platforms, even if your plugin doesn't support some functionality on one platform. For example if your plugin has functions foo and bar but the bar function only works on windows, it is important to register an empty bar function for any non-windows builds of your plugin rather than excluding the bar function from the angelscript registration of such a plugin build entirely. This is especially true if you intend to, for example, cross compile your application with the windows version of NVGT to run on a linux platform. -The reasoning is that Angelscript may sometimes store indexes or offsets to internal functions or engine registrations in compiled bytecode rather than the names of them. This makes sense and allows for much smaller/faster compiled programs, but what it does mean is that NVGT's registered interface must appear exactly the same both when compiling and when running a script. Maybe your plugin with foo and bar functions get registered into the engine as functions 500 and 501, then maybe the user loads a plugin after that with boo and bas functions that get registered as functions 502 and 503. Say the user makes a call to the bas function at index 503. Well, if the foo bar plugin doesn't include a bar function on linux builds of it, now we can compile the script on windows and observe that the function call to bas at index 503 is successful. But if I run that compiled code on linux, since the bar function is not registered (as it only works on windows), the bas function is now at index 502 instead of 503 where the bytecode is instructing the program to call a function. Oh no, program panick, invalid bytecode! The solution is to instead register an empty version of the bar function on non-windows builds of such a plugin that does nothing. +The reasoning is that Angelscript may sometimes store indexes or offsets to internal functions or engine registrations in compiled bytecode rather than the names of them. This makes sense and allows for much smaller/faster compiled programs, but what it does mean is that NVGT's registered interface must appear exactly the same both when compiling and when running a script. Maybe your plugin with foo and bar functions get registered into the engine as functions 500 and 501, then maybe the user loads a plugin after that with boo and bas functions that get registered as functions 502 and 503. Say the user makes a call to the bas function at index 503. Well, if the foo bar plugin doesn't include a bar function on linux builds of it, now we can compile the script on windows and observe that the function call to bas at index 503 is successful. But if I run that compiled code on linux, since the bar function is not registered (as it only works on windows), the bas function is now at index 502 instead of 503 where the bytecode is instructing the program to call a function. Oh no, program panic, invalid bytecode! The solution is to instead register an empty version of the bar function on non-windows builds of such a plugin that does nothing. ## Angelscript registration Hopefully this document has helped you gather the knowledge required to start making some great plugins! The last pressing question we'll end with is "how does one register things with NVGT's Angelscript engine?" The angelscript engine is a variable in the nvgt_plugin_shared structure passed to your plugins entry point, it's called script_engine. @@ -166,4 +166,4 @@ The best reference for how to register things with Angelscript is the Angelscrip * [registering global properties](https://www.angelcode.com/angelscript/sdk/docs/manual/doc_register_prop.html) * [registering an object type](https://www.angelcode.com/angelscript/sdk/docs/manual/doc_register_type.html) -Good luck creating NVGT plugins, and feel free to share some of them to the community if you deam them worthy! +Good luck creating NVGT plugins, and feel free to share some of them to the community if you deem them worthy! diff --git a/doc/src/advanced/docgen+.md b/doc/src/advanced/docgen+.md index 449f5880..cfa02d1a 100644 --- a/doc/src/advanced/docgen+.md +++ b/doc/src/advanced/docgen+.md @@ -5,13 +5,13 @@ * topics may be in .md or .nvgt format at this time. When NVGT becomes a c++ library as well, we may add ability to perform basic parsing of .h files. * Directories are subsections and can be nested. * Sections and subsections, starting at NVGTRepoRoot/doc/src, are scanned for topics with the following rules in mind: - * If a .index.json file exists, this file is loaded and parsed to create the topic list. The json is a list containing either strings or 2-element lists. If a string, just indicates a topic filename. If a list, the first element is a topic filename string and the second is a topic display name string if the topic filename isn't adiquit. + * If a .index.json file exists, this file is loaded and parsed to create the topic list. The json is a list containing either strings or 2-element lists. If a string, just indicates a topic filename. If a list, the first element is a topic filename string and the second is a topic display name string if the topic filename isn't adequate. * If a .index.json file does not exist, topics/subsections are loaded in alphabetical order. A topic C will appear before a subsection F. * Unless a .index.json file specifies a topic display name, the topic filename minus the extension is used as the topic name. Punctuation characters at the beginning of the display name are removed to provide for more flexible sorting. A subsection !C will show before a subsection F, but !C will display C thus allowing for multiple sorting levels without a .index.json file. * If there is a .MDRoot file present in a directory, the contents of that directory are output in new markdown/html documents instead of being appended to the main/parent documents, and a link to the new document is appended to the parent one. * If a topic filename contains an @ character right before the extension, that document is treated as a new markdown root document in the final output instead of being appended to the main/parent document, this is just a way to invoque the same as above but for a single file. * If a topic filename contains a + before the extension, the first line in the file minus markdown heading indicators will be used as the topic display name instead of a titlecased topic filename. -* .nvgt files contain embedded markdown within comments. Most markdown sintax is the same, accept that nvgt's docgen script replaces single line breaks with double lines so that each line is a markdown paragraph. Start a docgen comment with /**, and start a docgen comment with the above mentioned linefeed behavior disabled with /**\. +* .nvgt files contain embedded markdown within comments. Most markdown syntax is the same, except that nvgt's docgen script replaces single line breaks with double lines so that each line is a markdown paragraph. Start a docgen comment with /**, and start a docgen comment with the above mentioned linefeed behavior disabled with /**\. * Another embedded markdown comment within .nvgt files is the "// example:" comment, which will be replaced with "## example" in markdown. * When parsing a .nvgt file, a "# topicname" markdown directive is added to the top of the output to avoid this redundant step in example functions. * The docgen program creates a .chm file which requires parsing this markdown into html, and there may be reasons for removing embedded markdown indentation anyway. This resulted in an indentation rule where tabs are stripped from the document when passed to the python markdown package, spaces are not and can be used for things like nested lists. diff --git a/doc/src/appendix/!To do.md b/doc/src/appendix/!To do.md index 1596b006..8bc1489b 100644 --- a/doc/src/appendix/!To do.md +++ b/doc/src/appendix/!To do.md @@ -14,10 +14,10 @@ The joystick class in NVGT is still a no-op interface. There has already been a Another object from BGT we have not yet reimplemented, we are considering [tonic](https://github.com/TonicAudio/Tonic) for this but are very open to other suggestions as not much research as been done yet here. ### AVSpeech and speech dispatcher -Currently other than voice over support, the only speech output NVGT can produce on Linux and MacOS is based on a verry bad sounding RSynth derivative that is included as a fallback synthesizer intended to be used in an emergency situation where the user needs to know that their primary synth failed to load. We intend to wrap AVSpeechSynthesizer on MacOS and speechd on Linux to solve this problem. +Currently other than voice over support, the only speech output NVGT can produce on Linux and MacOS is based on a very bad sounding RSynth derivative that is included as a fallback synthesizer intended to be used in an emergency situation where the user needs to know that their primary synth failed to load. We intend to wrap AVSpeechSynthesizer on MacOS and speechd on Linux to solve this problem. ### VSCode extension -A plan that has existed for a few months now is to create a VSCode extension for Angelscript that works with NVGT scripts. To facilitate this we have wrapped a function called script_dump_engine_configuration, an example of which you can see in test/quick/dump_engine_config.nvgt. This function dumps a complete reference of everything registred in the engine, enough to compile scripts. This will, once time permits to learn the needed components, allow us to create an extennsion for VSCode that allows everything from symbol lookup to intellisense. +A plan that has existed for a few months now is to create a VSCode extension for Angelscript that works with NVGT scripts. To facilitate this we have wrapped a function called script_dump_engine_configuration, an example of which you can see in test/quick/dump_engine_config.nvgt. This function dumps a complete reference of everything registered in the engine, enough to compile scripts. This will, once time permits to learn the needed components, allow us to create an extension for VSCode that allows everything from symbol lookup to intellisense. ### JAWS keyhook Anyone who has been playing Survive the Wild for any period of time and who uses JAWS is no doubt aware that the keyhook in Survive the Wild is currently less than ideal. There is ongoing work to fix it, but this is not yet complete. @@ -30,7 +30,7 @@ At the moment, we are using SDL's message box system to show simple dialogs rath Either we will see if SDL will improve message boxes soon, or switch to something else. ### Switch to miniaudio -Currently we use the Bass audio library for sound output, which functionally speaking does work great. However Bass is not open source, and a comercial license must be purchased from [Un4seen](https://www.un4seen.com/bass.html) in order to sell comercial projects. For NVGT, this is not ideal and Bass was only used because it worked quite well at the time that NVGT was only being used to bolster Survive the Wild development with no opensource intentions. Instead, we plan to switch to [miniaudio](https://github.com/mackron/miniaudio) which is open source and in the public domain, and thus which will solve such comercial licensing issues. +Currently we use the Bass audio library for sound output, which functionally speaking does work great. However Bass is not open source, and a commercial license must be purchased from [Un4seen](https://www.un4seen.com/bass.html) in order to sell commercial projects. For NVGT, this is not ideal and Bass was only used because it worked quite well at the time that NVGT was only being used to bolster Survive the Wild development with no opensource intentions. Instead, we plan to switch to [miniaudio](https://github.com/mackron/miniaudio) which is open source and in the public domain, and thus which will solve such commercial licensing issues. ### Consider access permissions for subscripting NVGT allows a scripter to execute Angelscript code from within their Angelscript code, such as the python eval function. The user is given control of what builtin NVGT functions and classes these subscripts have access to, but it's still a bit rough. Basically Angelscript provides us with this 32 bit DWORD where we can map certain registered functions to bitflags and restrict access to them if a calling module's access bitmask doesn't include a flag the functions were registered with. However this means that we have 32 systems or switches to choose from, so either we need to assign builtin systems to them in a better way, or investigate this feature Angelscript has which is known as config groups and see if we can use them for permission control. C++ plugins in particular complicate this issue. @@ -61,4 +61,4 @@ Along the same line, partly due to initial closed source intentions and also par Currently we are using parts of an apache2 licensed library for system fingerprint generation. Not only is it a bit rough but it also uses several architecture specific assembly instructions at times when we probably don't need any. We should rewrite this to use our own system instead comprised of calls into Poco, SDL and other libraries that can return various bits of system information, or at the very least find a solid tiny dependency that can handle it for us. ### SDL3 upgrade -At some point we do indeed intend to upgrade to SDL3 instead of sticking with SDL2. The priority of this task is somewhat unknown and at least partially revolves around making sure SDL3 is easy to aquire/build/install on all the platforms we're interested in using it on. So long as we manually build one of the prereleases, we're probably OK though it would be nice to wait until it shows up on brew, apt and other package managers. +At some point we do indeed intend to upgrade to SDL3 instead of sticking with SDL2. The priority of this task is somewhat unknown and at least partially revolves around making sure SDL3 is easy to acquire/build/install on all the platforms we're interested in using it on. So long as we manually build one of the prereleases, we're probably OK though it would be nice to wait until it shows up on brew, apt and other package managers. diff --git a/doc/src/appendix/Changelog.md b/doc/src/appendix/Changelog.md index e5a30ca1..5d321dd3 100644 --- a/doc/src/appendix/Changelog.md +++ b/doc/src/appendix/Changelog.md @@ -26,14 +26,14 @@ This document lists all major changes that have taken place in NVGT since we sta * Add support for speech dispatcher on Linux and other BSD systems! * You can now use the directive `#pragma embed packname.dat` as an alternative to `#including` your pack files. * Fix broken quoted strings when handling pragma directives, resolving issues with the `#pragma include` option. -* Mostly finishes making it possible to configure various Angelscript engine properties as well as other NVGT options using configuration files, jjust needs pollishing. +* Mostly finishes making it possible to configure various Angelscript engine properties as well as other NVGT options using configuration files, just needs polishing. * bgt_compat's string_to_number function now trims whitespace to comply with bgt's standard, our new faster parse_float doesn't do that anymore in the name of performance. * Fix issues with sound::push_memory(): * actual audio files can be pushed to the function without modifying any other arguments other than the data string. * Calling sound.load() with a blank filename is no longer required before push_memory functions. -* Some pollishing to the Angelscript integration: +* Some polishing to the Angelscript integration: * If a global variable fails to initialize, the exception that caused it is now properly shown in the compilation error dialog. - * There should hoefully be no more cases where a compilation error dialog can show up after a script executes successfully and throws an exception. Instead if the user enables the warnings display, they should properly see warnings before the script executes. + * There should hopefully be no more cases where a compilation error dialog can show up after a script executes successfully and throws an exception. Instead if the user enables the warnings display, they should properly see warnings before the script executes. * Set up the infrastructure to be able to store a bit of extra encrypted information along side the bytecode payload in compiled programs, for now using that to more securely store the list of enabled plugins as well as the serialized Angelscript properties. * Scripts no longer compile if they do not contain a valid entry point. * Updated to the latest Angelscript WIP code which resolves a bytecode load error that had been reported. @@ -92,12 +92,12 @@ This document lists all major changes that have taken place in NVGT since we sta * This also introduces the change that on windows, there is now nvgt.exe and nvgtw.exe that gets built, one with the windows subsystem and one without. * Script files and nvgt's binary will check for config files with the basename of file + .ini, .properties, or .json. * The above changes mean that we now implement the Angelscript debugger since the nvgt compiler is now always available in console mode. -* NVGT now uses simantic versioning, for example 0.85.0. +* NVGT now uses symantic versioning, for example 0.85.0. * Fixed script return code. * NVGT finally has a cross-platform installer (NSIS on Windows and a .dmg file on macOS). * The timer class once present in `bgt_compat.nvgt` is finally in the core of the engine! * it is now possible to embed packs into executables! -* The way Windows binaries load has been changed, meaning that UPX or any other binary compresser that supports overlays can now be used on your compiled NVGT binaries! +* The way Windows binaries load has been changed, meaning that UPX or any other binary compressor that supports overlays can now be used on your compiled NVGT binaries! * The timer resolution should be much more accurate on Windows. * Added a new, optional `uint timeout` parameter to the `network.request()` method. * Improved documentation. @@ -121,7 +121,7 @@ This document lists all major changes that have taken place in NVGT since we sta * The var type now has PostEnc and PostDec operators. * UTF8 fixes: sound.load, and compiled applications can now execute if they contain non-english characters in their filenames. * All code that I wish to share has been forked into what will hopefully be nvgt's long-standing repository which will eventually have it's privacy status switched to public! -* NVGT now has a build system! I know it's not the fastest one around, but needing a middleground between learning even more new things and using what I already know, I chose SCons purely because of the fermiliar pythonic environment and not needing to learn yet another new set of syntax rules. I'm just glad we're no longer building the engine using a series of shell scripts! +* NVGT now has a build system! I know it's not the fastest one around, but needing a middle ground between learning even more new things and using what I already know, I chose SCons purely because of the familiar pythonic environment and not needing to learn yet another new set of syntax rules. I'm just glad we're no longer building the engine using a series of shell scripts! * Added basic steam audio reverb integration! It needs a lot of work and is far from being production ready (seriously this could slow your game to a crawl until I'm done with this), but nevertheless it is still around for testing! ## New leading up to 02/20/2024: @@ -134,7 +134,7 @@ This document lists all major changes that have taken place in NVGT since we sta * Remove sound_environment class for now. * Should load bassflac.dll and bassopus.dll if present * JSON Support. -* Better multithreading support with more primatives. +* Better multithreading support with more primitives. * More functions in the string class. * New methods of operating system detection. * Instance class removed from engine and replaced with include/instance.nvgt which wraps a named_mutex. @@ -143,7 +143,7 @@ This document lists all major changes that have taken place in NVGT since we sta * Other misc changes. ## Note for changes before 01/06/2024: -Changes were roughly untracked before this time, but there is a rather large list of somewhat sorted changes below as commited to nvgt_bin (a repository where the NVGT testers could access and test NVGT). These are sorted by month where possible to make them easier to sort, but keep in mind that commits to nvgt_bin usually occurred all at once so that building NVGT was easier for all platforms. As such, expect these lists (while somewhat sorted) to become rather large! Additionally, some of these changes may be ambiguous due to being based off of nvgt_bin's commit messages only. At this time, it was assumed anyone using this engine had direct contact with Sam to ask questions. +Changes were roughly untracked before this time, but there is a rather large list of somewhat sorted changes below as committed to nvgt_bin (a repository where the NVGT testers could access and test NVGT). These are sorted by month where possible to make them easier to sort, but keep in mind that commits to nvgt_bin usually occurred all at once so that building NVGT was easier for all platforms. As such, expect these lists (while somewhat sorted) to become rather large! Additionally, some of these changes may be ambiguous due to being based off of nvgt_bin's commit messages only. At this time, it was assumed anyone using this engine had direct contact with Sam to ask questions. ## New as of 12/10/2023: * Using more poco libraries including basic json implementation. @@ -177,7 +177,7 @@ Changes were roughly untracked before this time, but there is a rather large lis * New system information functions for custom system fingerprint or error tracking. * Improvements to coordinate_map. * Subscripting can now compile to bytecode. -* Fixed vector devision scaling operators. +* Fixed vector division scaling operators. * Improved reliability of timer queue. * Many more minor bugfixes. diff --git a/doc/src/manual/-BGT Upgrading+.md b/doc/src/manual/-BGT Upgrading+.md index 16b0e800..8327c884 100644 --- a/doc/src/manual/-BGT Upgrading+.md +++ b/doc/src/manual/-BGT Upgrading+.md @@ -1,14 +1,14 @@ # Upgrading From BGT Since for a while this is where most people who have heard of NVGT will likely start, we will begin by describing the relationship between NVGT and BGT, and more importantly the steps required to upgrade a BGT project to an NVGT one. If you have not heard of BGT or are completely new to game development and are wondering how NVGT can help you, you can probably skip this and move to the fresh start topic. -BGT stands for the Blastbay Gaming Toolkit, and is what initially enspired NVGT to be created after BGT was made into abandonware. +BGT stands for the Blastbay Gaming Toolkit, and is what initially inspired NVGT to be created after BGT was made into abandonware. It is important to note that NVGT is not officially endorsed by BGT's developers and contributors, and NVGT is not in any way derived from BGT's source code. The only shared assets between NVGT and BGT are some of BGT's include files such as the audio_form and sound_pool used by many bgt games, which are released under a zlib license. -our goal is to make the transission as seemless as possible from BGT to NVGT, but here are some things you should know when porting an existing BGT game. +our goal is to make the transition as seamless as possible from BGT to NVGT, but here are some things you should know when porting an existing BGT game. * Always `#include "bgt_compat.nvgt"` as this includes a lot of aliases to other functions. Using built-in functions may improve performance so this is more or less a stop-gap to get you up and running quickly; however if you wish for your code to just run, bgt_compat will certainly be of use. -* When refering to an array's length, pass length as a method call and not as a property. ,For example, you would use `array.length();` rather than `a.length;`. +* When referring to an array's length, pass length as a method call and not as a property. ,For example, you would use `array.length();` rather than `a.length;`. * The `sound::stream()` method does exist in NVGT, but it's simply an alias to `sound::load()`. For this reason it is recommended that you change all your `stream()` calls to `load()` instead. The load function performs an efficient combination of streaming and preloading by default. * load() contains a second optional argument to pass a pack file. set_sound_storage() is no longer used for the moment. However, you can set sound_pool.pack_file to a pack handle to get a similar effect. * Take care to check any method calls using the tts_voice object as a few methods such as set_voice have changed from their BGT counterparts. diff --git a/doc/src/manual/-Game Development Tutorial.md b/doc/src/manual/-Game Development Tutorial.md index 8730d754..eeecb5aa 100644 --- a/doc/src/manual/-Game Development Tutorial.md +++ b/doc/src/manual/-Game Development Tutorial.md @@ -153,7 +153,7 @@ Here is a full code example, which you can copy into an nvgt script and run. ``` #include "speech.nvgt" void main(){ - speak("Hello from the NVGTT speech include!"); + speak("Hello from the NVGT speech include!"); } ``` @@ -346,7 +346,7 @@ Let's see how it works: string sentence = "The quick brown fox"; message += " jumps over the lazy dog"; ``` -To give you some familiarity with string concatenation, let's go over a fulle example. Copy this into an NVGT script, and run it: +To give you some familiarity with string concatenation, let's go over a full example. Copy this into an NVGT script, and run it: ``` #include "speech.nvgt" void main(){ @@ -407,7 +407,7 @@ Let's write some code to demonstrate: ``` #include "speech.nvgt" void main(){ - speak("Welcome to the camping store! You need to have 30 dollars to buy a folding chairr."); + speak("Welcome to the camping store! You need to have 30 dollars to buy a folding chair."); } ``` diff --git a/doc/src/manual/-Toolkit Configuration.md b/doc/src/manual/-Toolkit Configuration.md index 8d52dd64..64d65089 100644 --- a/doc/src/manual/-Toolkit Configuration.md +++ b/doc/src/manual/-Toolkit Configuration.md @@ -4,17 +4,17 @@ One highly useful aspect of NVGT is it's ever growing list of ways that an end u From `#pragma` directives to command line argument syntax to configuration files, this document attempts to keep track of all such available configuration options NVGT has to offer. ## Command line arguments -NVGT's compiler program has a variety of command line arguments you can pass to it which can alter it's behavior. Some of these options can also be set in configuration files, however an explicit command line option is very likely to override any contridictory options that are in a configuration file. +NVGT's compiler program has a variety of command line arguments you can pass to it which can alter it's behavior. Some of these options can also be set in configuration files, however an explicit command line option is very likely to override any contradictory options that are in a configuration file. Generally, these command line options are self-documenting. If you open a command prompt or terminal and just run the nvgt application directly with no arguments, you will be informed that you should either provide an input file or run `nvgt --help` for usage instructions. You can also actually just run nvgt -h In almost all cases, command line arguments have 2 methods of invocation, both a short form and a long form. The short form of a command usually consists of just a letter or two and is easier to type, while the long form of a command is always more descriptive and thus might be suited to an automation script where you want anyone reading such a script to be able to understand exactly what they are asking NVGT to do. What form you wish to use is completely up to you. In either case you should put a space between arguments, and mixing short and long form arguments is completely fine. -The short form of an argument always begins with a single hifen character (-) followed by one or 2 letters. For example, `-C` would tell NVGT to compile your script with debug information. Some arguments take values, in which case the value shall follow directly after the argument when using short form invocations. For example you could set the platform to compile with using the `-pwindows` argument. +The short form of an argument always begins with a single hyphen character (-) followed by one or 2 letters. For example, `-C` would tell NVGT to compile your script with debug information. Some arguments take values, in which case the value shall follow directly after the argument when using short form invocations. For example you could set the platform to compile with using the `-pwindows` argument. -On the other hand, the long form of an argument begins with two hifens followed by what usually amounts to a few words separated by hifens. Usually it's just one or 2 words, but could be more in rare cases. For example, `--compile-debug` would tell NVGT to compile the given script with debug information. If an option takes an argument, you use an equals (=) character to define such a value. For example `--platform=windows` would tell NVGT to compile a script for the windows platform. +On the other hand, the long form of an argument begins with two hyphens followed by what usually amounts to a few words separated by hyphens. Usually it's just one or 2 words, but could be more in rare cases. For example, `--compile-debug` would tell NVGT to compile the given script with debug information. If an option takes an argument, you use an equals (=) character to define such a value. For example `--platform=windows` would tell NVGT to compile a script for the windows platform. -Finally, a special argument, two hifens without any following text, indicates that any further arguments should be passed onto the nvgt script that is about to run. +Finally, a special argument, two hyphens without any following text, indicates that any further arguments should be passed onto the nvgt script that is about to run. ### Argument list The following is a list of all available command line arguments, though note that it is best to directly run `nvgt --help` yourself encase this list is in any way out of date as nvgt's --help argument will always be more accurate because the text it prints is dynamically generated. @@ -25,15 +25,15 @@ The following is a list of all available command line arguments, though note tha * -Q, --QUIET: do not output anything (work in progress), error status must be determined by process exit code (intended for automation) * -d, --debug: run with the Angelscript debugger * -wlevel, --warnings=level: select how script warnings should be handled (0 ignore (default), 1 print, 2 treat as error) -* -iscript, --include=script: include an aditional script similar to the #include directive -* -Idirectory, --include-directory=directory: add an aditional directory to the search path for included scripts +* -iscript, --include=script: include an additional script similar to the #include directive +* -Idirectory, --include-directory=directory: add an additional directory to the search path for included scripts * -V, --version: print version information and exit * -h, --help: display available command line options ## Configuration files Both because command line arguments can become exhausting to type for every script execution for a while and because NVGT contains far too many configuration options to make command line arguments out of, NVGT also supports configuration files which can be used either on a global or a project level to further direct NVGT. -Configuration files can either be in ini, json or properties formats and are loaded from multiple locations. Values in these configuration files are usually separated into sections in some form, for example settings controling the user interface typically go in the application subsection while directives that provide control over Angelscript's engine properties are in a subsection called scripting. The way these directives in various subsections are defined depends on the configuration format you choose, however you can use any combination of configuration formats at once to suit your needs. Though all supported configuration formats are more or less standard, you can find examples of and notes on each format below. +Configuration files can either be in ini, json or properties formats and are loaded from multiple locations. Values in these configuration files are usually separated into sections in some form, for example settings controlling the user interface typically go in the application subsection while directives that provide control over Angelscript's engine properties are in a subsection called scripting. The way these directives in various subsections are defined depends on the configuration format you choose, however you can use any combination of configuration formats at once to suit your needs. Though all supported configuration formats are more or less standard, you can find examples of and notes on each format below. Configuration files at any given location have a priority attached to them to resolve directive conflicts. For example if a global configuration file and a project configuration file both contain the same option, the project file takes priority. @@ -45,7 +45,7 @@ The following configuration files are loaded listed in order of priority from lo * script_basename.ini, script_basename.json or script_basename.properties in the same directory as the nvgt script about to be run, where script_basename is the name of the nvgt script without an extension (mygame.nvgt = mygame.properties) ### Supported configuration formats -NVGT supports 3 widely standard configuration formats, all of which have their own advantages and disadvantages. It is perfectly acceptable to create mmultiple configuration files with the same name but with different extension, all keys from all files will load and be combined. If the files nvgt.json and nvgt.ini both exist and both set the same key to a different value, however, the result is a bit less defined as to what key is actually used and typically depends on what file was internally loaded first by the engine. +NVGT supports 3 widely standard configuration formats, all of which have their own advantages and disadvantages. It is perfectly acceptable to create multiple configuration files with the same name but with different extension, all keys from all files will load and be combined. If the files nvgt.json and nvgt.ini both exist and both set the same key to a different value, however, the result is a bit less defined as to what key is actually used and typically depends on what file was internally loaded first by the engine. It is entirely up to you what formats you want to use in your projects. @@ -122,11 +122,11 @@ For more information on these properties, the [Angelscript custom options docume * alter_syntax_named_args = integer default 2: control the syntax for passing named arguments to functions (0 only colon, 1 warn if using equals, 2 colon and equals) * always_impl_default_construct: create default constructors for all script classes even if none are defined for one * compiler_warnings = integer default 0: control how Angelscript warnings should be treated same as -w argument (0 discard, 1 print and continue, 2 treat as error) -* do_not_optimize_bytecode: disable bytecode optomizations (for debugging) +* do_not_optimize_bytecode: disable bytecode optimizations (for debugging) * disallow_empty_list_elements: disallow empty items in list initializers such as {1,2,,3,4} * disallow_global_vars: disable global variable support completely * disallow_value_assign_for_ref_type: disable value assignment operators on reference types -* disable_integer_division: Defer to floatingpoint devision internally even when only integer variables are involved +* disable_integer_division: Defer to floatingpoint division internally even when only integer variables are involved * expand_default_array_to_template: cause compilation messages which would otherwise contain something like string\[\] to instead contain array\ * heredoc_trim_mode = integer default 1: decide when to trim whitespace of heredoc strings (0 never, 1 if multiple lines, 2 always) * ignore_duplicate_shared_interface: allow shared interfaced with the same name to be declared multiple times @@ -158,7 +158,7 @@ The syntax for a pragma directive looks like `#pragma name value` or sometimes j * `#pragma console`: produce the compiled executable on windows using the console subsystem for CLI based programs ## Remarks on complex options -This section contains any explinations of topics that were too bulky to fit in the documentation of each specific configuration option or article section. +This section contains any explanations of topics that were too bulky to fit in the documentation of each specific configuration option or article section. ### application.compilation_message_template This useful option allows you to control the format that errors and warnings are printed in. The default template looks like this, for example: diff --git a/doc/src/manual/Concurrency Tutorial.md b/doc/src/manual/Concurrency Tutorial.md index 4b9aa96c..c08b04b7 100644 --- a/doc/src/manual/Concurrency Tutorial.md +++ b/doc/src/manual/Concurrency Tutorial.md @@ -12,7 +12,7 @@ While NVGT does not support parallelism as one might use it in other programming ## Why is this so important? -By far, the eseiest way to program is by sticking to synchronous execution, which is what happens by default unless any concurrency is specifically introduced by the programmer. Synchronous execution means that each statement in your code runs to completion before the next is executed. However as your game grows, you may find that it begins to execute slowly, which may temmpt you to quickly implement concurrency into your application. +By far, the easiest way to program is by sticking to synchronous execution, which is what happens by default unless any concurrency is specifically introduced by the programmer. Synchronous execution means that each statement in your code runs to completion before the next is executed. However as your game grows, you may find that it begins to execute slowly, which may temmpt you to quickly implement concurrency into your application. This however poses a significant issue because NVGT supports three types of concurrency, and not knowing what method to use or when to use it can often result in slower or more buggy code than if either a different method of concurrency had been used, or if concurrency had not been used at all. People most often jump strait to threads to solve a problem of performance, when, 99 percent of the time, the performance degradation comes from an easily solvable issue in the person's code and not NVGT or a true need for threads or the lowest levels of concurrency. It can be not only bad practice but also detrimental to your program's development to use more advanced concurrency methods when a simple loop would have sufficed, but knowing when and how to spin up a thread when synchronous execution just won't cut it can also save the day in such cases. As such, this article attempts to explain: diff --git a/doc/src/manual/compiling your project for distribution.md b/doc/src/manual/compiling your project for distribution.md index 675e2270..84b88934 100644 --- a/doc/src/manual/compiling your project for distribution.md +++ b/doc/src/manual/compiling your project for distribution.md @@ -13,10 +13,10 @@ Once your game is ready to be distributed to others, you may want to turn it int * You're creating tutorials or test scripts for others to learn by or to provide examples for how to do something or get feedback, such as trying to find a bug or teaching others how to do something in Nvgt. Hey, that's kinda the same thing as item 2! ## What is an executable file? -This will be sometimes called a binary. It's a file that is a complete program directly compatible with the opperating system for which it is intended. It can be launched directly. +This will be sometimes called a binary. It's a file that is a complete program directly compatible with the operating system for which it is intended. It can be launched directly. ## What about all the different operating systems? -Since Nvgt is intended to be able to run on Windows, Linux and Mac OS, there will be different executables for each targeted operating system. On windows, the resulting binary will have a .exe eextension like other programs you may have seen. On other platforms though, there is no standard file extension for executable files. +Since Nvgt is intended to be able to run on Windows, Linux and Mac OS, there will be different executables for each targeted operating system. On windows, the resulting binary will have a .exe extension like other programs you may have seen. On other platforms though, there is no standard file extension for executable files. e.g. if you compile my_game.nvgt on Windows you'll get a my_game.exe but if you compile on linux, you'll just get a file called my_game. Keep this in mind when trying to compile on a non-windows platform. If you have a file called my_game.nvgt and next to it is a directory called my_game, the compilation process will fail because my_game already exists and is a directory! @@ -38,12 +38,12 @@ NVGT does support what is known as cross compiling projects, which means compili You will receive a popup or STDOut print letting you know how long the compilation took. You should find a new file in the same folder you just compiled that has the same name it does but with a different extension e.g. when compiling my_game.nvgt you'll have my_game.exe. Distribute this along with the necessary libraries in what ever form is required. You can set it all up with an installer, such as Inno Setup, or if your game will be portable you can just zip it up, etc. ## Libraries needed for distribution: -There are a few libraries (dependancies) that Nvgt code relies on. When running from source, Nvgt is just interpreting your .nvgt scripts and using the libraries found in its own installation folder. Generally, if all is normal that will be: +There are a few libraries (dependencies) that Nvgt code relies on. When running from source, Nvgt is just interpreting your .nvgt scripts and using the libraries found in its own installation folder. Generally, if all is normal that will be: * On Windows, c:\Nvgt * On Linux, where you extracted NVGT's tarball to. * On Mac OS, `/Applications/nvgt.app/Contents` -Within that folder you should have a subfolder that is called "lib" (or "Frameworks" on macOS). Lib contains the redistributable dependancies Nvgt uses for certain functionality. When you run from source, the Nvgt interpretor uses this very folder. However, when you compile, you must provide the files in the same directory as the compiled program so that it can find them. You may copy the entire lib folder to the location of the compiled game, or you can optionally just copy the files directly there if you don't want a lib folder for some reason. In other words, you can have a subdirectory within the program's directory called lib with the files inside, or you can also just place the dlls right in the program's directory where the binary is. On windows, you can omit some of the dll files not needed by your code, and we plan to add more and more support for this on other platforms as time goes on. A list is provided below of the basic purpose and importance of each library so you can hopefully know what to omit if you don't want all of them. These files must be included where ever the program ends up, so installers need to copy those over as well, and they should be included in any zip files for portable programs, etc. +Within that folder you should have a subfolder that is called "lib" (or "Frameworks" on macOS). Lib contains the redistributable dependencies Nvgt uses for certain functionality. When you run from source, the Nvgt interpreter uses this very folder. However, when you compile, you must provide the files in the same directory as the compiled program so that it can find them. You may copy the entire lib folder to the location of the compiled game, or you can optionally just copy the files directly there if you don't want a lib folder for some reason. In other words, you can have a subdirectory within the program's directory called lib with the files inside, or you can also just place the dlls right in the program's directory where the binary is. On windows, you can omit some of the dll files not needed by your code, and we plan to add more and more support for this on other platforms as time goes on. A list is provided below of the basic purpose and importance of each library so you can hopefully know what to omit if you don't want all of them. These files must be included where ever the program ends up, so installers need to copy those over as well, and they should be included in any zip files for portable programs, etc. At time of writing, the files are: * bass.dll is required for the sound object and the tts_voice object, though will not be later once we switch from bass to the miniaudio library. The moment one of these objects exists in your script, your program will crash if this dll is not present. @@ -75,12 +75,12 @@ bool preglobals() { ``` ## Crediting open source libraries -NVGT is an open source project that uses open source dependencies. While aside from bass (which we will replace) we have been very careful to avoid any open source components that forbids or restricts comertial usage in any way, we do not always avoid dependencies that ask for a simple attribution in project documentation such as those under a BSD license. We'd rather focus on creating a good engine which we can fix quickly that can produce some epic games with awesome features, without needing to discard a library that implements some amazing feature just because it's devs simply ask users to do little more than just admit to the fact that they didn't write the library. +NVGT is an open source project that uses open source dependencies. While aside from bass (which we will replace) we have been very careful to avoid any open source components that forbids or restricts commercial usage in any way, we do not always avoid dependencies that ask for a simple attribution in project documentation such as those under a BSD license. We'd rather focus on creating a good engine which we can fix quickly that can produce some epic games with awesome features, without needing to discard a library that implements some amazing feature just because it's devs simply ask users to do little more than just admit to the fact that they didn't write the library. To facilitate the proper attribution of such libraries, a file called 3rd_party_code_attributions.html exists in the lib folder. We highly recommend that you distribute this file with your game in order to comply with all attribution requirements which you can read about in the aforementioned document. -The idea is that by simply distributing this attributions document within the lib folder of your app, any user who is very interested in this information can easily find and read it, while any nnormal game player will not stumble upon random code attributions in any kind of intrusive manner. The attributions document is currently well under 100kb, so it should not bloat your distribution. +The idea is that by simply distributing this attributions document within the lib folder of your app, any user who is very interested in this information can easily find and read it, while any normal game player will not stumble upon random code attributions in any kind of intrusive manner. The attributions document is currently well under 100kb, so it should not bloat your distribution. The existing file attributes all open source components in NVGT, not just those that require it. If you want to change this, you can regenerate the file by looking in the doc/OSL folder in NVGT's github repository to see how. -For those who really care about not distributing this file, we hope to provide extra stubs in the future which do not include any components that require a binary attribution. However, there is no denying that this goal is very costly to reach and maintain, while yielding absolutely no true reward for all the time spent sans not needing to distribute an html file with game releases which players and even most developers will not be bothered by anyway. As such, it might be a while before this goal comes to fruition, and we could decide at any point that it is not a viable or worthwhile project to attempt if we find that doing so in any way detraments the development of NVGT, such as by making a feature we want to add very difficult due to lack of available public domain libraries for that feature. +For those who really care about not distributing this file, we hope to provide extra stubs in the future which do not include any components that require a binary attribution. However, there is no denying that this goal is very costly to reach and maintain, while yielding absolutely no true reward for all the time spent sans not needing to distribute an html file with game releases which players and even most developers will not be bothered by anyway. As such, it might be a while before this goal comes to fruition, and we could decide at any point that it is not a viable or worthwhile project to attempt if we find that doing so in any way detriments the development of NVGT, such as by making a feature we want to add very difficult due to lack of available public domain libraries for that feature. diff --git a/doc/src/references/builtin/!Containers/grid/!Grid.nvgt b/doc/src/references/builtin/!Containers/grid/!Grid.nvgt index 8eff618e..a7726ca6 100644 --- a/doc/src/references/builtin/!Containers/grid/!Grid.nvgt +++ b/doc/src/references/builtin/!Containers/grid/!Grid.nvgt @@ -1,5 +1,5 @@ /** - This type is escentially just a more convenient 2d array. One place it's super useful is when representing a game board. + This type is essentially just a more convenient 2d array. One place it's super useful is when representing a game board. 1. grid(); 2. grid(uint width, uint height); 3. grid({repeat {repeat_same T}}); diff --git a/doc/src/references/builtin/!Datatypes/!datatypes.md b/doc/src/references/builtin/!Datatypes/!datatypes.md index a09293ed..ffaf168d 100644 --- a/doc/src/references/builtin/!Datatypes/!datatypes.md +++ b/doc/src/references/builtin/!Datatypes/!datatypes.md @@ -1,4 +1,4 @@ # Datatypes -In this documentation, we consider a datatype to be any class or primative that typically stores one value. While such a datatype could contain a pointer/handle to a more complex type that may store many values (in which case the handle itself is the single value the datetype contains), the types documented here do not directly contain more than one piece of data be that a string of text, a dynamically typed handle or just a simple number. +In this documentation, we consider a datatype to be any class or primitive that typically stores one value. While such a datatype could contain a pointer/handle to a more complex type that may store many values (in which case the handle itself is the single value the datatype contains), the types documented here do not directly contain more than one piece of data be that a string of text, a dynamically typed handle or just a simple number. Beware that a few of these datatypes may get quite advanced, and you are not expected to understand what all of them do (particularly the dynamically typed ones) during the course of normal game development. Instead, we recommend learning about basic datatypes here, and then coming back and looking at any that seemed confusing at first glance when you are trying to solve a particular problem usually relating to a variable you have that needs to be able to store more than one kind of value. diff --git a/doc/src/references/builtin/!Datatypes/any/!any.nvgt b/doc/src/references/builtin/!Datatypes/any/!any.nvgt index 8e3f120b..26c163db 100644 --- a/doc/src/references/builtin/!Datatypes/any/!any.nvgt +++ b/doc/src/references/builtin/!Datatypes/any/!any.nvgt @@ -5,7 +5,7 @@ ## Arguments (2): * ?&in value: The default value stored in this object. ## Remarks: - Though NVGT uses Angelscript which is a statically typed scripting language, there are sometimes ocasions when one may not know the type of value that could be stored in a variable, or may want to create a function that can accept an argument of any type. While this isn't the only way to do so, the any object provides a safe way to acomplish this task, possibly the safest / least restrictive of all available such options. There should be no type that this object can't store. + Though NVGT uses Angelscript which is a statically typed scripting language, there are sometimes occasions when one may not know the type of value that could be stored in a variable, or may want to create a function that can accept an argument of any type. While this isn't the only way to do so, the any object provides a safe way to accomplish this task, possibly the safest / least restrictive of all available such options. There should be no type that this object can't store. The biggest downside to this class is simply that storing and retrieving values from it is just as bulky as the usual way of doing so from dictionary objects. That is, when retrieving a value one must first create a variable then call the any::retrieve() method passing a reference to that variable. something to note is that the constructor of this class is not marked explicit, meaning that if you create a function that takes an any object as it's argument, the user would then be able to directly pass any type to that argument of your function without any extra work. Again just like with dictionaries, there is no way to determine the type of a stored value. Instead if one wants to print the value contained within one of these variables, they must carefully attempt the retrieval with different types until it succeeds where the value can then be printed. diff --git a/doc/src/references/builtin/!Datatypes/string/Methods/is_lower.nvgt b/doc/src/references/builtin/!Datatypes/string/Methods/is_lower.nvgt index 80f43ba8..df9e6366 100644 --- a/doc/src/references/builtin/!Datatypes/string/Methods/is_lower.nvgt +++ b/doc/src/references/builtin/!Datatypes/string/Methods/is_lower.nvgt @@ -12,7 +12,7 @@ // example: void main() { - alert("example", "HELLO".is_lower()); // Should show tfalse. + alert("example", "HELLO".is_lower()); // Should show false. string input = input_box("example", "enter a string"); if(input.is_empty()) exit(); diff --git a/doc/src/references/builtin/!Datatypes/string/Methods/replace.md b/doc/src/references/builtin/!Datatypes/string/Methods/replace.md index 0bff5c46..752b9489 100644 --- a/doc/src/references/builtin/!Datatypes/string/Methods/replace.md +++ b/doc/src/references/builtin/!Datatypes/string/Methods/replace.md @@ -1,12 +1,12 @@ # replace -Try to find any occurances of a particular string, and replace them with a substatution in a given string object. +Try to find any occurrences of a particular string, and replace them with a substitution in a given string object. `string string::replace(string search, string replacement, bool replace_all = true);` ## Arguments: * string search: the string to search for. * string replacement: the string to replace the search text with (if found). -* bool replace_all = true: whether or not all occurances should be replaced, or only the first one. +* bool replace_all = true: whether or not all occurrences should be replaced, or only the first one. ## Returns: string: the specified string with the replacement applied. diff --git a/doc/src/references/builtin/!Datatypes/string/Methods/replace_this.md b/doc/src/references/builtin/!Datatypes/string/Methods/replace_this.md index f2b348f4..853e715f 100644 --- a/doc/src/references/builtin/!Datatypes/string/Methods/replace_this.md +++ b/doc/src/references/builtin/!Datatypes/string/Methods/replace_this.md @@ -1,12 +1,12 @@ # replace_this -Try to find any occurances of a particular string, and replace them with a substatution in a given string object. +Try to find any occurrences of a particular string, and replace them with a substitution in a given string object. `string& string::replace_this(string search, string replacement, bool replace_all = true);` ## Arguments: * string search: the string to search for. * string replacement: the string to replace the search text with (if found). -* bool replace_all = true: whether or not all occurances should be replaced, or only the first one. +* bool replace_all = true: whether or not all occurrences should be replaced, or only the first one. ## Returns: string&: a two-way reference to the specified string with the replacement applied. diff --git a/doc/src/references/builtin/!Datatypes/string/Methods/reverse_bytes.nvgt b/doc/src/references/builtin/!Datatypes/string/Methods/reverse_bytes.nvgt index e913f22a..dca6cc5f 100644 --- a/doc/src/references/builtin/!Datatypes/string/Methods/reverse_bytes.nvgt +++ b/doc/src/references/builtin/!Datatypes/string/Methods/reverse_bytes.nvgt @@ -14,6 +14,6 @@ void main() { alert("reverse_bytes", string_to_hex(raw)); // Should show 4D3C2B1A. // Lets make it clear how this function differs from string::reverse. We'll make a string of emojis and show the results of both methods. string emojis = "🦟🦗🐜🐝🐞🦂🕷"; - alert("emojis reversed propertly", emojis.reverse()); // string::reverse takes the UTF8 encoding into account. - alert("broken emojis", emojis.reverse_bytes()); // This string no longer contains valid character sequences, and so the emoticons will most certainly not show correctly. Aww you can see if you runn this example that it seems even string::reverse_bytes() can't quite get rid of mosquitos though... 😀 + alert("emojis reversed properly", emojis.reverse()); // string::reverse takes the UTF8 encoding into account. + alert("broken emojis", emojis.reverse_bytes()); // This string no longer contains valid character sequences, and so the emoticons will most certainly not show correctly. Aww you can see if you run this example that it seems even string::reverse_bytes() can't quite get rid of mosquitos though... 😀 } diff --git a/doc/src/references/builtin/!Streams/!Streams.md b/doc/src/references/builtin/!Streams/!Streams.md index 51089755..5289958c 100644 --- a/doc/src/references/builtin/!Streams/!Streams.md +++ b/doc/src/references/builtin/!Streams/!Streams.md @@ -1,18 +1,18 @@ # datastreams Streams, also known as datastreams, are one of the primary ways of moving around and manipulating data in nvgt. With their convenient function calls, low memory footprint when dealing with large datasets and with their ability to connect to one another to create a chain of mutations on any data, datastreams are probably the most convenient method for data manipulation in NVGT that exist. -A datastream could be a file on disk, a file downloading from/uploading to the internet, a simple incapsolated string, or some sort of a manipulator such as an encoder, decryptor or compression stream. +A datastream could be a file on disk, a file downloading from/uploading to the internet, a simple incapsulated string, or some sort of a manipulator such as an encoder, decryptor or compression stream. Datastreams can roughly be split into 3 categories, or if you want to be really specific 2.5. * sources: These streams are things like file objects, internet downloads, or really anything that either inputs new data into the application or outputs data from it. Thus, they can read, write or both depending on the properties of the stream. * readers: These streams only support read/input operations, an example may be a decoder. Usually these attach to another stream, read data from the connected stream, and mutate that data as the stream is read from. * writers: The polar opposite of readers, these streams usually connect to another stream E. a file object opened in writing mode where data gets mutated (usually encoded) before being written to the connected stream. -Ocasionally, you may see a reader referred to as a decoder, and a writer referred to as an encoder. +Occasionally, you may see a reader referred to as a decoder, and a writer referred to as an encoder. Particularly when considering reader and writer streams that manipulate data, you can typically chain any number of streams of the same type together to cause a sequence of data mutations to be performed in one function call. For example you could connect an inflating_reader to a hex_decoder that is in turn connected to a file object in read mode. From that point, calling any of the read functions associated with the inflating stream would automatically first read from the file, hex decode it, and decompress/inflate it as needed. Inversely, you could connect a deflating_writer to a hex encoder which is connected to a file object in write mode, causing any data written to the inflating stream to be compressed, hex encoded, and finally written to the file. -There are a few readers and writers that, instead of manipulating data in any way as they pass through, give you details about that data. You can ssee counting_reader and counting_writer as examples of this, these streams count the number of lines and characters that are read or written through them. +There are a few readers and writers that, instead of manipulating data in any way as they pass through, give you details about that data. You can see counting_reader and counting_writer as examples of this, these streams count the number of lines and characters that are read or written through them. Lets put this together with a little demonstration. Say you have a compressed and hex encoded file with many lines in it, and you'd like to read the file while determining the line count as the file is read. You could execute the following, for example: ``` diff --git a/doc/src/references/builtin/!Streams/datastream/!datastream.nvgt b/doc/src/references/builtin/!Streams/datastream/!datastream.nvgt index e9e04b0d..f49d7a31 100644 --- a/doc/src/references/builtin/!Streams/datastream/!datastream.nvgt +++ b/doc/src/references/builtin/!Streams/datastream/!datastream.nvgt @@ -7,7 +7,7 @@ * string encoding = "": The text encoding used to read or write strings to this stream (see remarks), this argument appears in all non-empty child datastream constructors. * datastream_byte_order byteorder = STREAM_BYTE_ORDER_NATIVE: The byte order to read or write binary data to this stream using (see remarks), this argument appears in all non-empty child datastream constructors. ## Remarks: - If this class is directly instanciated, the effect is basically that the string class gets wrapped with streaming functions. The default datastream class will create an internal string object, and any data passed into the initial_data parameter will be copied to that internal string. Then, the read/write functions on the stream will do their work on the internal string object held by the datastream class, which can be read or retrieved in full at any time. Internally, this wraps the std::stringstream class in c++. + If this class is directly instantiated, the effect is basically that the string class gets wrapped with streaming functions. The default datastream class will create an internal string object, and any data passed into the initial_data parameter will be copied to that internal string. Then, the read/write functions on the stream will do their work on the internal string object held by the datastream class, which can be read or retrieved in full at any time. Internally, this wraps the std::stringstream class in c++. It must be noted, however, that this is the parent class for all other datastreams in nvgt. This means that any child datastream such as the file class can be cast to a generic datastream handle. In this case, the read/write functions for the casted handle will perform the function of the child stream which has been casted instead of on an internal string. This is the same for any other parent/child class relationship in programming, but it was mentioned here to avoid any confusion between the default datastream implementation and a datastream handle casted from a different stream. The encoding argument, present in nearly all child datastream constructors, controls what encoding if any strings should be converted to from UTF8 as they are written to the stream with the write_string() function or << operator while the binary property on the stream is set to true, as well as what encoding to convert from when reading them with read_string() or the >> operator. If set to an empty string (the default), strings are left in UTF8 when writing, and already expected to be in UTF8 in a stream when reading from it. The byteorder argument, again present in nearly all child datastream constructors, controls what endianness is used when reading/writing binary data from/to a stream, that is the read_int/write_float/similar functions when the binary property on the stream is set to true. When a value takes more than one byte, the endianness or byte order controls whether the bytes of that value are read/written from left to right or right to left, or in proper terms whether the most significant byte of the value should be written first. The values that can be accepted here are: diff --git a/doc/src/references/builtin/!Streams/datastream/Properties/available.nvgt b/doc/src/references/builtin/!Streams/datastream/Properties/available.nvgt index 5fae66ea..99d6bb8a 100644 --- a/doc/src/references/builtin/!Streams/datastream/Properties/available.nvgt +++ b/doc/src/references/builtin/!Streams/datastream/Properties/available.nvgt @@ -1,5 +1,5 @@ /** - This property returns the number of bytes immedietly available to be read from a stream. + This property returns the number of bytes immediately available to be read from a stream. const int available; ## Remarks: This property may not be implemented in all streams, for example decoders. If it is unavailable, it will return 0. diff --git a/doc/src/references/builtin/Concurrency/!Concurrency.md b/doc/src/references/builtin/Concurrency/!Concurrency.md index 5c16d21d..94145933 100644 --- a/doc/src/references/builtin/Concurrency/!Concurrency.md +++ b/doc/src/references/builtin/Concurrency/!Concurrency.md @@ -1,6 +1,6 @@ # Concurrency -This section contains the documentation for all mechenisms revolving around several things running at once, usually involving threads and their related synchronization facilities. +This section contains the documentation for all mechanisms revolving around several things running at once, usually involving threads and their related synchronization facilities. A warning that delving into this section will expose you to some rather low level concepts, the misapplication of which could result in your program crashing or acting oddly without the usual helpful error information provided by NVGT. -The highest level and most easily invoqued method for multithreading in nvgt is the async template class, allowing you to call any script or system function on another thread and retrieve it's return value later. +The highest level and most easily invoked method for multithreading in nvgt is the async template class, allowing you to call any script or system function on another thread and retrieve it's return value later. diff --git a/doc/src/references/builtin/Concurrency/Classes/async/Methods/try_wait.nvgt b/doc/src/references/builtin/Concurrency/Classes/async/Methods/try_wait.nvgt index fd9e96e6..83851047 100644 --- a/doc/src/references/builtin/Concurrency/Classes/async/Methods/try_wait.nvgt +++ b/doc/src/references/builtin/Concurrency/Classes/async/Methods/try_wait.nvgt @@ -1,5 +1,5 @@ /** - Wait a given number of millisecondss for an async call to complete. + Wait a given number of milliseconds for an async call to complete. bool try_wait(uint milliseconds); ## Arguments: * uint milliseconds: The amount of time to wait, may be 0 to not wait at all. @@ -7,8 +7,8 @@ bool: True if the async call has finished, or false if it is still running after the given number of milliseconds has expired. ## Remarks: If you try waiting for 50ms but the async call finishes in 10ms, the try_wait call will only block for 10 out of the 50ms requested. In short, any blocking try_wait call is canceled prematurely with the try_wait function returning true if the call finishes while try_wait is in the middle of executing. - If the function has already finished executing or if this async object is not connected to a function (thus nothing to wait for), try_wait() will immedietly return true without waiting or blocking at all regardless of arguments. - Similar to the async::wait function, you should be careful using this method in the same thread that show_window was called or if you do, make sure to call it with tiny durations and intersperce standard nvgt wait(5) or similar calls in your loops so that window messages and events continue to be handled. + If the function has already finished executing or if this async object is not connected to a function (thus nothing to wait for), try_wait() will immediately return true without waiting or blocking at all regardless of arguments. + Similar to the async::wait function, you should be careful using this method in the same thread that show_window was called or if you do, make sure to call it with tiny durations and interspurse standard nvgt wait(5) or similar calls in your loops so that window messages and events continue to be handled. */ // Example: diff --git a/doc/src/references/builtin/Concurrency/Classes/async/Methods/wait.nvgt b/doc/src/references/builtin/Concurrency/Classes/async/Methods/wait.nvgt index d88f2f5b..0bc2597e 100644 --- a/doc/src/references/builtin/Concurrency/Classes/async/Methods/wait.nvgt +++ b/doc/src/references/builtin/Concurrency/Classes/async/Methods/wait.nvgt @@ -4,7 +4,7 @@ ## Remarks: This is the simplest way to wait for the execution of an async function to complete, however it does not allow you to execute any of your own code while doing so. The execution of your program or the thread you called the wait function on will be completely blocked until the async function returns. This also means that window events cannot be received while the wait function is executing, so you should be very careful about using this from an environment with a game window especially on the thread that created it. For more control such as the ability to execute your own code during the wait, check out the try_wait() function. - If the async object this function is called on is executed with a default constructor and thus has no function call in progress, this function will return immedietly as there is nothing to wait for. + If the async object this function is called on is executed with a default constructor and thus has no function call in progress, this function will return immediately as there is nothing to wait for. */ // Example: diff --git a/doc/src/references/builtin/Concurrency/Classes/async/Properties/complete.nvgt b/doc/src/references/builtin/Concurrency/Classes/async/Properties/complete.nvgt index 27a18442..065741ab 100644 --- a/doc/src/references/builtin/Concurrency/Classes/async/Properties/complete.nvgt +++ b/doc/src/references/builtin/Concurrency/Classes/async/Properties/complete.nvgt @@ -1,9 +1,9 @@ /** - Immedietly shows whether an async function call has completed, meaning that either a result is available or that there has been an error. + Immediately shows whether an async function call has completed, meaning that either a result is available or that there has been an error. const bool complete; ## Remarks: This is the best and prettiest looking method of checking whether an async call has completed or not without blocking. You can also call the try_wait() function with an argument of 0 for a similar effect, though this looks nicer and takes any uninitialized state of the object into account. - Usually this will be used when a loop has some other sort of waiting logic, such as the global nvgt wait() function we are all fermiliar with. + Usually this will be used when a loop has some other sort of waiting logic, such as the global nvgt wait() function we are all familiar with. */ // Example: diff --git a/doc/src/references/builtin/Concurrency/Classes/mutex/!mutex.nvgt b/doc/src/references/builtin/Concurrency/Classes/mutex/!mutex.nvgt index 9a1f0762..4681ab3e 100644 --- a/doc/src/references/builtin/Concurrency/Classes/mutex/!mutex.nvgt +++ b/doc/src/references/builtin/Concurrency/Classes/mutex/!mutex.nvgt @@ -3,10 +3,10 @@ mutex(); ## Remarks: It is not safe for 2 threads to try accessing the same portion of memory at the same time, that especially becomes true when at least one of the threads performs any kind of updates to the memory. One of the common and widely used solutions to this problem is basically to create a lock condition where, if one thread starts modifying a bit of shared data, another thread which wants to access or also modify that data must first wait for the initial accessing thread to complete that data modification before continuing. - The mutex class is one such method of implementing this mechenism. On the surface it is a simple structure that can be in a locked or unlocked state. If thread A calls the lock method on a mutex object which is already locked from thread B, thread A will block execution until thread B calls the unlock method of the mutex object which can then be successfully locked by thread A. - This is the most basic mutex class, though there are other derivitives. Most mutex classes have the ability to try locking a mutex for up to a given timeout in milliseconds before returning false if a lock could not be acquired within the given timeout. + The mutex class is one such method of implementing this mechanism. On the surface it is a simple structure that can be in a locked or unlocked state. If thread A calls the lock method on a mutex object which is already locked from thread B, thread A will block execution until thread B calls the unlock method of the mutex object which can then be successfully locked by thread A. + This is the most basic mutex class, though there are other derivatives. Most mutex classes have the ability to try locking a mutex for up to a given timeout in milliseconds before returning false if a lock could not be acquired within the given timeout. Mutexes or most other threading primitives are not connected by default to any sort of data. You can use one mutex for 10 variables if you want and if it makes sense in your context. - Remember, you are beginning to enter lower level and much more dangerous programming teritory when dealing with multiple threads. If you accidentaly forget to unlock a mutex when you are done with it for example, any thread that next tries locking that mutex will at the least malfunction but is much more likely to just hang your app forever. Be careful! + Remember, you are beginning to enter lower level and much more dangerous programming territory when dealing with multiple threads. If you accidentally forget to unlock a mutex when you are done with it for example, any thread that next tries locking that mutex will at the least malfunction but is much more likely to just hang your app forever. Be careful! */ // Example: @@ -44,7 +44,7 @@ void main() { snd.volume += 1; } else if (key_pressed(KEY_DOWN)) { mutex_lock exclusive(ding_mutex); - snd.volume -= 1; // We can be sure that these volume changes willl not take place while the sound is being accessed on another thread. + snd.volume -= 1; // We can be sure that these volume changes will not take place while the sound is being accessed on another thread. } } exit_program.set(); // Make sure the dinging_thread knows it's time to shut down. diff --git a/doc/src/references/builtin/Concurrency/Classes/mutex/methods/lock.md b/doc/src/references/builtin/Concurrency/Classes/mutex/methods/lock.md index 98894f2d..083ac60a 100644 --- a/doc/src/references/builtin/Concurrency/Classes/mutex/methods/lock.md +++ b/doc/src/references/builtin/Concurrency/Classes/mutex/methods/lock.md @@ -1,5 +1,5 @@ # lock -Locks the mutex, waiting indefinitely or for a given duration if nesessary for the operation to succeed. +Locks the mutex, waiting indefinitely or for a given duration if necessary for the operation to succeed. 1. `void lock();` 2. `void lock(uint milliseconds);` diff --git a/doc/src/references/builtin/Concurrency/Classes/mutex/mutex_lock.md b/doc/src/references/builtin/Concurrency/Classes/mutex/mutex_lock.md index 781ab244..152d4970 100644 --- a/doc/src/references/builtin/Concurrency/Classes/mutex/mutex_lock.md +++ b/doc/src/references/builtin/Concurrency/Classes/mutex/mutex_lock.md @@ -24,7 +24,7 @@ In this case, the constructor of the mutex_lock class will automatically call th The class contains a single method, void unlock(), which allows you to unlock the mutex prematurely before the scope actually exits. -There is a very good reason for using this class sometimes as aposed to calling mutex.lock directly. Consider: +There is a very good reason for using this class sometimes as opposed to calling mutex.lock directly. Consider: ``` my_mutex.lock(); @@ -40,9 +40,9 @@ throw("Oh no, this code is broken!"); exclusive.unlock() ``` -The mutex_lock object will be destroyed as part of the exception handler unwinding the stack, because the handler already knows to destroy any objects it encounters along the way. However any code that handles exceptions certainly does not know it should specificly call the unlock method of a mutex, thus you could introduce a deadlock in your code if you lock a mutex and then run code that throws an exception without using this mutex_lock class. +The mutex_lock object will be destroyed as part of the exception handler unwinding the stack, because the handler already knows to destroy any objects it encounters along the way. However any code that handles exceptions certainly does not know it should specifically call the unlock method of a mutex, thus you could introduce a deadlock in your code if you lock a mutex and then run code that throws an exception without using this mutex_lock class. -A final hint, it is actually possible to create scopes in Angelscript and in many other languages as well without any preceeding conditions, so you do not need an if statement or a while loop to use this class. +A final hint, it is actually possible to create scopes in Angelscript and in many other languages as well without any preceding conditions, so you do not need an if statement or a while loop to use this class. ``` int var1 = 2; diff --git a/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/get_opIndex.nvgt b/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/get_opIndex.nvgt index b8c69b00..00e1e948 100644 --- a/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/get_opIndex.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/get_opIndex.nvgt @@ -1,5 +1,5 @@ /** - Get a value out of the JSON arraywith literal syntax, for example `arr[2]`. + Get a value out of the JSON array with literal syntax, for example `arr[2]`. var@ json_array::get_opIndex(uint index) property; ## Arguments: * uint index: the index of the value to get. diff --git a/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/opCall.nvgt b/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/opCall.nvgt index 5c9b3c90..3ff6668a 100644 --- a/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/opCall.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Classes/json_array/Operators/opCall.nvgt @@ -6,7 +6,7 @@ ## Returns: var@: a handle to the object, or null if it couldn't be found. ## Remarks: - Queries are formatted like so, using key names and indexes seperated with ".": + Queries are formatted like so, using key names and indexes separated with ".": > world.player.0 It can be as nested as you like. */ diff --git a/doc/src/references/builtin/Data Manipulation/Classes/json_object/Methods/is_null.nvgt b/doc/src/references/builtin/Data Manipulation/Classes/json_object/Methods/is_null.nvgt index 7e6fed77..3bb2017f 100644 --- a/doc/src/references/builtin/Data Manipulation/Classes/json_object/Methods/is_null.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Classes/json_object/Methods/is_null.nvgt @@ -11,5 +11,5 @@ void main() { string data = """{"brain": null}"""; json_object@ o = parse_json(data); - alert("Info", o.is_null("brain") ? "null" : "nonull"); + alert("Info", o.is_null("brain") ? "null" : "not null"); } diff --git a/doc/src/references/builtin/Data Manipulation/Classes/pack/methods/set_pack_identifier.md b/doc/src/references/builtin/Data Manipulation/Classes/pack/methods/set_pack_identifier.md index 91385664..7716f368 100644 --- a/doc/src/references/builtin/Data Manipulation/Classes/pack/methods/set_pack_identifier.md +++ b/doc/src/references/builtin/Data Manipulation/Classes/pack/methods/set_pack_identifier.md @@ -1,4 +1,4 @@ -# pset_pack_identifier +# set_pack_identifier Set the identifier of this pack object (e.g. the first 8-bytes that determine if you have a valid pack or not). `bool pack::set_pack_identifier(string ident);` diff --git a/doc/src/references/builtin/Data Manipulation/Enums/regexp_options.md b/doc/src/references/builtin/Data Manipulation/Enums/regexp_options.md index 0a0080ca..dd23db71 100644 --- a/doc/src/references/builtin/Data Manipulation/Enums/regexp_options.md +++ b/doc/src/references/builtin/Data Manipulation/Enums/regexp_options.md @@ -31,5 +31,5 @@ See the PCRE documentation for more information. * RE_NEWLINE_CRLF: assume newline is CRLF ("\r\n") [ctor] * RE_NEWLINE_ANY: assume newline is any valid Unicode newline character [ctor] * RE_NEWLINE_ANY_CRLF: assume newline is any of CR, LF, CRLF [ctor] -* RE_GLOBAL: replace all occurences (/g) [subst] +* RE_GLOBAL: replace all occurrences (/g) [subst] * RE_NO_VARS: treat dollar in replacement string as ordinary character [subst] diff --git a/doc/src/references/builtin/Data Manipulation/Functions/join.nvgt b/doc/src/references/builtin/Data Manipulation/Functions/join.nvgt index 83ea9b25..bd76fe4f 100644 --- a/doc/src/references/builtin/Data Manipulation/Functions/join.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Functions/join.nvgt @@ -1,9 +1,9 @@ /** - turn an array into a string, with each element being seperated by the given delimiter. + turn an array into a string, with each element being separated by the given delimiter. string join(string[] elements, string delimiter); ## Arguments: * string[] elements: the array to join. - * string delimiter: the delimiter used to seperate each element in the array (can be empty). + * string delimiter: the delimiter used to separate each element in the array (can be empty). ## Returns: string: the given array as a string. ## Remarks: diff --git a/doc/src/references/builtin/Data Manipulation/Functions/string_base32_normalize.nvgt b/doc/src/references/builtin/Data Manipulation/Functions/string_base32_normalize.nvgt index 50568ad8..06ab7a5f 100644 --- a/doc/src/references/builtin/Data Manipulation/Functions/string_base32_normalize.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Functions/string_base32_normalize.nvgt @@ -6,7 +6,7 @@ ## Returns: string: the normalized string. ## Remarks: - The primary thing this function does is to skip sepeerators, convert all letters to uppercase, and make sure the length is a multiple of 8. + The primary thing this function does is to skip separators, convert all letters to uppercase, and make sure the length is a multiple of 8. To learn more about base32, click [here](https://en.wikipedia.org/wiki/Base32). */ diff --git a/doc/src/references/builtin/Data Manipulation/Functions/string_base64_decode.nvgt b/doc/src/references/builtin/Data Manipulation/Functions/string_base64_decode.nvgt index 1212c2ed..2b1b3ca4 100644 --- a/doc/src/references/builtin/Data Manipulation/Functions/string_base64_decode.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Functions/string_base64_decode.nvgt @@ -9,7 +9,7 @@ ## Remarks: The following options may be passed to the options argument of this function: * STRING_BASE64_DEFAULT: The defaults passed to the string_base64_encode function. - * STRING_BASE64_URL: Use base64 URL encoding as aposed to the / and = characters. + * STRING_BASE64_URL: Use base64 URL encoding as opposed to the / and = characters. * STRING_BASE64_PADLESS: Allows decoding even if the string does not end with = padding characters. You can learn more about base64 [here.](https://en.wikipedia.org/wiki/Base64) */ diff --git a/doc/src/references/builtin/Data Manipulation/Functions/string_base64_encode.nvgt b/doc/src/references/builtin/Data Manipulation/Functions/string_base64_encode.nvgt index 062492d2..c03cff85 100644 --- a/doc/src/references/builtin/Data Manipulation/Functions/string_base64_encode.nvgt +++ b/doc/src/references/builtin/Data Manipulation/Functions/string_base64_encode.nvgt @@ -9,7 +9,7 @@ ## Remarks: The following options may be passed to the options argument of this function: * STRING_BASE64_DEFAULT: The default options (i.e. insert padding and do not use URL encoding). - * STRING_BASE64_URL: Use base64 URL encoding as aposed to the / and = characters. + * STRING_BASE64_URL: Use base64 URL encoding as opposed to the / and = characters. * STRING_BASE64_PADLESS: Allows decoding even if the string does not end with = padding characters. You can learn more about base64 [here.](https://en.wikipedia.org/wiki/Base64) */ diff --git a/doc/src/references/builtin/Date and Time/Classes/datetime/!datetime.md b/doc/src/references/builtin/Date and Time/Classes/datetime/!datetime.md index 17f8e077..52638e4a 100644 --- a/doc/src/references/builtin/Date and Time/Classes/datetime/!datetime.md +++ b/doc/src/references/builtin/Date and Time/Classes/datetime/!datetime.md @@ -1,7 +1,7 @@ # datetime This class stores an instance in time represented as years, months, days, hours, minutes, seconds, milliseconds and microseconds. -The class stores time independent of timezone, and thus uses UTC by default. You can use a calendar object in place of this one if you need to check local time, however it is faster to calculate time without needing to consider the timezone and thus any time difference calculations should be done with this object instead of calander. +The class stores time independent of timezone, and thus uses UTC by default. You can use a calendar object in place of this one if you need to check local time, however it is faster to calculate time without needing to consider the timezone and thus any time difference calculations should be done with this object instead of calendar. 1. `datetime();` 2. datetime(double julian_day); diff --git a/doc/src/references/builtin/Date and Time/Functions/datetime_is_valid.nvgt b/doc/src/references/builtin/Date and Time/Functions/datetime_is_valid.nvgt index 2978d902..19f86edb 100644 --- a/doc/src/references/builtin/Date and Time/Functions/datetime_is_valid.nvgt +++ b/doc/src/references/builtin/Date and Time/Functions/datetime_is_valid.nvgt @@ -16,8 +16,8 @@ // Example: void main() { - alert("example 1", datetime_is_valid(2023, 2, 29)); // Will display false (not a leepyear!) - alert("example 2", datetime_is_valid(2020, 2, 29)); // Will display true, is a leapyear. + alert("example 1", datetime_is_valid(2023, 2, 29)); // Will display false (not a leap year!) + alert("example 2", datetime_is_valid(2020, 2, 29)); // Will display true, is a leap year. alert("example 3", datetime_is_valid(2020, 6, 31)); // Will display false (June has 30 days). alert("example 4", datetime_is_valid(2020, 7, 31, 13, 71, 59)); // Will display false (invalid time values). } diff --git a/doc/src/references/builtin/Date and Time/Functions/parse_datetime.nvgt b/doc/src/references/builtin/Date and Time/Functions/parse_datetime.nvgt index 8242542d..32f414a6 100644 --- a/doc/src/references/builtin/Date and Time/Functions/parse_datetime.nvgt +++ b/doc/src/references/builtin/Date and Time/Functions/parse_datetime.nvgt @@ -12,7 +12,7 @@ This function may throw an exception if an invalid date/time is provided. You can use the global `bool datetime_is_valid_format(string str)` function to attempt validating user input before passing it as an argument here. If you use the version of this function without a format specifier, it will try to automatically determine the format of the date/time using several available standard formats. This function will clean the input string such as trimming whitespace before parsing is attempted. - Internally, this wraps the DateTimeParser functionality in the Poco c++ libraries. Their documentation says the following, copied verbatim, about this parsing engine, though note in nvgt DateTime:::makeUTC is called datetime.make_UTC, for example. + Internally, this wraps the DateTimeParser functionality in the Poco c++ libraries. Their documentation says the following, copied verbatim, about this parsing engine, though note in NVGT DateTime:::makeUTC is called datetime.make_UTC, for example. This class provides a method for parsing dates and times from strings. All parsing methods do their best to parse a meaningful result, even from malformed input strings. The returned DateTime will always contain a time in the same timezone as the time in the string. Call DateTime::makeUTC() with the timeZoneDifferential returned by parse() to convert the DateTime to UTC. Note: When parsing a time in 12-hour (AM/PM) format, the hour (%h) must be parsed before the AM/PM designator (%a, %A), otherwise the AM/PM designator will be ignored. diff --git a/doc/src/references/builtin/Date and Time/Global Properties/timer_default_accuracy.nvgt b/doc/src/references/builtin/Date and Time/Global Properties/timer_default_accuracy.nvgt index 1ee59ba8..ca40549e 100644 --- a/doc/src/references/builtin/Date and Time/Global Properties/timer_default_accuracy.nvgt +++ b/doc/src/references/builtin/Date and Time/Global Properties/timer_default_accuracy.nvgt @@ -4,7 +4,7 @@ ## Remarks: Internally NVGT always uses a clock with microsecond accuracy to track time, meaning that microseconds is the highest accuracy that timer objects support. However in many cases, microsecond accuracy is not desired and causes a user to need to type far too many 0s than they would desire when handling elapsed time. Therefor NVGT allows you to set a devisor/multiplier that is applied to any timer operation as it passes between NVGT and your script. The accuracy represented here is just a number of microseconds to divide values returned from timer.elapsed by before returning them to your script, as well as the number of microseconds to multiply by if one uses the timer.force function. - If this property is changed, any timers that already exist will remain uneffected, and only newly created timers will use the updated value. + If this property is changed, any timers that already exist will remain unaffected, and only newly created timers will use the updated value. Some useful constants are provided to make this property more useful: * MILLISECONDS: 1000 microseconds * SECONDS: 1000 MILLISECONDS diff --git a/doc/src/references/builtin/Filesystem/Functions/directory_exists.nvgt b/doc/src/references/builtin/Filesystem/Functions/directory_exists.nvgt index edc6bc92..2bb7cc5a 100644 --- a/doc/src/references/builtin/Filesystem/Functions/directory_exists.nvgt +++ b/doc/src/references/builtin/Filesystem/Functions/directory_exists.nvgt @@ -2,7 +2,7 @@ Determine if a directory exists or not. bool directory_exists(string directory); ## Arguments: - * string directory: the directory whose existance will be checked (can be a relative or absolute path). + * string directory: the directory whose existence will be checked (can be a relative or absolute path). ## Returns: true if the directory exists, false otherwise. */ diff --git a/doc/src/references/builtin/Filesystem/Functions/file_get_date_created.nvgt b/doc/src/references/builtin/Filesystem/Functions/file_get_date_created.nvgt index 6806b136..5a454b56 100644 --- a/doc/src/references/builtin/Filesystem/Functions/file_get_date_created.nvgt +++ b/doc/src/references/builtin/Filesystem/Functions/file_get_date_created.nvgt @@ -1,5 +1,5 @@ /** - Get a datetime object representing the creation date of a particula file. + Get a datetime object representing the creation date of a particular file. datetime file_get_date_created(string filename); ## Arguments: * string filename; the name of the file to check. diff --git a/doc/src/references/builtin/Filesystem/Functions/file_get_date_modified.nvgt b/doc/src/references/builtin/Filesystem/Functions/file_get_date_modified.nvgt index c37d0234..e272eb6a 100644 --- a/doc/src/references/builtin/Filesystem/Functions/file_get_date_modified.nvgt +++ b/doc/src/references/builtin/Filesystem/Functions/file_get_date_modified.nvgt @@ -1,5 +1,5 @@ /** - Get a datetime object representing the modification date of a particula file. + Get a datetime object representing the modification date of a particular file. datetime file_get_date_modified(string filename); ## Arguments: * string filename; the name of the file to check. diff --git a/doc/src/references/builtin/Filesystem/Functions/glob.nvgt b/doc/src/references/builtin/Filesystem/Functions/glob.nvgt index 415b59b3..cc18af95 100644 --- a/doc/src/references/builtin/Filesystem/Functions/glob.nvgt +++ b/doc/src/references/builtin/Filesystem/Functions/glob.nvgt @@ -9,7 +9,7 @@ ## Remarks: This function provides for one of the easiest ways to enumerate the filesystem in NVGT, particularly because the path patterns provided can actually cause semi-recursive directory searches. The search starts at the current working directory unless an absolute path is given. The glob patterns have simple rules: - * path seperators must be matched exactly, \* will not cause a recursive lookup + * path separators must be matched exactly, \* will not cause a recursive lookup * \* matches any sequence of characters * ? matches any single character * [set] matches any characters between the brackets diff --git a/doc/src/references/builtin/Networking/classes/network/methods/request.md b/doc/src/references/builtin/Networking/classes/network/methods/request.md index c835d870..6d59468a 100644 --- a/doc/src/references/builtin/Networking/classes/network/methods/request.md +++ b/doc/src/references/builtin/Networking/classes/network/methods/request.md @@ -1,5 +1,5 @@ # request -This is the function you'll probably be calling the most when you're dealing with the network object in NVGT. It checks if an event has occured since the last time it checked. If it has, it returns you a network_event handle with info about it. +This is the function you'll probably be calling the most when you're dealing with the network object in NVGT. It checks if an event has occurred since the last time it checked. If it has, it returns you a network_event handle with info about it. `network_event@ network::request(uint timeout = 0);` diff --git a/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_file.nvgt b/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_file.nvgt index 32f3028a..ca039043 100644 --- a/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_file.nvgt +++ b/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_file.nvgt @@ -1,5 +1,5 @@ /** - Get the name/path of the source file where the exception occured. + Get the name/path of the source file where the exception occurred. string get_exception_file(); ## Returns: string: the name/path of the file where the exception was thrown. diff --git a/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_line.nvgt b/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_line.nvgt index 5c339265..110b2501 100644 --- a/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_line.nvgt +++ b/doc/src/references/builtin/Profiling and Debugging/Functions/get_exception_line.nvgt @@ -1,8 +1,8 @@ /** - Get the line an exception occured on. + Get the line an exception occurred on. int get_exception_line(); ## Returns: - int: the line number the exception occured on. + int: the line number the exception occurred on. */ // Example: diff --git a/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/!random interface.md b/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/!random interface.md index 1db23f16..bbcac7ff 100644 --- a/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/!random interface.md +++ b/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/!random interface.md @@ -5,10 +5,10 @@ Defines the class structure that is available in NVGT's object based pseudorando ## Arguments (2): * uint seed: The number used as the seed/starting point for the RNG, passing the same seed will yield the same sequence of random numbers. ## Remarks: -NVGT contains several different pseudorandom number generators which can all be instanciated as many times as the programmer needs. +NVGT contains several different pseudorandom number generators which can all be instantiated as many times as the programmer needs. These generators all share pretty much exactly the same methods by signature and are interacted with in the same way, and so it will be documented only once here. Small topics explaining the differences for each actual generator are documented below this interface. -These classes all wrap a public domain single header library called [rnd.h](https://github.com/mattiasgustavsson/libs/blob/main/rnd.h) by mattiasgustavsson on Github. The explinations for each generator as well as the following more general expination about all of them were copied verbatim from the comments in that header, as they are able to describe the generators best and already contain links to more details. +These classes all wrap a public domain single header library called [rnd.h](https://github.com/mattiasgustavsson/libs/blob/main/rnd.h) by mattiasgustavsson on Github. The explanations for each generator as well as the following more general explanation about all of them were copied verbatim from the comments in that header, as they are able to describe the generators best and already contain links to more details. The library includes four different generators: PCG, WELL, GameRand and XorShift. They all have different characteristics, and you might want to use them for different things. GameRand is very fast, but does not give a great distribution or period length. XorShift is the only one returning a 64-bit value. WELL is an improvement of the often used Mersenne Twister, and has quite a large internal state. PCG is small, fast and has a small state. If you don't have any specific reason, you may default to using PCG. diff --git a/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/nextf.nvgt b/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/nextf.nvgt index 846c53dc..a55d9b0a 100644 --- a/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/nextf.nvgt +++ b/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/nextf.nvgt @@ -1,5 +1,5 @@ /** - Return the next random floatingpoint number from the generator. + Return the next random floating point number from the generator. float nextf(); ## Returns: float: The next random float (between 0.0 and 1.0). diff --git a/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/seed.nvgt b/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/seed.nvgt index d1baeacf..00bb2323 100644 --- a/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/seed.nvgt +++ b/doc/src/references/builtin/Pseudorandom Generation/Classes/!random_interface/Methods/seed.nvgt @@ -1,5 +1,5 @@ /** - Seed the random number generator with a new startingpoint value. + Seed the random number generator with a new starting point value. void seed(uint new_seed = random_seed()); arguments: * uint new_seed = random_seed(): The seed to use (may be uint64 depending on generator, if so will default to random_seed64). diff --git a/doc/src/references/builtin/Pseudorandom Generation/Functions/random.nvgt b/doc/src/references/builtin/Pseudorandom Generation/Functions/random.nvgt index 884ba16c..1818ca94 100644 --- a/doc/src/references/builtin/Pseudorandom Generation/Functions/random.nvgt +++ b/doc/src/references/builtin/Pseudorandom Generation/Functions/random.nvgt @@ -7,7 +7,7 @@ ## Returns: int: a random number in the given range. ## Remarks: - Note that this function is a pseudorandom number generator. To lern more, click [here](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). + Note that this function is a pseudorandom number generator. To learn more, click [here](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). */ // Example: diff --git a/doc/src/references/builtin/Pseudorandom Generation/Functions/random_bool.nvgt b/doc/src/references/builtin/Pseudorandom Generation/Functions/random_bool.nvgt index 3f62f14e..3bda003f 100644 --- a/doc/src/references/builtin/Pseudorandom Generation/Functions/random_bool.nvgt +++ b/doc/src/references/builtin/Pseudorandom Generation/Functions/random_bool.nvgt @@ -2,11 +2,11 @@ Generates a true or false value pseudorandomly. bool random_bool(int percent = 50); ## Arguments: - * int percent = 50: the likelyhood (as a percent from 0-100) of generating a true value. Defaults to 50. + * int percent = 50: the likelihood (as a percent from 0-100) of generating a true value. Defaults to 50. ## Returns: bool: either true or false. ## Remarks; - Note that this function is a pseudorandom number generator. To lern more, click [here](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). + Note that this function is a pseudorandom number generator. To learn more, click [here](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). */ // Example: diff --git a/doc/src/references/builtin/Pseudorandom Generation/Functions/random_character.nvgt b/doc/src/references/builtin/Pseudorandom Generation/Functions/random_character.nvgt index d9ca91b7..616d5b47 100644 --- a/doc/src/references/builtin/Pseudorandom Generation/Functions/random_character.nvgt +++ b/doc/src/references/builtin/Pseudorandom Generation/Functions/random_character.nvgt @@ -8,7 +8,7 @@ string: a random ascii character in the given range. ## Remarks: If you pass a string with more than one byte in it to either of the arguments in this function, only the first byte is used. - Note that this function uses a pseudorandom number generator. To lern more, click [here](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). + Note that this function uses a pseudorandom number generator. To learn more, click [here](https://en.wikipedia.org/wiki/Pseudorandom_number_generator). */ // Example: diff --git a/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/get_volume.nvgt b/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/get_volume.nvgt index ef5f6343..852eda1b 100644 --- a/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/get_volume.nvgt +++ b/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/get_volume.nvgt @@ -4,7 +4,7 @@ ## Returns: int: the current volume in percentage. ## Remarks: - 0 is silent, 100 is louded. If this hasn't been assigned, it will use the OS setting which may not be 100%. Beware if running old code, this is different from bgt having 0 be the max. + 0 is silent, 100 is loudest. If this hasn't been assigned, it will use the OS setting which may not be 100%. Beware if running old code, this is different from bgt having 0 be the max. */ // Example: diff --git a/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/set_volume.nvgt b/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/set_volume.nvgt index e94f45c0..d717b93b 100644 --- a/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/set_volume.nvgt +++ b/doc/src/references/builtin/Text-To-Speech/classes/tts_voice/Methods/set_volume.nvgt @@ -4,7 +4,7 @@ ## Arguments: * int volume: the desired volume level. ## Remarks: - 0 is silent, 100 is louded. If this hasn't been assigned, it will use the OS setting which may not be 100%. Beware if running old code, this is different from bgt having 0 be the max. It's better to use this instead of directly setting volume property. + 0 is silent, 100 is loudest. If this hasn't been assigned, it will use the OS setting which may not be 100%. Beware if running old code, this is different from bgt having 0 be the max. It's better to use this instead of directly setting volume property. */ // Example: diff --git a/doc/src/references/builtin/User Interface/Functions/clipboard_set_raw_text.nvgt b/doc/src/references/builtin/User Interface/Functions/clipboard_set_raw_text.nvgt index 5af7dd48..d8cdbecc 100644 --- a/doc/src/references/builtin/User Interface/Functions/clipboard_set_raw_text.nvgt +++ b/doc/src/references/builtin/User Interface/Functions/clipboard_set_raw_text.nvgt @@ -6,7 +6,7 @@ ## Returns: Bool: true on success, false on failure. ## Remarks: - To copy UTF-8 textt, see clipboard_set_text(). + To copy UTF-8 text, see clipboard_set_text(). */ // Example: @@ -16,5 +16,5 @@ void main() { if (text == "") alert("Info", "Your clipboard has been cleared."); else - alert("Info", "Text coppied"); + alert("Info", "Text copied"); } diff --git a/doc/src/references/builtin/User Interface/Functions/clipboard_set_text.nvgt b/doc/src/references/builtin/User Interface/Functions/clipboard_set_text.nvgt index d6fc1340..c878be14 100644 --- a/doc/src/references/builtin/User Interface/Functions/clipboard_set_text.nvgt +++ b/doc/src/references/builtin/User Interface/Functions/clipboard_set_text.nvgt @@ -16,5 +16,5 @@ void main() { if (text == "") alert("Info", "Your clipboard has been cleared."); else - alert("Info", "Text coppied"); + alert("Info", "Text copied"); } diff --git a/doc/src/references/builtin/User Interface/Functions/message_box.nvgt b/doc/src/references/builtin/User Interface/Functions/message_box.nvgt index 0bcd1614..c7f0bb06 100644 --- a/doc/src/references/builtin/User Interface/Functions/message_box.nvgt +++ b/doc/src/references/builtin/User Interface/Functions/message_box.nvgt @@ -11,7 +11,7 @@ ## Remarks: Notes on button syntax: * A grave character (`) prepending button text is default enter key. - * A tilda character (~) before text means default cancel. + * A tilde character (~) before text means default cancel. */ // Example: diff --git a/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/!audio_form.md b/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/!audio_form.md index cc1e8485..37de6308 100644 --- a/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/!audio_form.md +++ b/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/!audio_form.md @@ -1,5 +1,5 @@ # audio_form -This class fecilitates the easy creation of user interfaces that convey their usage entirely through audio. +This class facilitates the easy creation of user interfaces that convey their usage entirely through audio. ## Notes: * many of the methods in this class only work on certain types of controls, and will return false and set an error value if used on invalid types of controls. This will generally be indicated in the documentation for each function. diff --git a/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/create_progress_bar.md b/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/create_progress_bar.md index a5d3a328..77dda4cd 100644 --- a/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/create_progress_bar.md +++ b/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/create_progress_bar.md @@ -5,7 +5,7 @@ Creates a new progress bar control and adds it to the audio form. ## Arguments: * string caption: the label to associate with the progress bar. -* int speak_interval = 5: how often to spaek percentage changes. +* int speak_interval = 5: how often to speak percentage changes. * bool speak_global = true: should progress updates be spoken even when this control doesn't have keyboard focus? ## Returns: diff --git a/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/get_current_focus.md b/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/get_current_focus.md index c3f9fa22..52db405d 100644 --- a/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/get_current_focus.md +++ b/doc/src/references/include/Auditory User Interface (form.nvgt)/Classes/audio_form/Methods/get_current_focus.md @@ -1,5 +1,5 @@ # get_current_focus -Get the control index of the control with the keyboartd focus. +Get the control index of the control with the keyboard focus. `int audio_form::get_current_focus();` diff --git a/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/control_types.md b/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/control_types.md index 577830ed..d9ac1b71 100644 --- a/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/control_types.md +++ b/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/control_types.md @@ -1,5 +1,5 @@ # control_types -This is a complete list of all control types available in the audio form, as well as a breif description of what they do. +This is a complete list of all control types available in the audio form, as well as a brief description of what they do. * ct_button: a normal, pressable button. * ct_input: any form of text box. diff --git a/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/text_entry_speech_flags.md b/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/text_entry_speech_flags.md index fe12f609..fc3baefd 100644 --- a/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/text_entry_speech_flags.md +++ b/doc/src/references/include/Auditory User Interface (form.nvgt)/Enums/text_entry_speech_flags.md @@ -4,4 +4,4 @@ This enum provides constants to be used with the character echo functionality in * textflag_none: no echo. * textflag_characters: echo characters only. * textflag_words: echo words only. -* textflag_characters_words: echo both charcters and words. +* textflag_characters_words: echo both characters and words. diff --git a/doc/src/references/include/Auditory User Interface (form.nvgt)/Global Properties/audioform_word_seperators.md b/doc/src/references/include/Auditory User Interface (form.nvgt)/Global Properties/audioform_word_separators.md similarity index 60% rename from doc/src/references/include/Auditory User Interface (form.nvgt)/Global Properties/audioform_word_seperators.md rename to doc/src/references/include/Auditory User Interface (form.nvgt)/Global Properties/audioform_word_separators.md index 1eb9b2a1..91225a5c 100644 --- a/doc/src/references/include/Auditory User Interface (form.nvgt)/Global Properties/audioform_word_seperators.md +++ b/doc/src/references/include/Auditory User Interface (form.nvgt)/Global Properties/audioform_word_separators.md @@ -1,4 +1,4 @@ -# audioform_word_seperators +# audioform_word_separators A list of characters that should be considered word boundaries for navigation in an input box. -`string audioform_word_seperators;` +`string audioform_word_separators;` diff --git a/doc/src/references/include/BGT Compatibility Layer (bgt_compat.nvgt)/!BGT Compatibility Layer.md b/doc/src/references/include/BGT Compatibility Layer (bgt_compat.nvgt)/!BGT Compatibility Layer.md index b0f8144d..9eb0169a 100644 --- a/doc/src/references/include/BGT Compatibility Layer (bgt_compat.nvgt)/!BGT Compatibility Layer.md +++ b/doc/src/references/include/BGT Compatibility Layer (bgt_compat.nvgt)/!BGT Compatibility Layer.md @@ -62,7 +62,7 @@ Note that these functions don't map cleanly to how NVGT's API works. As such, su * string_to_upper_case: string.upper. * string_split: string.split. * string_contains: string.find. -* get_last_error_text: supersceeded by exxceptions. +* get_last_error_text: Superseded by exceptions. * string_to_number: parse_float. * string_compress: string_deflate. * string_decompress: string_inflate. diff --git a/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_2d_distance.nvgt b/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_2d_distance.nvgt index dd99b093..06aa67ba 100644 --- a/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_2d_distance.nvgt +++ b/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_2d_distance.nvgt @@ -9,7 +9,7 @@ ## Returns: double: the distance between the two points. ## Remarks: - This function uses the Euclidean distance formula, meaning it will return the possible closest distance bhetween the two points. + This function uses the Euclidean distance formula, meaning it will return the possible closest distance between the two points. */ // Example: diff --git a/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_3d_distance.nvgt b/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_3d_distance.nvgt index 19ec27f1..6d47d9d6 100644 --- a/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_3d_distance.nvgt +++ b/doc/src/references/include/Character Rotation (rotation.nvgt)/Functions/get_3d_distance.nvgt @@ -11,7 +11,7 @@ ## Returns: double: the distance between the two points. ## Remarks: - This function uses the Euclidean distance formula, meaning it will return the possible closest distance bhetween the two points. + This function uses the Euclidean distance formula, meaning it will return the possible closest distance between the two points. */ // Example: diff --git a/doc/src/references/include/File Reading (file_contents.nvgt)/!File Contents.md b/doc/src/references/include/File Reading (file_contents.nvgt)/!File Contents.md index 2956d902..6575c0c5 100644 --- a/doc/src/references/include/File Reading (file_contents.nvgt)/!File Contents.md +++ b/doc/src/references/include/File Reading (file_contents.nvgt)/!File Contents.md @@ -1,2 +1,2 @@ # File Contents Library -Fecilitates the easy reading and writing of strings in files. +Facilitates the easy reading and writing of strings in files. diff --git a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/!INI Reader and Writer.md b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/!INI Reader and Writer.md index 51d7fcff..f3079f62 100644 --- a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/!INI Reader and Writer.md +++ b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/!INI Reader and Writer.md @@ -1,4 +1,4 @@ # INI Reader and Writer This is a class designed to read and write ini configuration files. -I can't promise that the specification will end up being followed to the letter, but I'll try. At this time, though the order of keys and sections will remain the same, the witespace, comment, and line structure of an externally created ini file may not remain in tact if that file is updated and rewritten using this include. +I can't promise that the specification will end up being followed to the letter, but I'll try. At this time, though the order of keys and sections will remain the same, the whitespace, comment, and line structure of an externally created ini file may not remain in tact if that file is updated and rewritten using this include. diff --git a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/get_bool.md b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/get_bool.md index bb5fa378..18ca8af1 100644 --- a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/get_bool.md +++ b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/get_bool.md @@ -6,7 +6,7 @@ Fetch a boolean value from the INI data given a section and key. ## Arguments: * string section: the section to get the value from (if any). * string key: the key of the value. -* bool default_value = aflse: the default value to return if the key isn't found. +* bool default_value = false: the default value to return if the key isn't found. ## Returns: bool: the value at the particular key if found, the default value if not. diff --git a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/load.md b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/load.md index 0bce5470..5e24458d 100644 --- a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/load.md +++ b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/load.md @@ -5,7 +5,7 @@ Load an INI file. ## Arguments: * string filename: the name of the ini file to load. -* bool robust = true: if true, a tempoerary backup copy of the ini data will be created before saving, and it'll be restored on error. This is slower and should only be used when necessary, but insures 0 data loss. +* bool robust = true: if true, a temporary backup copy of the ini data will be created before saving, and it'll be restored on error. This is slower and should only be used when necessary, but insures 0 data loss. ## Returns: bool: true if the ini data was successfully loaded, false otherwise. diff --git a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/save_robust.md b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/save_robust.md index 4d5e6eb4..d790a404 100644 --- a/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/save_robust.md +++ b/doc/src/references/include/INI Reader and Writer (ini.nvgt)/classes/ini/methods/save_robust.md @@ -1,5 +1,5 @@ # save_robust -This function is similar to `ini::save()`, but it first performs a temporary backup of any existing data, then restores that backup if the saving fails. This is slower and should only be used when necissary, but should insure 0 data loss. +This function is similar to `ini::save()`, but it first performs a temporary backup of any existing data, then restores that backup if the saving fails. This is slower and should only be used when necessary, but should insure 0 data loss. `bool ini::save_robust(string filename, bool indent = false);` diff --git a/doc/src/references/include/Music System (music.nvgt)/classes/music_manager/methods/play.md b/doc/src/references/include/Music System (music.nvgt)/classes/music_manager/methods/play.md index bf1e6251..9d8adefa 100644 --- a/doc/src/references/include/Music System (music.nvgt)/classes/music_manager/methods/play.md +++ b/doc/src/references/include/Music System (music.nvgt)/classes/music_manager/methods/play.md @@ -12,11 +12,11 @@ bool: true if the track was able to start playing, false otherwise. ## Remarks: Music tracks are specified using a very simple string format ("filename; flag; flag; option1=value; option2=value; flag; option3=value..."). -Options are deliminated by "; " excluding quotes. The only required setting is the track's main filename, which must be the first option provided. It does not matter in what order any other options or flags are set, the only rule is that the track's configuration string must start with it's main filename. +Options are delimited by "; " excluding quotes. The only required setting is the track's main filename, which must be the first option provided. It does not matter in what order any other options or flags are set, the only rule is that the track's configuration string must start with it's main filename. The difference between a flag and an option is that a flag is usually just a simple switch E. "stinger; ", while an option usually consists of a key/value pair e. "startpos=2.9" -When deeling with fades, values are usually in milliseconds, while when deeling with track durations they are usually specified in float seconds E. 4.555 for 4555 milliseconds. +When dealing with fades, values are usually in milliseconds, while when dealing with track durations they are usually specified in float seconds E.G. 4.555 for 4555 milliseconds. ### List of possible options: * stinger; disables looping @@ -26,11 +26,11 @@ When deeling with fades, values are usually in milliseconds, while when deeling * f=ms; causes the track to fade in at first play, ms=number of milliseconds the fade should take to complete * p=pitch; Sets the pitch of this track, defaults to 100. If this track streams from the internet, make sure not to set this too high as this could result in playing more of the sound than has been downloaded. * v=volume; sets the starting volume for this entire track (0=full -100=silent) -* intro=filename; causes the audio file specified here to play before the main track file. By default the main track will begin playing immediatly after the intro track ends unless intro_end is specified. +* intro=filename; causes the audio file specified here to play before the main track file. By default the main track will begin playing immediately after the intro track ends unless intro_end is specified. * repeat=s; How many seconds before the end of the main track should the track repeat again? s=number of seconds (can include milliseconds like 4.681). When the track repeats, it will play overtop the remainder of the currently ending track. repeat=0 is the same as the loop flag, repeat=anything<0 is the same as stinger. If multiple of repeat, loop, stinger are specified, only the one specified last will take effect. * repeat_f=ms; If repeat is specified and is greater than 0, this option causes the end of the currently playing track to fade out as the repeated track begins to play, and specifies how many ms that fade should take to complete. * predelay=s; how many seconds (can include milliseconds) before the track should begin after it starts playing? * switch_predelay=s; Same as above, but only applies if a track was previously playing and the music system switches to this one. Defaults to 300. This and predelay are added together, but this variable is handled by the music manager instead of by this music track unlike predelay. * switch_f=ms; If the music system is playing a track and then switches to this one, how many milliseconds should it take for the previously playing track to fade out? Defaults to 400. -* intro_end=s; if intro is specified but the audio track specified by intro does not seemlessly transition into the main track, how many seconds (can include milliseconds) before the intro ends should the main track begin playing? The main track will not interrupt the remainder of the intro but will play overtop of it if this option is specified. +* intro_end=s; if intro is specified but the audio track specified by intro does not seamlessly transition into the main track, how many seconds (can include milliseconds) before the intro ends should the main track begin playing? The main track will not interrupt the remainder of the intro but will play overtop of it if this option is specified. * startpos=s; How many seconds (can include milliseconds) into either the intro track if specified else the main track should the audio begin playing E. seek? diff --git a/release/include/form.nvgt b/release/include/form.nvgt index ef9e1a6e..41345832 100644 --- a/release/include/form.nvgt +++ b/release/include/form.nvgt @@ -99,7 +99,7 @@ enum control_event_type { event_slider } //characters that should be considered word boundaries. -string audioform_word_seperators = "_ .,!\\\"/[{()}]=\n"; +string audioform_word_separators = "_ .,!\\\"/[{()}]=\n"; //prespeech callback, if set the given function will be called right before the form speaks. funcdef void prespeech_callback(audio_form@ f); //control event callback @@ -2835,9 +2835,9 @@ class control { } if (echo_flag == textflag_characters || echo_flag == textflag_characters_words) speak(input_box_speak(find_appropriate_character(character)), true); - if (audioform_word_seperators.find(character) > -1 && (echo_flag == textflag_words || echo_flag == textflag_characters_words)) { + if (audioform_word_separators .find(character) > -1 && (echo_flag == textflag_words || echo_flag == textflag_characters_words)) { int temp_position = cursor - 1; - while (temp_position > 0 && (temp_position >= text.length() || audioform_word_seperators.find(text[temp_position - 1]) < 0 && text[temp_position - 1] != "\n")) + while (temp_position > 0 && (temp_position >= text.length() || audioform_word_separators .find(text[temp_position - 1]) < 0 && text[temp_position - 1] != "\n")) temp_position--; string word = read_word_from_position(temp_position); if (password_mask != "") { @@ -2857,9 +2857,9 @@ class control { text[cursor] = character; if (echo_flag == textflag_characters || echo_flag == textflag_characters_words) speak(input_box_speak(find_appropriate_character(character)), true); - if (audioform_word_seperators.find(character) > -1 && (echo_flag == textflag_words || echo_flag == textflag_characters_words)) { + if (audioform_word_separators .find(character) > -1 && (echo_flag == textflag_words || echo_flag == textflag_characters_words)) { int temp_position = cursor - 1; - while (temp_position > 0 && (temp_position >= text.length() || audioform_word_seperators.find(text[temp_position - 1]) < 0)) + while (temp_position > 0 && (temp_position >= text.length() || audioform_word_separators .find(text[temp_position - 1]) < 0)) temp_position--; speak(read_word_from_position(temp_position), echo_flag != textflag_characters_words); } @@ -3054,7 +3054,7 @@ class control { if (text == "") return -1; int i = cursor; - while (i= 0 and audioform_word_seperators.find(text[i]) > -1) + while (i= 0 and audioform_word_separators .find(text[i]) > -1) i--; for (i; i > -1; i--) { if (i >= text.length() || i == cursor && !word && text[cursor] == "\n") @@ -3064,7 +3064,7 @@ class control { return i + 1; else return i; - } else if (!word && text[i] == "\n" || (word && audioform_word_seperators.find(text[i]) > -1)) + } else if (!word && text[i] == "\n" || (word && audioform_word_separators .find(text[i]) > -1)) return i + 1; } return 0; @@ -3323,12 +3323,12 @@ class control { speak("Blank"); return; } - bool found_boundary = audioform_word_seperators.find(text[cursor]) > -1; + bool found_boundary = audioform_word_separators .find(text[cursor]) > -1; int new_word = -1; for (uint i = cursor; i < text.length(); i++) { - if (audioform_word_seperators.find(text[i]) > -1) + if (audioform_word_separators .find(text[i]) > -1) found_boundary = true; - else if (found_boundary && audioform_word_seperators.find(text[i]) < 0) { + else if (found_boundary && audioform_word_separators .find(text[i]) < 0) { new_word = i; break; } @@ -3384,9 +3384,9 @@ class control { return ""; int word_end = 0; for (int counter = position; counter < text.length(); counter++) { - if (word_end < 1 && (audioform_word_seperators.find(text[counter]) > -1 || text[counter] == "\n")) + if (word_end < 1 && (audioform_word_separators .find(text[counter]) > -1 || text[counter] == "\n")) word_end = counter; - else if (word_end > 0 && (audioform_word_seperators.find(text[counter]) < 0) && (text[counter] != "\n")) { + else if (word_end > 0 && (audioform_word_separators .find(text[counter]) < 0) && (text[counter] != "\n")) { word_end = counter; break; } diff --git a/release/include/int_to_byte.nvgt b/release/include/int_to_byte.nvgt index 226e75ec..43876ac4 100644 --- a/release/include/int_to_byte.nvgt +++ b/release/include/int_to_byte.nvgt @@ -1,6 +1,6 @@ /* Note that better methods for this probably exist in nvgt, keeping it for backwards compatibility. This is an attempt to give bgt the ability to support easy conversion from 32 bit intigers to the 4 bytes but in a binary format. This could be used to access data from dll structures, to compress data instead of using string_to_number, or to access data from binary files. For example, you should be able to use this to parse a PCM wave header, etc. - Note: I can't promase that this will be 100 percent, but I will make it as close as possible to the real thing, such as what you could do in c++, python, or most every language accept bgt. All I'm saying is to not be surprised if I mess something up. Feel free to distribute or modify this code in any way shape or form you wish unless otherwise spesified, though credit would be apreciated if you use it. + Note: I can't promise that this will be 100 percent, but I will make it as close as possible to the real thing, such as what you could do in c++, python, or most every language accept bgt. All I'm saying is to not be surprised if I mess something up. Feel free to distribute or modify this code in any way shape or form you wish unless otherwise spesified, though credit would be apreciated if you use it. */ //Just a couple of globals.