FFB Packet "PT_EFOPREP"

Yes, very possible that vJoy can handle only one active effect.

But all other FFB packets have enough effect information.
Exception: changing an "type specific" parameters (this packets refer to some effect or to all possible effects; Similar problem have "PT_EFOPREP" packets).

enum FFBOP have "EFF_SOLO" (msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.idirectinputeffect.idirectinputeffect.start(v=vs.85).aspx: "All other effects on the device should be stopped before the specified effect is played. If this flag is omitted, the effect is mixed with existing effects already started on the device").

I tried to use "EffectBlockIndex" to distinguish between effects, but it was always "1" or unknown (not effect reports: PT_CTRLREP, PT_BLKFRREP, ...).


Another my problem: vJoy often disable callback function. It occur sometimes on startup, sometimes after some time. I solve this by using timer (interval 100 ms) that causes FfbRegisterGenCB. Possible this work of Direct Input in "exclusive" mode.

And another problem: Ramp Force. This only one effect that causes SlimDX "E_INVALIDARG" exception. Possible this bug in SlimDX.

virtual I managed to get a working feeder with FFB support, using vJoy in C# and I had similar problem with determining what "PT_EFOPREP" refers to. I won't be able to go into details because it's not fresh in my memory, but IIRC "PT_EFOPREP" refers to previous EFF_REPORT packet. So I ended up storing the previous EFF_REPORT packet until a new packet arrives. FFB_REPORT has EffectType field by which you can determine to which effect "PT_EFOPREP" refers to.

Regarding vJoy disabling callback, i'm pretty sure there is a bug in your code, because I never experienced this (and I had users running my feeder/receptor for hours).

P.S. I suggest you use FfbMon app (part of vJoy) to monitor packets, then use something like FFB inspector and send an effect. You will see the order of packets (and order is important).

AFAIK there is no real benefit of loading multiple effects of the same type in memory of device. Even if you could find a scenario where that is needed, not all wheels handle that too well. So at least in my implementation, there is no such problem as you described, since there is only one ET_CONST loaded in memory, then if EFF_REPORT has EffectType ET_CONST, I'm stopping that effect. I did experiment with SharpDX and SlimDX only briefly but I didn't like how things are done there and abandoned them.
Now I use WGI (which is good for Windows 10 , but nothing else) and basically start by loading one effect of each type in memory of device, and then modify parameters on the fly and start or stop them. Effect parameters can be updated without actually having to repeatedly load and unload the effect, so it's kinda neat.

So the real question is, what would be the purpose of loading multiple effects of the same type in memory of device and can you predict the behavior of various devices under those conditions?

P.S. RampForce works fine here for WGI. I get an error, when trying to send RampForce through FFB inspector (which uses SlimDX) though.

Some examples:

========================================
Example 1 (About "stop" of runned effects)
========================================
Variant 1
- Create and start a effect1 with duration = infinity;
- Create and start a effect2 with duration = infinity;
- Stop effect1.

Variant 2
- Create and start a effect1 with duration = infinity;
- Create and start a effect2 with duration = infinity;
- Stop effect2.

Both variants have same report packets.

========================================
Example 2 (About "start" of preloaded effects)
========================================
Variant 1
- Create and download a effect1;
- Create and download a effect2;
- Start effect1.

Variant 2
- Create and download a effect1;
- Create and download a effect2;
- Start effect2.

Both variants have same report packets.

========================================
Example 3 (About changing type-specific parameters)
========================================
Variant 1
- Create and start a effect1 (Square) with duration = infinity;
- Create and start a effect2 (SawtoothUp) with duration = infinity;
- Change type-specific parameters "PeriodicForce" of effect1.

Variant 2
- Create and start a effect1 (Square) with duration = infinity;
- Create and start a effect2 (SawtoothUp) with duration = infinity;
- Change type-specific parameters "PeriodicForce" of effect2.

Both variants have same report packets.

I don't have any physical FFB devices, so I desire to make 1:1 model - full playback DirectInput FFB actions. Currently it probably impossible. Probably it don't necessary in most cases. Simple I don't known how many games or user applications use multi-effects and how they use them.
I work on "prediction system" to partially close multi-effects problem. For example: "stop" command probably not refer to ended effect (actually I can stop a effect in any time, even when it ended and get "stop" report packet).