[SOLVED] __EVAL/__EXEC problem

[7erra 629]

Hi everyone,

 

I've got the following problem: I'm trying to use a macro to define the position of a control. It looks like this:

__EXEC(_curY = 0)
#define ADD_Y(VAL) __EXEC(_curY = _curY +0.1 +VAL)
#define CUR_Y __EVAL(_curY * GUI_GRID_H)
#define ADD_HEIGHT(HEIGHT) HEIGHT * GUI_GRID_H; ADD_Y(HEIGHT)

And then I'm using it like this (ui controls, part of a controlsgroup):

class controlClassName: RscSomething
{
	idc = 1000;
	x = 0;
	y = CUR_Y;
	w = GUI_GRID_W;
	h = ADD_HEIGHT(1);
};
class grp_watchFields: RscControlsGroupNoScrollBars
{
  idc = 7410;
  x = 0;
  y = CUR_Y;
  w = W_BORDER;
  h = ADD_HEIGHT(10);
};
// and
class seperator1: RscText
{
  x = 0;
  y = CUR_Y;
  w = W_BORDER;
  h = pixelH;
  colorBackground[] = {1,1,1,1};
};
ADD_Y(0)
class seperator2: seperator1
{
	y = CUR_Y;
};
ADD_Y(0)

While using it in a mission (description.ext) it works perfectly. Only when used as a mod it scrambles the order in the same way each time. I've checked the y values each time (mission and mod) and they were not equal for whatever reason, even though I copied the exact same content.

 

Anyone got experience with that? Do these macros not work in the config as intented?  I'd rather stick to them since it gives me the ability to rearrange the controls in any way I want in a fast and simple way but at the moment I'd be forced to go back and define each y value seperatly.

 

Thanks,

 

7erra

 

EDIT

Solution below: https://forums.bohemia.net/forums/topic/217330-config-macros-excecution-order/?tab=comments#comment-3299580

Also changed the title of the topic in case someone is searching for it

Edited June 28, 2018 by 7erra
solved

[reyhard 2082]

Are you using addon builder or pboproject?

[mikero 79]

your exec and evals are fine. But, configs are static entities, baked in concrete. desc.ext alters at game time.

 

this may, or may not, be an issue.

 

 

[7erra 629]

8 hours ago, reyhard said:

Are you using addon builder or pboproject?

Currently I'm using Addon Builder. I'd rather use pboproject but wasn't able to get my hands on a working version.

 

5 hours ago, mikero said:

configs are static entities, baked in concrete

Guess so. But the order of the classes shouldn't be changed as this would lead to potentially undefined base classes if you were suggesting this. Not sure about macros though.

[mikero 79]

On 6/17/2018 at 4:50 AM, 7erra said:

but wasn't able to get my hands on a working version.

 

'working' versions of the free tools are here

https://armaservices.maverick-apps.de/Products/MikerosDosTools/default

 

They are robust, stable, tools and have been in existence for over a decade. But, if you're having issues with these, please tell me about it.

On 6/17/2018 at 4:50 AM, 7erra said:

But the order of the classes shouldn't be change

 

That is correct. The *difference* between code in description.ext and any other type of paramfile is it can only be compile at game time. There *might* be some issue with exec/eval interpretation.

 

pixelH, W_BORDER, and GUI_GRID_W are not defined in the above example code

 

if any of these are generated from game-time values, that's where your problem lies.

 

pixelH is notably suspicious.

There is a reasonably good description of the limits of exec/eval, along with what it can do, in the documents that come with my tools. And, I congratulate you on using them at all, since most people are bewildered by them. Bis use them, heavily, but they are all compiled out of the code during binarisation which is why the community lacks any concrete examples of how they can be used.

 

 

 

[7erra 629]

14 hours ago, mikero said:

'working' versions of the free tools are here

Thank you very much. I'm now getting used to them.

14 hours ago, mikero said:

But, if you're having issues with these, please tell me about it.

Well I already got two: When using your tools the config won't compile with the following error:

config.cpp In File P:\<path>\file.hpp: Line 337 bad eval/exec

Rap or Derap error

This is the line:

tooltip = __EVAL( format ["Line 1%1 Line 2%1Line 3%1Line 4:""String in string""%1Line 5",toString [10]] );
//WORKS:
tooltip = "Text";

 

And another error: 

Each time I try to start Eliteness.exe

English (probably not correctly translated):

The procedure entry point "??0CStringU@@QEAA@PEBD@Z" could not be found in the DLL "C:\Program Files (x86)\Mikero\DePboTools\bin\Eliteness.exe"

 

Original (German):

Spoiler

---------------------------
Eliteness.exe - Einsprungpunkt nicht gefunden
---------------------------
Der Prozedureinsprungpunkt "??0CStringU@@QEAA@PEBD@Z" wurde in der DLL "C:\Program Files (x86)\Mikero\DePboTools\bin\Eliteness.exe" nicht gefunden. 
---------------------------
OK   
---------------------------
 

------------------------------------------

 

14 hours ago, mikero said:

pixelH, W_BORDER, and GUI_GRID_W are not defined in the above example code

Yeah I defined them elsewhere but didn't want to put the whole code in here for the sake of readability. Here they are:

Spoiler

