Throw ONScripter away! ONSlaught released!

Post about your projects or talk about mirror moon projects that haven't been announced yet... or something.

Moderator: Staffers

Totally hardly posted
Posts: 9
Joined: June 27th, 2007, 1:49 am
Location: Argentina

Throw ONScripter away! ONSlaught released!

Unread post by Helios » December 31st, 2008, 4:17 am

Have you ever been frustrated by ONScripter and its lack of Unicode support while trying to translate any of the many ONScripter VN? You have probably even tried some hackish solution, like modifying fonts and such.

Well, you need to struggle no more. Yours truly has just finished his greatest project so far: ONSlaught.

Is that sum Unicode? You're damn right it is! Needless to say, you can use any font you need to represent the glyphs of your target language.

You can visit the project site at

Excerpt from the PFAQ (Possibly Frequently Asked Questions):

Q: What is ONSlaught?
A: ONSlaught is a visual novel engine based, from a high-level perspective, on
NScripter and ONScripter. It therefore tries to be as compatible with them as
However, some features where removed, changed, or deprecated ("deprecated" means
that a new, better version exists, but the old one is left for backwards
compatibility), usually for the sake of portability, simplicity, or to better
fit the new internal design.

Q: What parts are (in)compatible with O/NScripter?
A: These are the most prominent changes:
* Syntax. Some syntax has been changed. The changes are detailed in
* Commands. Some commands have been changed or removed. The changes are
detailed in doc/Changes.txt
At the time of writing, only 45% of the commands are unimplemented (this
only accounts for commands that are intended to be implemented some time in
the future).
* The script reading code is almost 100% compatible. A certain encryption
method that relied on the binary image of the executable was left
unimplemented for being considered impractical.
* Archives with ASCII-only names are read correctly. I believe O/NScripter
uses Shift JIS to store file names in archive headers. This has yet to be
* "nscrflog.dat" and "gloval.sav" are read correctly, but written back in a
format O/NScripter can't read. "nscrflog.dat" is written back as
"nonsflog.dat". "gloval.sav" is written back as "global.sav".
* Only a narrow range of save game files are supported. Namely, versions
200-202. Save game files are written in a format O/NScripter can't read.
* "envdata" (whatever it is) is ignored.

Q: What new features does ONSlaught have that O/NScripter didn't?
A: ONSlaught's main purpose was to add Unicode support to O/NScripter, so it's
not particularly feature-rich (it has, of course, more features than
These are the most prominent new features:
* Unicode support. Onslaught supports all characters in the range U+0000 to
The following encodings/code pages are supported:
ISO-8859-1 (code page)
UCS-2 with or without BOM (Unicode encoding)
UTF-8 (Unicode encoding)
Shift JIS (code page)
Future releases may add more encondings or code pages, and/or the
possibility to add more through some interpreted language (probably
* Non-monospace font support.
* A few new commands.
* Debug mode allows script writers to view the values of variables and to run
commands a few commands from the console. The verbosity of the engine can
be changed through the command line, or through a file that simulated the
command line.
* Images may have an alpha channel. As simple as this sounds, this was not
supported by O/NScripter. For an image to have transparency, it was
necessary to add the alpha plane to the right of the bitmap.
* When drawing to the screen, all processors are used to speed things up.
* Through a clever programming trick, it's possible to run a script at a
different physical resolution than its logical resolution. For example, a
script that was designed to be ran at 640x480 can be scaled up to 1280x1024
without changing the script or the data.

Q: Why should I use ONSlaught instead of O/NScripter?
A: Unlike O/NScripter, ONSlaught was designed from the start to support European
languages, and any other language written from left to right and from top to
bottom, which luckily covers most of the world's languages. For example, it
can't be used to display Japanese in its classical top-to-bottom, right-to-left
style, or Arabic, which is bidirectional. This is important if one intends to
write a script in a language other than English or Japanese, as it's often
necessary to use characters that can't be represented in Shift JIS. Spanish, for
example, uses accentuated vowels, umlaut, and an N with a tilde. None of these
can be represented in Shift JIS.
If you intend to write a script in a language that uses any of these glyphs --
for example, for the purpose of translation -- then you should definitely use
ONSlaught also correctly displays any font, regardless of width of the
individual glyphs, which is a plus for aesthetics.
These reasons are, of course, only relevant for script writers. End users have
no reason to stop using their current engine.

Master of Bad Puns
Posts: 1845
Joined: October 25th, 2004, 6:27 pm
Location: Netherlands

Re: Throw ONScripter away! ONSlaught released!

Unread post by Message » December 31st, 2008, 10:53 am

Helios wrote:Q: What parts are (in)compatible with O/NScripter?
A: These are the most prominent changes:
* Syntax. Some syntax has been changed. The changes are detailed in doc/Changes.txt
Doesn't that kind of... You know, make the whole point invalid? The reason NScripter games are so easy to translate is that you don't need to rewrite or recode anything. If you go and change the syntax, you might as well stop calling it 'based on NScripter', as it has become an entirely new VN gaming engine. o__O

Totally hardly posted
Posts: 9
Joined: June 27th, 2007, 1:49 am
Location: Argentina

Unread post by Helios » December 31st, 2008, 11:49 am

The changes in syntax are of course minimal. Most games should not even notice something has changed.
Example: Variable names can only have latin alphabet characters (A-Z and a-z), underscores, and numerals anywhere but as the first character in the name.
There was little harm in using a rule like this, since most variables will be something like this anyway.

An important example is strings, which were changed in a manner that should be unnoticeable to already translated games:
Strings: Only things inside of quotes are considered strings. Only these two characters are treated as quotes: " (Unicode code point U+0022), ` (Unicode code point U+0060). It's possible to use one quote inside of a string that uses the other kind of quote: `This is a whole "string" because the inner quotes, being of a different kind, are ignored.`U+0060 is also used to print lines when it's the first non-whitespace character in a line.

I didn't say it was compatible because I felt like it. "Compatible" in this case means that only games at the sides of the normal distribution should be unable to run. Most games should be playable without much hassle.

Post Reply