Fwatch Request List

[faguss 65]

Reading the sqm doesn't work if the mission is packed into a pbo-file or when it is not known if the mission is in the missions-folder or in the 'users\username\missions', right?

See this.

if you can make in any way a 3d sound comunications

No such things with Fwatch. You might want to look into this.

[faguss 65]

Update on your requests:

 

Would there be a way to rise the water level beyond what's possible by simply changing the in-game date, even as far as to flood the whole island?

 

:mem setweather

 

 

Could you make a command that finds current values for rain, overcast and fog from the memory?

 

:mem getweather

[sukhoi191 30]

Hey faguss!

 

Do you think it's possible to launch another application from CWA / OFP thread and send the output to the game? I have already tried to do it simplest way possible, as I'm not the biggest fan of WinAPI:

char buffer[256];
FILE *fp = _popen("test.exe -c xxx", "r");
QWrite("[", out);
int first = 1;

while (fgets(buffer, 256, fp))
{
  if (first == 1)
  {
    QWrite("\"", out);
    first = 0;
  }
  else
  {
    QWrite(",\"", out);
  }

  QWrite(buffer, out);
  QWrite("\"", out);
}

QWrite("]", out);
_pclose(fp);

test.exe prints all of passed parameters. I want to return them as an array to CWA - it doesn't serve any purpose, but that's just for the sake of simplicity of testing.

CWA crashes after executing this code. Here's the reason from crash dump:

 

The thread tried to read from or write to a virtual address for which it does not have the appropiate access.

 

I can't really find anything useful on Google. The error is obvious, yet I don't have any idea on how to fix it or if it's even possible to do.

What's also worth mentioning, it doesn't crash on _popen. It's fgets(buffer, 256, fp) that messes things up.

Is there some "special" folder which won't cause any cries about privileges when CWA tries to execute something in it?

[faguss 65]

Hey faguss!

 

Do you think it's possible to launch another application from CWA / OFP thread and send the output to the game?

 

Check :file wget command. It creates a pipe to which an external program is writing its output data. Then it passes that information along so it goes to the game as a return value of the :file wget command.

 

I wouldn't recommend using it because the game is stopped while third-party program is running.

[sukhoi191 30]

Thanks for the answer!
 
I'm surely gonna check it out this weekend. I must admit wget is a pretty clever approach.
 
While being at it, my idea is to manage most mission's logic externally by another application. I think it would be much cleaner, easier to maintain and powerful than writing the same thing using only OFP's scripting language. Not to mention all of the other possibilities, such as using a database.
 
It would work like this:

