byteframe

thank you very much for checking it out.

It still leaks memory like mad, but I'm convinced it's my fault, even though it is ok with the older branch. I think it's something related to my chat handling. I'll keep trying.

Certainly.

What is the recommendation for listening to chat events? Should we switch to watching the events from the new chat component, or are the older events sufficient?

ok thank you for taking the time to test this out. if you cant find aything Ill have to resume banging my head against the wall on this

are they joined to a group chat? all my accounts currently are. Ill try one without.

sorry to whine, but I am suffering from a memory leak issue with the version 4 branch. After disabling all my code, except for one account logging in, (and doing nothing) it still leaks. I left the one idle account running doing nothing and after about a day or so it exceeded the ~1.5 GB of heap the node process (by default) can use. I then downgraded to 3.9.2 and it's fine now. I restored all the code and all the accounts are running and its been 12 hours now and memory usage is proper and garbage collecting is happening. It kinda seems like garbage collecting wasnt happening with v4, but I'm not sure exactly, as I didn't play around much with --expose-gc, yet. I quick glance suggested I couldnt just hack around this with manual global.gc() calls, but that would have probably been fine with me. This happens on Linux and Windows, and im using node lts 10, linux from now on. What version does the the doctor use, btw? I wish could be of more help, I tried generating heapdumps, but It locked up my machine, and I cant seem to get 'node-memwatch' installed/compiled, which had some event I maybe later could listen to that detects leaks. All the accounts are 'assigned/joined/ to a steam group chat however, a idle ghost town chat with nobody chatting in there, so maybe its likething related to (other) group chat events. Ill try to test this out next with an account who is not joined to a group chat. thanks for looking.

ok thanks Ill look at the protobufs and see if I can ape at least the sending function, after I fix a memory leak somewhere in my code.

how exactly does one send chat messages to a broadcast? do they function like group chats?

huzzahs are in order.

Oh ok, I thought it was going to be a situation like before whereby the 'old webchat' was available in steam-community, ehh, because it was 'web based'.

Do you think you will 'port' the chat code to node-steamcommunity? What's the future of the relationship between these two modules going forward?

I got some error (when I didnt in maybe beta 1 or beta 2) when calling getInviteLinkInfo. I no longer need to call that function and didnt remember to copy the error. the 'processChatGroupState' call in 'getInviteLinkInfo' (line #120) fails because the 'chat_rooms' property of the state object is undefined. I think I saw it in another place from the info result, so maybe something changed. Other than that, the chat stuff in so far as I'm been using it is working well. I like it!

Does the 'joinGroup' function to join a group chatroom function yet? It appears that it might be unimplemented.

'OS' is improperly capitalized in line 38 of components\helpers.js (getInternalMachineID)? Where is the documentation for the new chat stuff again?<3

i wouldnt understand whats going on, but you basically lose your web session very quickly, and have to add your own logic to retry your web calls after calling webLogOn again when the session expires. It will prolly be sorted in the new version.

oh boy I can play with the new chat stuff? can I install this branch with npm? edit: nvm I got it installed, now I can get a jump on updating my code.

Also, some calls to endpoints do not fire the sessionExpired event, but just report 'NotLoggedOn' in the error result. Also straight up GET calls to steamcommunity.com pages will not show from the view of the user if the session is lost, and you can detect this by the presence of 'g_steamid = false' in the body.

Assuming this is all the new normal, (and pending any built in mitigation from a future node-steam-user update), you will all have to implement some kind of keep-alive system within your own code. First, once you establish a web session, you should run an authorized POST call to an endpoint, if you're code isnt going to do that very soon thereafter. For a dummy, I recommend 'my/commentnotifications' with your sessionid and action: 'markallread', I guess. This first call seems to be important for keeping the session alive for whatever is the normal time, lets say a minute. Without that call I've had bots get sessionExpired just several seconds after getting their first session. Overall though, the idea is such that If you don't do anything on your websession it will 'shortly' logout, (sessionExpired: Error: Not Logged In), If your bot is active throughout, it generally doesnt seem to lose the session. If not, after a period of inactivity, the bot's next call to an authorized endpoint on steam will fire off the sessionExpired event. Typically you will have defined that event handler to call webLogon again; but the call still fails though and can cock up your code accordingly. You can implement a retry system that waits a second for the new session before retrying, or you can maybe prevent the failures by knowing when to, or otherwise prempting them by calling webLogon manually. I do the former, because I can coordinate on one call to retry, blah blah, but chances are others might have more pain. I doubt using setInterval to periodically refresh the session is a good idea. Also this is only affecting me in my calls to community.httpRequest, I dont use the trade modules or know how those are affected.

as best I can work this out (i'm stupid) web sessions seem to be expiring really quickly now. maybe less than a minute, if there is no activity. successful calls to endpoints that require authentication will keep the session alive, but it has to more or less be continually doing stuff. failing that, the user will have to use webLogOn to refresh.

I can also report this new problem of 'web sessions constantly expiring' or something to that effect. I thought it was just me.

// Turns out my handlers werent applying, and I am now able to get a response from the server. tf2._handlers[TF2Language.NameBaseItemResponse] = function(body) { console.log('response:'); console.log(body); }; var bb = new ByteBuffer(8+4+Buffer.byteLength('wut') + 1, ByteBuffer.LITTLE_ENDIAN); bb.writeUint32(735); //Sapper Defindex bb.writeUint64(coerceToLong(6470016595)); // my tag's item id bb.writeCString('wut'); // the message tf2._send(TF2Language.NameBaseItem, null, bb);// outputs response: ByteBuffer { buffer: <Buffer 00 00 05 00 00 00>, offset: 0, markedOffset: -1, limit: 6, littleEndian: true, noAssert: false }// but doesn't perform the desired renaming. ive believe Ive tried all combinations of ordering the variables. I'll keep banging on it., but I'm still a tad out of my depth, notice me senpai.

tf2._handlers[TF2Language.NameBaseItemResponse] = function(body) { console.log('responded'); }; bb = new ByteBuffer().writeUint64(coerceToLong(6470016595)).writeUint32(735).writeString('wut'); tf2._send(1019, null, bb); // I figure I also need to supply the item id of the tag... // nothing happens yet, still banging my head against it. does this look bad? // will I get a response only on success? // Sorry I suck with these buffers, still.

ill try my best!

Hello Mr, McKay (and suboordinates). Can you please point me in the direction of the correct protobuf/method/recipe to apply name/descript tags to stock items? i found this in the language defintion: NameItem: 1006: NameBaseItem: 1019, I assume I need the latter one, but I can't identify the correct protobuf/recipe to use them. Thank you!