Start the Engines!

Posted in

#26 by donkeyskin
2019-07-17 at 05:38
< report >Can we fill the engine field to releases that have yet to be released if the information is known?
#27 by Ileca
2019-07-17 at 05:55
< report >Ask yourself: can you fill the resolution field of TBA releases if the information is known?
#28 by roadi
2019-07-17 at 14:50
< report >Most (all?) of Favorite's games use their in-house "FVP" or "Favorite View Point System" engine; this seems to be currently missing.
#29 by netonetori
2019-07-18 at 20:07
< report >Ok, how does one start hook-coding? what is the hook-coding 101? is it safe to download these packages? are most open-source and all that?
#30 by andredron
2019-07-19 at 03:30
< report >Add engine Rugp....

All games for Windows are company Age made on this engine...


It would be better to add the ability to link to YouTube for viewing op video projectsLast modified on 2019-07-19 at 04:02
#31 by spidey01
2019-07-20 at 15:41
< report >Seems to be a nice change to how engines are handled. Especially given that different releases of a game may have different engines for various reasons.
#32 by beliar
2019-07-21 at 18:04
< report >I have a question regarding the NScripter engine. Should we consider it and ONScripter separate engines or not (and let's not forget a PONScripter fork)? Currently there is one separate entry for ONScriter in the Engine list, with all the others being NScripter.

The problem here is that like many of the other fields, the engine field cannot be modified if the release is a patch, which implies that it uses the same engine as the original release. Now, with almost no exceptions, all the English patches of NScripter games actually port the games to ONScripter.

As an example, Tsukihime is originally an NScripter game, but the English translation runs on ONScripter.

For convenience maybe it would be prudent to consider all the NScripter forks to be the same engine, which eliminates the problem, but the engine name leaves a lot to be desired. Maybe "NScripter and derivatives" would clear the issue?

As an alternative solution, the engine field could be made editable for the patches, but that creates another problem, as you pretty much cannot tell which fork is used in each case without actually downloading the game. And I assume most people will just ignore the issue and will use NScripter by default, regardless of the actual fork used. Hence I'm leaning towards the first solution. Thoughts?
#33 by Ileca
2019-07-21 at 20:55
< report >I tried to add PONScripter to the Russian and French patches of SnU without success too.
The interest of knowing a game uses NScripter is that you will have to port it to P/ON if you want to translate it. It's not open source contrary to P/ON and PON as far as I remember uses a slightly different scripting language, which means you can't just paste your N script into PON. Also, still afair ON doesn't support unicode while PON does.
I see no problems with ONScripter and PONScripter having their own entry. I prefer we consider the patches to be opened, maybe with a rule stipulating that only the patches changing the engine should use the engine field?
#34 by butterflygrrl
2019-07-24 at 00:37
< report >given that there are a reasonably large number of games using it, can tyranoscript be added to the auto-dropdown list? people typing it in manually would be likely to put tyranobuilder instead and get things confused.
#35 by hinoe
2019-07-27 at 00:12
< report >Is any form of version number support planned? If so, it should probably be a separate field altogether so as to make it completely optional.
#36 by Yorhel
2019-07-27 at 06:35
< report >Regarding NScripter and forks: I think we should just keep it simple. The current engine field isn't complex enough to handle that kind of detail and I'm not sure it's worth being that detailed in the first place. Keeping track of engine/script compatibility isn't a goal right now, and would be way too complex anyway (I can imagine there are games using a slightly modified engine that is incompatible with the others, etc).

Versions: Same, no versions at the moment (but if we do that, then yeah it definitely should be separate field)
#37 by Ileca
2019-07-27 at 22:28
< report >I see a problem with the engine filter being strict.
You can't find a compilation marked as "SiglusEngine, RealLive" if you input SiglusEngine alone.

Apart from clicking directly the engine from the engine page that is hidden in the release form (4 clicks to reach it), this filter is not really convenient to use (strict means case sensitive too and go remember where are the capital letters in "codeX RScript").Last modified on 2019-07-27 at 23:28
#38 by hinoe
2019-07-31 at 08:47
< report >Regarding version, that seems fine. Having version information is nice, but I agree that it's very low priority. Perhaps, if it ever becomes a thing, it might be useful to make it a freeform field where more data than the version number itself can be added; I'm thinking in terms being able to specify things like forks. That would solve the problem of how to handle forks, imo.

I envision it like this: the engine field would stay as it is, a sanitized field, with all the positive points of that choice, such as allowing easy search; meanwhile, the engine version field would have the most detail possible, and since you already have the sanitized field separately, that wouldn't cause any interference. So, for the Tsukihime English translation example mentioned, the engine field would simply say "NScripter", whereas the version would be allowed to say "ONScripter v. xyz". If a game is known to have a modified version, it could even say something akin to "ONScripter v. xyz (customized/modified)".
#39 by fllthdcrb
2019-08-20 at 08:27
< report >@23
For example, many of KID's VNs seem to run on nameless in-house engines. And they clearly didn't use a completely new engine for each one, though it may not be feasible to determine how similar they are without close examination.
To expand on that, I've looked at the scripts for Never7 and Ever17 (enough to be able to disassemble them, mostly), and I can say, the scripts are very similar, with most of the same bytecode instructions, but also some different instructions at a high level, for different features and such. Perhaps they're different versions of the same codebase, at different stages of evolution, or something. But then, both have script files with the same magic number (which is kind of a name), so that's confusing. So, should they be considered distinct, or not? How would one name them?
#40 by tigershark
2019-09-15 at 14:51
< report >Not sure if it's of any use but just wanted to add that Unity3D has a more or less "rolling release" methodology since 2017 (after version 5), so adding versions would be quite a mess.
On other note, while Unity is by no means a pure vn engine, new modules like "timeline" with "playables" make implementing one easy enough to justify doing it in-house.
#41 by alto
2019-09-15 at 20:48
< report >The engine release search filter auto complete doesn't completely work. You can't select anything but the first engine via clicking. I think it's because there's no id sent for the engine so the css ids are all "ds_box_null".Last modified on 2019-09-15 at 20:49
#42 by Yorhel
2019-09-16 at 07:12
< report >Fixed.
#43 by rampaa
2019-09-30 at 01:16
< report >Can there be an "Engines to exclude" field?

Also, being able to include/exclude multiple engines -like producer filter- would be more useful.
#44 by savagetiger
2019-10-20 at 00:41
< report >TyranoScript and LiveMaker can probably be added to the automatic dropdown now considering the amount of vn's that they are used in.
#45 by Yorhel
2019-10-20 at 08:25
< report >Yup, done.


You must be logged in to reply to this thread.