• Create a new "agent" function in fwatch source code (it would send input acquired from OFP's script, then wait and read the output from external application).
• Input would consist of a command name and optionally parameters, let's say: IS_OWNER PLAYER CAR1.
• External application reads the input.
• External application's parser processes the input and calls proper method / function / whatever accordingly.
• fwatch gets an output from external application, for example as an array, which I've already mentioned in my previous post.

Main advantage of this solution: it would be very, very flexible. One could provide it's own program without the need to change anything in fwatch. Just provide the path to the executable, make sure it's there, parse the input (which could be totally different than my aforementioned proposal) and return something in format of OFP's array.

 
One more thing comes to my mind - what about upgrading fwatch project files to Visual Studio 2015? This may seem as a trivial question, yet I guess you have some good reasons to keep it in the older format? Surely upgrading isn't as easy as using officlal VS's project upgrade feature, as it doesn't compile anymore. I didn't really try that much to fix it, but I will in the free time.

 

Adding described external logic to fwatch could also work, but it would limit us to using C++ as a main language and we would have to recompile it every time and swap DLL, instead of doing so only with our external program in case of any changes.

[faguss 65]

my idea is to manage most mission's logic externally by another application

Good luck.

 

What about upgrading fwatch project files to Visual Studio 2015? I guess you have some good reasons to keep it in the older format?

Vektorboson has made source for the newer VS but I had issues with the latter so I moved to the old one. Also OFP is an old game and I'd like to have compatibility with old computers.

[sukhoi191 30]

Good luck.

Thanks. I'm not sure if it's not an irony, but I just really like this idea and I'm curious if it's possible to do or not, even if it won't work efficiently enough to actually use it in missions.

 

Seems like even predefined function that calls wget doesn't work for me, it crashes CWA with the same reason as fgets mentioned in one of the previous posts. I wonder if it's not an OS-related issue (Windows 10). Microsoft just loves to gradually restrict access for applications, which generally isn't a bad idea, yet I miss Windows 98 in this matter. One could delete whole Windows folder, while Windows was still running.

 

I think I'll try to get some info on MSDN forums.

[VanoXVZ 0]

Hello! Thank you so much for your work! Through this work I was able to make ideas real. You can see on my youtube channel https://www.youtube.com/channel/UClQweo3ZqWpBw12tDPz138A/videos. The question is whether the function changes the gamma? The aspect ratio is in fashion thanks to your tool changes automatically. And gamma correction do I need to change in the night time. In this video you can see how it is necessary ))  

 

 

 

 

 

[cpt_smagnet 10]

Hi, many thanks for your hard work, but is it possible to consider a backward compatibility in the future updates?

As we've discussed in a thread next door, I found my own mod based on Fwatch 1.14 incompatible with 1.15.  I've done an quick check and noticed that a lot of ways I've applied the Fwatch commands no longer work.

 

For example, I used to call the ":file read" function by this way:

in a certain.txt in fwatch\mdb, I put:

    KeyShortcut1=SHIFT SPACE

and in the script I went:

    _k = loadFile format[":file read blabla.txt %1",KeyShortcut1];
    _str = format ["%1",_k];

That way I got the script to pick up the variable as a string, and it worked fine before 1.15.  In 1.15, by simply using loadFile I will get a "_fwatch_error=blabla" before any of the extracted strings.

 

For another example, I used the ":srng" pretty often, but now...I've been trying to find out how ":string cut" works, and it's been almost 1 hour in this thing and I couldn't get it to work.  The demo case for the command is pretty neat, but doesn't help...

 

And also, when adding or updating a new command, please also provide a simple but complete showcase showing how that command works, like ":string cut begin:1[optional] end:2[optional] blabla", it help a lot better than the current "dialog" style (at least that's what would really look clean and fast to a slow mind like me).

 

Many thanks again!

[faguss 65]

On 5/1/2018 at 5:55 PM, cpt_smagnet said:

consider a backward compatibility in the future updates?

 

Negative.

 

On 5/1/2018 at 5:55 PM, cpt_smagnet said:

KeyShortcut1=SHIFT SPACE

 

Strings should be saved with quotation marks so:

loadFile Format [":file write blabla.txt %1 ""%2""", "KeyShortcut1", "SHIFT SPACE"]

and then you load it with:

_str = call loadFile Format [":file read blabla.txt %1", KeyShortcut1];

 

On 5/1/2018 at 5:55 PM, cpt_smagnet said:

I've been trying to find out how ":string cut" works, and it's been almost 1 hour in this thing and I couldn't get it to work.  The demo case for the command is pretty neat, but doesn't help...

 

What is the issue exactly? In the demo mission on the bottom you can see how command is used. For example:

\:STRING CUT start:0 length:2 text:test

 

On 5/1/2018 at 5:55 PM, cpt_smagnet said:

but complete showcase showing how that command works, like ":string cut begin:1[optional] end:2[optional] blabla"

 

That's what I show already in the demo plus there's also example on the website.

[damotr 49]

FWATCH_MEM_MULTI select 2

and

call loadFile ":mem getnv"

returns invalid value if PLAYER is in vehicle

• For airplanes it's always FALSE
• For cars it's always TRUE

 

Also: will there be option for fwatch to automaticlly redirect from "Singleplayer" to "Singleplayer/@modfolder", so after pressing it in menu player will be shown modfolder missions as default? It could be really useful.

[faguss 65]

On 3/23/2020 at 1:49 AM, damotr said:

returns invalid value if PLAYER is in vehicle

Fixed in Fwatch 1.16 28.03.20

 

On 3/23/2020 at 1:49 AM, damotr said:

will there be option for fwatch to automaticlly redirect from "Singleplayer" to "Singleplayer/@modfolder", so after pressing it in menu player will be shown modfolder missions as default?

No, I don't know how to do that.

[CTI player IF 32]

I have a request about language for Chinese. Chinese characters need 2 bytes for expression while other languages supported by OFP (except Korean) require simply 1 byte. Common method in dta/fonts doesn't support Chinese.

In early version of OFP (no later than 1.75) there's a bug in OFP EXE and Chinese agent used a trick basing on that bug. They manage to load a big texture (15.1MB, 2256x2352) using buffer. That big texture contains all Chinese characters.

I wonder whether it's possible to realize similar trick in Fwatch, using buffer trick or something else.

 

Regards,

IF

[faguss 65]

I don't think loading large textures is necessary. Instead you could map letters to different texture files. See convert_fxy and OFP Font Viewer.

[CTI player IF 32]

10 hours ago, faguss said:

I don't think loading large textures is necessary. Instead you could map letters to different texture files. See convert_fxy and OFP Font Viewer.

I've read your article and watched your video. But the problem is I need OFP recognize 2 bytes to know which character to display since there're thousands of characters. Is that still possible aplying only OFP original fxy design?

[faguss 65]

On 4/4/2021 at 10:02 AM, CTI player IF said:

I've read your article and watched your video. But the problem is I need OFP recognize 2 bytes to know which character to display since there're thousands of characters. Is that still possible aplying only OFP original fxy design?

No. OFP does not support Unicode.

[CTI player IF 32]

23 hours ago, faguss said:

No. OFP does not support Unicode.

So I still hope if there can be some trick to make OFP load 2 bytes as what CHN agend had done many years ago in version no later than 1.75 using buffer...