Warband Refined & Enhanced Compiler Kit (v1.0.0 @ Mar 01, 2015)

Users who are viewing this thread

Could someone please test this compiler with their code, in a battle. I need to see if it's just my code somehow doing it, or any code compiled with this compiler.

Edit: Something isn't right, I just ran a custom battle, it's slow-mo and the horses were two stories tall.
DB2C9CBA7288ED11ED3C067D4F52418DB3E78A15
 
Weird. Cause I'm using this compiler for months already with Native Expansion and have yet to see this behavior. Still, extremely curious, I'd never even thought such an effect is possible at all.  :mrgreen:
 
Update. I suspect I found the issue with jacobhinds' code.

Temporary patch is available here. Full download links have been updated in the starting post.

Now Wookie's problem is a really tricky one as I have no idea what could be causing that. :smile:
 
Sure I did. However I'm extremely hesitant to introduce special processing based on variable naming scheme - such things always manage to backfire in my experience. Besides I have already checked both scripts that compiler reports to have unused variables, and in both scripts there are genuine unused variables which serve no purpose whatsoever. For example:

Code:
  # script_debug_variables
  # Input: two variables which will be examined by coder, this script is only for debugging.
  # Output: none
  ("debug_variables",
    [
      (store_script_param, ":unused", 1),
      (store_script_param, ":unused_2", 2),
    ]),

Are you really sure compiler shouldn't complain about this? :smile:

Oh, and as of 0.6.1 the compiler already ignores locals if they've been used as a dummy iterator in try_for_range cycle. Otherwise there would be far more notices of this sort when compiling Native.
 
I still think it should ignore the variable not being used in all cases yes, because the very purpose of naming it ":unused" is to avoid compiler errors. Ignoring the dummy iterators was a good idea though, and you can certainly make the argument that 'unused' vars are only useful for those loops anyway, so it's up to you.
 
WookieWarlord said:
Could someone please test this compiler with their code, in a battle. I need to see if it's just my code somehow doing it, or any code compiled with this compiler.
Highly seconded. I definitely never experienced anything like this with Native Expansion, and neither did any of NE players.

And a couple of questions.

Do you use mission_set_time_speed or mission_time_speed_move_to_value operations anywhere in your module?

What horse_scale() do you have defined for your horses?

What happens when you compile your mod with vanilla compiler and run the same custom battle?
 
I have not used any of those operations, including adjusting horse scale. That same custom battle when compiled with the vanilla compiler works normally, no slow-mo, no giant horses.
 
Then I'm officially without any ideas. :smile:

Can you send me your module system under non-disclosure? I'm really interested to see what could have such a result.
 
Lav said:
Then I'm officially without any ideas. :smile:

Can you send me your module system under non-disclosure? I'm really interested to see what could have such a result.
I'd like to get other people to weigh in, to determine that it is specific to me, first.
 
WookieWarlord said:
Yo so I've discovered what I find to be a hilarious unintended consequence. When compiling my code with your compiler, battles happen in slow motion, matrix style. No lag or anything, just slow motion. This is even true for multiplayer when server and client both have the code compiled with your compiler.

Note that this doesn't happen when the exact same code is compiled with the default build_module.

:lol:
Can you make a video of this?
 
I literally haven't changed anything to do with horses, or mission speed, so it's the default native stuff. Is there a chance your compiler would handle the order of item and mission template definitions though? You don't use the ID_* files which have to do with the order of tuple definition, so perhaps it's something to do with whether I add new items to the start or end of the items.py. I've also moved the multiplayer_bt mission template right to the bottom.
 
If you're using 'copy_n_forget' files without any additional modification of module files, then W.R.E.C.K. behaves similarly to vanilla compiler, i.e. it does make use of ID_*.py files and recreates them at the end of compilation.

As for changing order of mission templates in the file I honestly have no idea - I never examined multiplayer code closely enough to tell if it has any effect on the game or not. But you said the issues persist in single-player custom battles as well, which means the problem is probably with the horses after all, not with mission templates. Unless you have some post-processing Python enhancements to module_mission_template.py file.

In short, I simply have too little information to go with, and so far your case seems to be an isolated incident. Native compilation with W.R.E.C.K. doesn't yield such results, neither for me nor for anyone else who has tried it so far, so the issue is caused by some of your changes being compiled fine by vanilla but not by W.R.E.C.K. But the first point of debugging is still identifying your modification which is at the root of this, and I can't help you in any way unless you give me some info to work with.
 
BTW this is what I got by simply increasing horse scale by a factor of 10 in the module files:



Looks eerily similar, but has nothing to do with compiler. :smile:

If you don't want to send the entire module system, can you at least send me your header_items.py and module_items.py files?
 
Back
Top Bottom