• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

RC5 Question - reference d.net ID

JWMiddleton

Diamond Member
I want to get clarification on a question I have. I have noted that your d.net id is in the dnetc.ini file. If you change that id with blocks in the buff-out file, what id gets credit for the blocks? It appears that whatever id is active while the block are being processed would get the credit. Is that correct? If you wish to change the id should you flush first, then make the change?
 
The ID is hard-coded in to any completed blocks. So, yes, whatever ID is active when the packet is completed gets the credit. So, you could change the ID and restart in the middle of a packet and the one changed to would be credited.

Say you did 500 blocks for rc5@tacube.com[img]i/expressions/face-icon-small-smile.gif[/img], and then changed to one@tacube.com[img]i/expressions/face-icon-small-smile.gif[/img], and did another 500 blocks. When you flushed the 1000 blocks they would correctly go to the two different ID's.

Russ, NCNE
 
im not 100% sure on this, but i used to think whatever ID you had when you flushed got the credit, but someone told me the ID gets coded into each block, and cant be changed.

edit: speeling
 
The blocks are encoded with your ID as the client processes them. Changing your ID will not change what is in the buff-out file and will only apply to those currently in-progress or in the buff-in file.

Sorry, but your out of luck there.
 
Thanks guys! I wonder if this situation has caused some folks to think they lost block becuase they didn't understand how this worked...hmmm In otherwords the blocks didn't go where they had assumed they were being directed.
 
JWM, there are reasons for this. Shared buffer files is the main reason, so that shared buffers dont get credited to the client that flushes them, but to the clients that process them.
 
Back
Top