Help us plan OpenMW's future

Feel free to discuss here about news on our blog
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Help us plan OpenMW's future

Post by AnyOldName3 »

I imagine a lot of mod developers will have kept tweaking their script until it worked, whether or not they knew if it was their fault or the compiler's. I don't think too many mods will have been shipped which totally trusted the vanilla compiler and had no testing done at all yet also have a large enough user base for anyone to notice if we don't have perfect support. However, I do think that there are probably a bazillion mods with wonky scripts and basically correct bytecode just due to lots of testing and refinement.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Help us plan OpenMW's future

Post by Zini »

In some cases though, the broken behavior is entirely a result of the CS' compiler's lax validation of scripts. That is, in such cases the bytecode itself came out fine, it's just a mess when trying to interpret the source text.
I am going to challenge this statement. Example: viewtopic.php?f=40&t=5219

The plugin seemed to have worked with vanilla MW, but only for some values of "working". It seems that the _ql_glider2 instance was placed in the wrong orientation (meaning not the orientation the mod author had intended). Apparently that was only a minor issue, but it was still a bug.

Just because vanilla compiles a script to bytecode and users don't notice any problems does not mean that the bytecode is correct. It could be. But there is no way of knowing for sure without looking at the script itself. And if it needs to be looked at anyway, it can be fixed as well.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Help us plan OpenMW's future

Post by AnyOldName3 »

It's also possible that the airship was supposed to be how it appeared in vanilla, but because the compiler cocked up, the author adjusted his values to account for it. I.e.
  • Lets position this airship using a script.
  • Huh, that looks wrong...
  • I guess I'll tweak the script, even though the documentation says it's correct.
  • It looks fine now. That was weird.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Help us plan OpenMW's future

Post by Chris »

Zini wrote: 03 Jul 2018, 07:34 Just because vanilla compiles a script to bytecode and users don't notice any problems does not mean that the bytecode is correct.
I don't mean that the bytecode will always be correct, just that (I would think) more scripts' bytecode will be correct compared to the sources. That is, there would be no instance of a script's bytecode being incorrect while the source is valid, but there can be some instances of the bytecode being correct while the source is incorrect (i.e. difficult to parse correctly, causing problems for OpenMW to support).

And if we're going to have a separate parser/converter for oldscript anyway, using the bytecode would seem to handle more cases correctly with less work, while using the original sources would require a lot more work to replicate the vanilla CS's crappy parser. I would also imagine correcting for any anomalies/errors in the bytecode will be easier than trying to figure out how the vanilla CS parsed the source.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Help us plan OpenMW's future

Post by AnyOldName3 »

I'm not thinking of having the bytecode translator instead of the source translator, but as an optional tool in the CS which says 'Run your ESP through this to get an omwaddon with the same behaviour as vanilla, including all the bugs and which it'll be a pain to fix the bugs in'. The point would be that we can replicate the errors in vanilla without having to introduce any errors on purpose or disable any warnings or otherwise dirty the clean, recommended workflow.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Help us plan OpenMW's future

Post by Zini »

That is, there would be no instance of a script's bytecode being incorrect while the source is valid
Lol. You wish.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Help us plan OpenMW's future

Post by Chris »

Zini wrote: 03 Jul 2018, 15:04
That is, there would be no instance of a script's bytecode being incorrect while the source is valid
Lol. You wish.
I'm curious if you have any examples of this. I don't think I've heard of a case before where the script source is syntactically clean with no coding errors, but the vanilla CS produced broken, buggy bytecode.
NullCascade
Posts: 121
Joined: 16 Jan 2012, 07:58

Re: Help us plan OpenMW's future

Post by NullCascade »

$0.02 from someone who uses the crap out of bytecode, while OpenMW ignores it: 100% go for the bytecode. You have two (now three) compilers with different output. mwscript is an ugly bastard where coders complain constantly that they have to do crazy things like compile most scripts in one compiler, then some other script in another compiler. If mwscript were consistent and reliably interpreted throughout the last decade and a half of modding, I'd be looking directly at that and doing some fancier things. But it's not, it's a nightmare.

It's very simple. You go code -> bytecode -> engine's "VM".

Step one (code -> bytecode) is inconsistent because of multiple shitty compilers.

Step two (bytecode -> VM) is always consistent. How you got there might not be, but it's what the content file shipped and expects to run.

So, you favor step 2, where you know what you have is completely unambiguous.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Help us plan OpenMW's future

Post by Zini »

Chris wrote: 04 Jul 2018, 01:42
Zini wrote: 03 Jul 2018, 15:04
That is, there would be no instance of a script's bytecode being incorrect while the source is valid
Lol. You wish.
I'm curious if you have any examples of this. I don't think I've heard of a case before where the script source is syntactically clean with no coding errors, but the vanilla CS produced broken, buggy bytecode.
An obvious case are the various size limits (e.g. nesting depth, length of an if block and so on). The vanilla compiler tends to just stop. Code that goes over the limit is ignored. Ran in that quite a lot while working on Redemption. We noticed the problem immediately because usually 80% or more of the script functionality was missing. But if the script is only a bit over the limit, the problem might go unnoticed.

Another one of which I don't have all the details at hand right now is related to scripts with many variables. The n-th variable is defective. Don't remember the value for n. 32 or 34 maybe. Probably a weakness in the design of the VM.
Loriel
Posts: 179
Joined: 28 May 2015, 00:44

Re: Help us plan OpenMW's future

Post by Loriel »

Zini wrote: 04 Jul 2018, 09:41Another one of which I don't have all the details at hand right now is related to scripts with many variables. The n-th variable is defective. Don't remember the value for n. 32 or 34 maybe. Probably a weakness in the design of the VM.
n=34

See http://en.uesp.net/wiki/Tes3Mod:Scripti ... h_Variable - the page lists a few other potential problems.

Loriel
Post Reply