They can't take action against it unless somebody uses illegal methods to reverse their system. Like using leaked source code. Look at Wine and Samba.
They can't take action against it unless somebody uses illegal methods to reverse their system. Like using leaked source code. Look at Wine and Samba.
I was talking more about steam bans and achievement/stats resets, rather than legal action.
There is always a risk, but it's very unlikely.
I've been messing with SW things for a few months now. My achievement/stats have never been reset, and my account has never been disabled or banned.
Edited:
That doesn't mean it's 100% safe. If anyone using OSW for some shady purposes gets an account banned then I really can't be held responsible.
Yes, Steam has to run with this.
It's a lot of easier using Open SteamWorsk to access the steam-api than reverse engineering the SteamFriends protocoll.
Edited:
I know about this function and I'm actually using it frequently. But I need this var, so I can do
CFriend myFriend = CFriend("STEAM_0:1:23456789")
There, I convert the steam-id string back to uint64 cummunityID in order to get CSteamID(communityID) and then a CFriend Object.
I think that's very hard. Messages are encrypted (First RSA afaik and then AES - Not entirely sure). I once saw a partially reverse-engineered protocol in the net and it wasn't really easy.
Is there any way to stop the chat window popping up when you send a message?
The idea is to make use of Steam's own DLLs to connect to Steam Friends.
So you won't even touch the protocol.
Isn't that what I said?
that's what that means
Probably yes. Find all windows with C++ and close that one which just popped up (that's the "hard way" I think). I'll run to this issue anyway later, when I'll start coding on the actual trillian-plugin. My plans are to stop the popups when you are not ingame (detecting "ingame", when the SteamFriends Overlay is on).
start steam with -console and then type log_ipc 1
for maximum fun
Oh, nice!
Edited:
Just a random question: What are the interfaces numbered? Example: ISteamFriends001 to 3 or similar. Isn't ISteamFriends enough? I saw, all interfaces differ a little bit. But why not making one huge with all necessary stuff in it?
Not quite, I meant "building your own Steam client using the same DLLs Valve's client uses for its functionality".
So basically you'd have to be able to run the DLLs but you don't have to run the Steam client and don't have to use its API so you could basically do everything.
From what I understand it's just the ones that VALVe have frozen a version of, presumably for backwards compatibility when something gets removed.
That way, older games that expect (for example) getFriendCountOrWhateverTheFuctionIsCalled() to return only the number of people on the users friends list don't break with the new version that expects the 'type' of friend wanted to be passed as well.
The most recent version should be used in a new project, VoiDeD just makes available exactly what is in the DLLs.
If you want the cutting edge (possibly changing) version, use the IClientFriends interface.
Ah, I understand. So it's safer, to use the _00X interfaces instead.
Except VoiDeD can't get the login process to work.
Yeah that's why I asked if someone's gotten it to work in the first place![]()
VoiDeD, you already worked with SteamFriends but in C#. I now ran into an issue, where I need to get new messages from SteamFriends.
I looked into the API and it looks like ISteam006 is suitable. It has SetNotificationCallback as member and I think that one can be used to get messages from steam-friends. At least, I did not find any other method yet where I can add a callback in order to obtain received messages.
Well, my problem now is, if I use STEAM = (ISteam006*) ClientFactory(STEAM_INTERFACE_VERSION_006,&error);, my program compiles but instantly crashes :(
What can be the cause? Or is there an even better method in getting received messages?
That would indeed be the hard way. I'm not sure of any other way to do it through OSW.
It's Valve's process of allowing updates to interfaces without breaking existing code.
If a game uses an older version of ISteamFriends because it was built for that version a long time ago, any changes to the vtable layout will break that game. So instead Valve uses interface versioning throughout the vast majority of their code, even in the source engine itself.
This way they can release new interfaces and any new consumer code can use it, and old code will still stay functional.
Internally they're named all sorts of things, such as CAdapterSteamInterface###, CSteamInterfaceV###, and other ones, but their steamworks SDK will only contain an interface definition for a specific version, so you're limited to using only that version. OSW is basically all the releases of the SDK rolled into one, with additional stuff you'll never find in the SDK, like IClient and the steam.dll headers.
Most of the time, yeah, but there are sometimes functions in the older interfaces that aren't available in the new ones.
Not recommended. Each steamclient update has the potential to change IClient interfaces. These aren't versioned like the ISteam counterparts. IClient are assumed to be compiled for use in one consumer: steam.exe, so they make no reserves when changing things.
I try my best to update the IClient interfaces to their latest versions, but I still don't recommend using them. They're provided for that "oh cool look what steam can do" feeling.
Yep.
ISteam is an interface provided by steam.dll, but isn't what you want at all. That's the interface for starting your own steam engine instance and going through the login process and other related goodies.
What you're looking for is ISteamFriends::GetChatMessage.
There is an example in the Chat Log code, which is C#, but you should be able to convert it to it's C++ equivalent easily.
http://code.assembla.com/steamworks/...s?rev=88#ln236
Well, ISteamFriends::GetChatMessage seems not to be "event-based". I thought there is some type of method where I supply a callback. I also found many structs related to ISteamFriends which seem to be "used" for "hook like" callbacks.
Well, if there is no other way, I'll just constantly check for updates then with this method. Thanks.
VoiDeD:
Is there a method now other than running an infinite-loop checking for updates of messages using C++? If so, do you have an example?
I actually can't really answer this from your C# example (and I also never coded C#)
Edit
After looking through the code, I found Steam_BGetCallback(PIPE,&callbackMsg,&steamCall) which I now want to run frequently and check for updates concerning messages.
But when I want to run my program, it tells me it can't fiend steamclient.dll (and only, when the above function is used) - Just when I put the exectuable into the same directory as Steam, it runs well - But that shouldn't happen. (Used system is Win7x64Pro).
The same problem happens with the Callback Logger:It only runs within the Steamfolder. But I need to run Steam_BGetCallback outside of that folder.
You do indeed have to copy over steamclient.dll, as well as tier0_s and vstdlib_s.dll.
Maybe you can use LoadLibrary of the Windows SDK and pass the full path. Don't forget to free the library.
Really? Oh shit. I thought I could interface with Steam as I did before. Well, then I'll just always copy a latest version of those dlls to my app.
Isn't there a way, making my app pretend to have these dlls in it's working directory? I tried ZeekyHBomb method, but it seem to have no effect.
Edit
Seems like I was acting too fast. I just read about GetProcAddress in combination with LoadLibrary. I'll give this a try tomorrow. Going to bed now. Thanks for the help.
Steamclient.dll is entirely event driven via callbacks. You poll for new callbacks with Steam_BGetCallback, and it will give you the minimal amount of data (steam ids involved with the chat message, chat id, etc in the case of a friends message) you need to investigate the data further as necessary.
This allows consumer code to not request additional data if it's not deemed necessary, thus saving on bandwidth if there is alot of behind the scenes data.
You can use steam_api.dll to register callbacks through some of the macro's located in Callbacks.h, but you'd have to ask AzuiSleet for the specifics. You'll still have to run a loop and call SteamAPI_RunCallbacks to have it process any callbacks for you.
As azu said, you need vstdlib_s.dll, and tier0_s.dll in order for steamclient.dll to sucessfully load.
There is an alternative to manually loading all these libraries. You can make use of steam_api.dll, and call the SteamAPI_Init function. This will locate the steam directory, and load all the libraries necessary. That way you can redistribute your program with just steam_api.dll.
If you still want to load everything manually, SetDllDirectory and LoadLibrary.
This was really helpful. Thank you very much.
If you don't want to worry about copying dlls and all the other jazz, you can skip steam_api and instead use the CSteamAPILoader class recently added. It loads the proper steam dlls and sets the DllDirectory. It returns the steamclient factory, so you can get ISteamClient or whatever else you want. (which you then CreateSteamPipe etc)
Code:CSteamAPILoader apiloader; CreateInterfaceFn clientFactory = apiloader.Load(); if(clientFactory == NULL) ... client = (ISteamClient008 *)clientFactory(STEAMCLIENT_INTERFACE_VERSION_008, NULL);
Oh jeez, that looks even easier than I tried it. Thank you :)
Am I late?
Yes. Very.
That's in reference to the Source SDK anyway. More so, with such a restrictive EULA, projects like SourceMod and MetaMod: Source are still alive and kicking.
Can somebody tell me something about this code
Because i dont have this folders, and project doesnt compile =(Code:#include <boost/cstdlib.hpp> #include <boost/unordered_map.hpp>
Another stupid question:
Code:[SERVER] Loading item DB... Unable to load DB, empty!
I wasn't able to code the last few days. Today I used your tips (VoiDeD and AzuiSleet) and now everything works as expected. Thank you once more.
http://img689.imageshack.us/img689/3007/nsteamfriends.png
Events and all work like a charm. Going to write a prototype trillian plugin dll the next few days before I polish the code and make it "safe" (now, it fails e.g. when I close steam or steam-friends and start it again).
I also have to figure out, how to avoid the "One or more Steam Applications are running"-Error when I try to shutdown steam. Maybe also event based.
Not related to OSW really, but is that VS theme downloadable somewhere?
Thanks guys.
How can i increase a timeout for idler clients?
You mean the syntaxhilighting? Because it's just Visual Studio 2008 Professional with modified visual style: Go to Extras/Preferences/Editor/Text coloring (I needed to translate this into English - It might be different).
There you can chose the font and colors.
He means did you download it somewhere? If not give him your VS settings export![]()
Well, I did not DL it anywhere (I made it myself). I did not even knew, there is a settings-export.
I'll export it later.