Start the Engines!
|#26 by donkeyskin|
2019-07-17 at 05:38
|Can we fill the engine field to releases that have yet to be released if the information is known?|
|#27 by eacil|
2019-07-17 at 05:55
|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
|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
|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
|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
|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
|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 eacil|
2019-07-21 at 20:55
|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
|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
|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
|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 eacil|
2019-07-27 at 22:28
|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
|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
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?
You must be logged in to reply to this thread.