// Default grid
#define GUI_GRID_WAbs			((safezoneW / safezoneH) min 1.2)
#define GUI_GRID_HAbs			(GUI_GRID_WAbs / 1.2)
#define GUI_GRID_W			(GUI_GRID_WAbs / 40)
#define GUI_GRID_H			(GUI_GRID_HAbs / 25)
#define GUI_GRID_X			(safezoneX)
#define GUI_GRID_Y			(safezoneY + safezoneH - GUI_GRID_HAbs)

// Default text sizes
#define GUI_TEXT_SIZE_SMALL		(GUI_GRID_H * 0.8)
#define GUI_TEXT_SIZE_MEDIUM		(GUI_GRID_H * 1)
#define GUI_TEXT_SIZE_LARGE		(GUI_GRID_H * 1.2)

// control related defines
#define DEBUG_W (22 * GUI_GRID_W)
#define DEBUG_H (28 * GUI_GRID_H)
#define L_BORDER (0.5 * GUI_GRID_W)
#define R_BORDER (21.5 * GUI_GRID_W)
#define W_BORDER (R_BORDER - L_BORDER)

 

The GUI_GRID is the default grid which BIS uses for dialogs themselves. pixelH is a variable which is used by the engine just like safeZoneH and has been introduced with the 3den Editor I think (at least it uses those variables). 

14 hours ago, mikero said:

game-time values

I'm sorry but I'm kind of noobish when it comes to technical terms. What is game time? And what are those values?

------------------------------------------

 

14 hours ago, mikero said:

There is a reasonably good description of the limits of exec/eval, along with what it can do, in the documents that come with my tools.

I've got all my knowledge from the BIS site and the BISim site. Haven't found your documentation yet though.

 

14 hours ago, mikero said:

And, I congratulate you on using them at all, since most people are bewildered by them. Bis use them, heavily, but they are all compiled out of the code during binarisation

Thanks . I always wondered why a3's configs were looking so strange with all this free space in gui configs.

 

Thank you for the time and sorry for the wall of text,

 

7erra

[mikero 79]

10 hours ago, 7erra said:

Haven't found your documentation yet though.

it's stated in the splash screen of ever tool of mine that you install.
start->programs->mikero->dos tools->nameOfTool->readme & docs

 

 

10 hours ago, 7erra said:

The procedure entry point "??0CStringU@@QEAA@PEBD@Z" could not be found

you have a mismatched version between the free depbo.dll and some crappy stale copy of eliteness taken from somewhere ten years ago, or worse, some borrowed copy of the subscriber tools, and that is explicitly prevented. download ALL the free tools

 

10 hours ago, 7erra said:

 

 

10 hours ago, 7erra said:

What is game time? And what are those values

 

the engine operates in two modes. one that uses precompiled assets (such as config.BIN, or prebinarised mission.sqm). These are loaded at game start. Game Time refers explicitly to items that are compiled when you start a mission. Notably, description.ext. Everything in there is compiled on-the-fly with values such as pixelH which (probably) would not be known at game start time.

10 hours ago, 7erra said:

tooltip = __EVAL( format

I don't support the sqf format statement for use in exec/eval. It *generally* refers to a variable or variables that cannot be precompiled into a binary asset. There is no mechanism in a binarised paramfile (mission.sqm or config.cpp) that can read and store a variable. something= "Format(blah)" is not the same thing, 'something'  is a constant, containing a string.

 

I personally think i have a bug here when dealing, specifically, with description.ext. You might be better off first trying to get this mission working with addon builder which doesn't check for any errors. genuine, or otherwise.

 

you can contact me further on skype or discord. anyone using exec/eval is worthy of all the help (s)he can get.

 

[7erra 629]

12 hours ago, mikero said:

you have a mismatched version between the free depbo.dll and some crappy stale copy of eliteness

So this is what it feels like to be the DAU 

 

12 hours ago, mikero said:

pixelH which (probably) would not be known at game start time

Wouldn't this also apply to the safeZone values then?

 

12 hours ago, mikero said:

You might be better off first trying to get this mission working with addon builder which doesn't check for any errors.

Done that. The tooltip works and has a line break.

 

12 hours ago, mikero said:

anyone using exec/eval is worthy of all the help (s)he can get.

 

12 hours ago, mikero said:

you can contact me further on skype or discord

Will do that via PN. If I get any results and solve the problems I'll get back to this thread.

[7erra 629]

Alright, with the help of @mikero I was able to solve the problem. When using __EVAL and __EXEC macros you can't rely on most engine commands. There are a few (mostly mathematical) ones that work though. A list of those can be found in the documentation for mikero's tools. With this in mind I changed my script accordingly:

#define ADD_Y(VAL) __EXEC(_curY = _curY +0.1 +VAL)
#define CUR_Y __EVAL(_curY) * GUI_GRID_H // moved GUI_GRID_H outside of the __EVAL brackets 
#define ADD_HEIGHT(HEIGHT) HEIGHT * GUI_GRID_H; ADD_Y(HEIGHT)

The __EVAL statement now only gets the current value of _curY instead of evalating GUI_GRID_H as well which isn't defined at game start. With this setup and everything else staying the same I now have a working __EVAL/__EXEC macro.

 

Thanks everyone for your time and props to mikero who seems to know everything