omnetpp | OMNeT++ Discrete Event Simulator

No, OMNeT++ does not have ready to use parameter to stop a simulation after specified number of events.
However, it is possible to achieve that behaviour programmatically, by adding the following piece of code to every handleMessage():

The methods sendDown( ) and sendDelayedDown( ) are used to send the messages to other nodes in omnet++. May be you are calling handleSelfMessage( ). Including code here may help.

update: My Guess went right. There is no handleSelfMessage() definition. scheduleAt() invokes handleSelfMessage() and its not there.

upvote if I am correct

Using the header files does not say anything about where the actual shared object file is present. You must add -lzmq (or whatever the library is called) to your linker flags in the project.

The easiest way is to create a makefrag file in the source folder (where the Makefile is generated) and add

As long as your string does not contain a space, add backslashes before quotes, i.e.:

I think this error might be due to more than one factor so you should provide more information. I had something similar while using incompatible versions of Omnetpp and Veins. Maybe you'd want to share your host system and the versions you're using. For me was enough to test different versions of the program and the frameworks. Also import/reference one framework at a time, so you know if it's a compatibility fault. E.g. I could not use veins and inet at same time for some reason.

Another hint: From your screenshot I see a red cross on the "subprojects" folder so maybe you set that as a NED source file directory? Make sure these boxes are selected.

NED Files directory setting

I'd suggest to follow this video for veins_inet cooperation: https://youtu.be/mGvhbrw05sQ?list=PLaBPUIXZ8s4AwAk5EelikvvyG4EzX2hpx

The handleMessage() method is never called by the simulator because you never send a message to any of your modules so there is nothing to deliver. Note that sendDirect() calls are only present in your handleMessage() methods, so until one of them is called, there will be no messages to deliver. The way a simulation should work is that SOME code MUST create messages or events (e.g. timers) in the initialize() methods because that is the method that is called on the simulation start.

In node::initialize() you create a timerMessage but never schedule it so it is not delivered to handleMessage(). (not that it would help because the handleMessage() code would explicitly ignore it):

The gateway module creates and schedules a self message, and that is delivered to the gateway::handleMessage() but it's not handled and most likely falls through to the else case at the end and then just does nothing.

I cannot add too much to the actual error here as I don't have experience with Veins, but I know that linking several models on Windows is a pain. One possible route for you:

If you are okay with upgrading to Windows 11, you can actually install Ubuntu in the Windows System for Linux and WSLg on Windows 11 now supports GUI programs out of the box. You will be able to continue to use the Linux version (along with the IDE and qtenv) without any further magic. In my experience, CPU performance is the same on native Windows vs. virtualized Linux. I/O performance (like disk writing, compiling etc.) are a LOT faster in a virtualized Linux container than on native Windows (yes, NTFS sucks). The only drawback with virtual VMs were that you had to allocate the memory statically between host and guest and you were running two desktop environment that eat the memory. But this is not the case with WSLg. It allocates the memory dynamically and on Linux it does not run a separate desktop but rather integrates with the main Windows desktop (using wayland instead of X).

As strange as it sounds, but IMHO the best way to actually run OMNeT++ on Windows is to run the Linux version inside WSLg.

On Windows 10, graphical programs in WSL are not (yet?) supported out of the box (fingers crossed that MS backports this), but you still can install an XServer and if properly configured you will get similar experience. (There is a chapter about how to install WSL and XServer in the InstallGuide of OMNeT++ 6.0pre13). There is also a project called GWLS that aims to ease the XServer installation for WSL that is even easier than the steps in the install guide.

This is a known issue in 6.0 preview 11 and 12, caused by the fact that the same directory is added multiple times in the NED path. My guess is that ../.. and ../../../showcases is the same directory. I'm not sure where that ../.. is coming from, but try to get rid of it.

As a side note, this issue was fixed in 6.0pre13 version.

The maxCommunicationRange is the parameter of the MediumLimitCache submodule of RadioMedium. The medium limit cache is an optimization, so that the radio medium doesn't have to calculate the ranges with each transmitter/receiver pair from the power and sensitivity, but you can specify some values to use (by default the medium limit cache is not used.) These ranges (max communication and interference range) are used for further optimization, such as the range filter (rangeFilter parameter in the radio medium). The filter can be set so that transmissions which are beyond the max communication range are not sent to the nodes.

In your example, if you want the radio medium to not send any transmissions to nodes beyond the max communication range, you also need to set the range filter to communication range (see the radio medium NED documentation).

So by default, the max communication range of the medium limit cache is not used, but the success of a transmission is calculated from the transmitter power, attentuation due to distance and the receiver sensitivity. To set a communication range, the power and sensitivity need to be fine-tuned.

However, you mentioned that it is important for the communication range to be a specific distance. For this, the UnitDiskRadio model might be better suited (if you don't care about other things about the transmissions such as signal attenuation). In this model, you can set specific communication ranges for each transmitter, and transmissions in the range are always successful, out of range they are never.