Auto-Compose Program Exists?

[Daimos]

I have too **** many +1's.... I spent hours composing and I barely make a dent. Is there a program or macro/bot anything that will auto-compose this junk for me?

[BaussHacker]

You could use a mouserecorder or make your own macro. Should not be that hard.

[_StarScream_]

Go to google and type in Macro REcorder.

[Real~Death]

Originally Posted by Daimos

I have too **** many +1's.... I spent hours composing and I barely make a dent. Is there a program or macro/bot anything that will auto-compose this junk for me?

doesent co farmer have a plugin that does this

[Chalkie]

Originally Posted by Real~Death

doesent co farmer have a plugin that does this

Yup.

[_StarScream_]

Originally Posted by Chalkie

Yup.

Is ther anything COF cant do?

[InfamousNoone]

Originally Posted by _StarScream_

Is ther anything COF cant do?

If there is and it's reasonable shoot me a PM

[Kiyono]

Originally Posted by InfamousNoone

If there is and it's reasonable shoot me a PM

So just wondering but why did you decide to ditch your own proxy and use CoFarmer?

[Coatl 2.0]

go to low def mode on co, and you wont have to wait as long to compose...it removes the stupid animation

[InfamousNoone]

Originally Posted by Kiyono

So just wondering but why did you decide to ditch your own proxy and use CoFarmer?

The overall way the project is designed is much better. It was designed with the intent of supporting multiple characters (with that well over 10, 20, 30).

JProxy was designed with the intent of only being used with the COClient (meaning 2-3 clients) and in no way designed to support standalone.

COFarmer uses XAML for it's form, which is essentially a form drawn with DirectX, not Win32-API. This also means it utilizes GPU instead of CPU where it can, improving the performance quite significantly.

The way the over all bot was developed flexible enough for me to to develop the Plugin API to allow plugins to integrate their own panels into the bot, where as JProxy was not intended to give such support, but expected plugins to spawn their own window-sub-sets. Another thing was, the bot was designed in such a way where it though of how to manage reconnection while plugins still were doing work. I really had no way of accounting for this in JProxy, nor did I ever intend on implementing reconnection.

Over all like I said, the design was better. Oh, and it's completely managed code. It was a huge hassle having to always implement natively (JProxyHelper.dll) and then port up to managed-code (JProxyNativeInterface.dll)

[Kiyono]

Originally Posted by InfamousNoone

The overall way the project is designed is much better. It was designed with the intent of supporting multiple characters (with that well over 10, 20, 30).

JProxy was designed with the intent of only being used with the COClient (meaning 2-3 clients) and in no way designed to support standalone.

COFarmer uses XAML for it's form, which is essentially a form drawn with DirectX, not Win32-API. This also means it utilizes GPU instead of CPU where it can, improving the performance quite significantly.

The way the over all bot was developed flexible enough for me to to develop the Plugin API to allow plugins to integrate their own panels into the bot, where as JProxy was not intended to give such support, but expected plugins to spawn their own window-sub-sets. Another thing was, the bot was designed in such a way where it though of how to manage reconnection while plugins still were doing work. I really had no way of accounting for this in JProxy, nor did I ever intend on implementing reconnection.

Over all like I said, the design was better. Oh, and it's completely managed code. It was a huge hassle having to always implement natively (JProxyHelper.dll) and then port up to managed-code (JProxyNativeInterface.dll)

Ah I see, makes sense.