Re: [hlcoders] Interesting Hierarchy Bug
-- [ Picked text/plain from multipart/alternative ] I actually noticed this bug too, but it took me a while to realize that this was the same bug. I have a client-side only entity that's parented to a PVSCHECK entity and when the parent goes dormant the same behaviour occurs. I worked around the problem using the IPVSNotify interface (which in itself needed to be fixed, but the fix was easy) to re-link the entities whenever the dormant entity comes back into the PVS. Not a great solution, but it does work if you are stuck trying to fix this. I will try for a real fix, and post here if I come up with something clever. On 9/8/06, Daniel Menard [EMAIL PROTECTED] wrote: Well I've found an interesting hierarchy related bug. I figured I should notify the list about this one because it took me a while to wrap my head around it. I'm not sure if this has been fixed in the new SDK update (my mod is still running on the old codebase until we have time to merge in the new SDK), but I did a quick search in the known issues list and the new source and there doesnt appear to be a fix. It looks like a comment was left regarding parent attachments in the SDK update, but it doesnt resolve the parent issue. Anyways this bug occurs when a FL_EDICT_ALWAYS entity is parented to a PVSCHECK entity. When the PVS entity becomes dormant, it will call UnlinkFromHierarchy which will unlink it from its parent and do the same for all its children. The trouble comes when the PVSCHECK entity comes back into view. The entity loses its dormant state and it begins to move again, but the FL_EDICT_ALWAYS entity stops following (atleast client side). The reason being that the hierarchy system expects a full entity update from the server when it comes back into view (which would fix up the parent of the ALWAYS entity), but since the entity is always transmitted, it never receives the message to reset the parent because server side the parent never changed and the entity never went dormant. I have yet to find a concrete solution to the problem (though its only been about an hour or so since I figured it out), but I am beginning the think UnlinkHierarchy should never get called when an entity goes dormant in the first place. The EHandles would return NULL if the entity was ever removed and if anything is parented to an entity that is dormant it should stay where it is without unlinking. I'm weary of removing the call though, because it may break in some odd condition. I won't be able to make the change to my codebase until tomorrow, but some comments would be appreciated. I could add this to the Known Issues list in the wiki once a stable solution is found. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Interesting Hierarchy Bug
Not sure I understand what's bad about all of this. Do you have a concrete repro scenario from HL2DM, or does this only occur in mod code? At 2006/09/08 12:30 AM, Ben Everett wrote: Good catch! Add it to the bugzilla, as you have a better idea of what is going on than I do (busy bug fixing my own code). An interesting condition to say the least, anyone else w/ experience in this field wanting to comment? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Menard Sent: Friday, September 08, 2006 12:12 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Interesting Hierarchy Bug Well I've found an interesting hierarchy related bug. I figured I should notify the list about this one because it took me a while to wrap my head around it. I'm not sure if this has been fixed in the new SDK update (my mod is still running on the old codebase until we have time to merge in the new SDK), but I did a quick search in the known issues list and the new source and there doesnt appear to be a fix. It looks like a comment was left regarding parent attachments in the SDK update, but it doesnt resolve the parent issue. Anyways this bug occurs when a FL_EDICT_ALWAYS entity is parented to a PVSCHECK entity. When the PVS entity becomes dormant, it will call UnlinkFromHierarchy which will unlink it from its parent and do the same for all its children. The trouble comes when the PVSCHECK entity comes back into view. The entity loses its dormant state and it begins to move again, but the FL_EDICT_ALWAYS entity stops following (atleast client side). The reason being that the hierarchy system expects a full entity update from the server when it comes back into view (which would fix up the parent of the ALWAYS entity), but since the entity is always transmitted, it never receives the message to reset the parent because server side the parent never changed and the entity never went dormant. I have yet to find a concrete solution to the problem (though its only been about an hour or so since I figured it out), but I am beginning the think UnlinkHierarchy should never get called when an entity goes dormant in the first place. The EHandles would return NULL if the entity was ever removed and if anything is parented to an entity that is dormant it should stay where it is without unlinking. I'm weary of removing the call though, because it may break in some odd condition. I won't be able to make the change to my codebase until tomorrow, but some comments would be appreciated. I could add this to the Known Issues list in the wiki once a stable solution is found. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Interesting Hierarchy Bug
-- [ Picked text/plain from multipart/alternative ] Maybe you could provide us with an example. An entity that has the flag FL_EDICT_ALWAYS and a child of that entity with a PVS check. Anyway, can't you just prevent that the entity goes dormant on the client? (C_BaseEntity::NotifyShouldTransmit) On 9/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Not sure I understand what's bad about all of this. Do you have a concrete repro scenario from HL2DM, or does this only occur in mod code? At 2006/09/08 12:30 AM, Ben Everett wrote: Good catch! Add it to the bugzilla, as you have a better idea of what is going on than I do (busy bug fixing my own code). An interesting condition to say the least, anyone else w/ experience in this field wanting to comment? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Menard Sent: Friday, September 08, 2006 12:12 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Interesting Hierarchy Bug Well I've found an interesting hierarchy related bug. I figured I should notify the list about this one because it took me a while to wrap my head around it. I'm not sure if this has been fixed in the new SDK update (my mod is still running on the old codebase until we have time to merge in the new SDK), but I did a quick search in the known issues list and the new source and there doesnt appear to be a fix. It looks like a comment was left regarding parent attachments in the SDK update, but it doesnt resolve the parent issue. Anyways this bug occurs when a FL_EDICT_ALWAYS entity is parented to a PVSCHECK entity. When the PVS entity becomes dormant, it will call UnlinkFromHierarchy which will unlink it from its parent and do the same for all its children. The trouble comes when the PVSCHECK entity comes back into view. The entity loses its dormant state and it begins to move again, but the FL_EDICT_ALWAYS entity stops following (atleast client side). The reason being that the hierarchy system expects a full entity update from the server when it comes back into view (which would fix up the parent of the ALWAYS entity), but since the entity is always transmitted, it never receives the message to reset the parent because server side the parent never changed and the entity never went dormant. I have yet to find a concrete solution to the problem (though its only been about an hour or so since I figured it out), but I am beginning the think UnlinkHierarchy should never get called when an entity goes dormant in the first place. The EHandles would return NULL if the entity was ever removed and if anything is parented to an entity that is dormant it should stay where it is without unlinking. I'm weary of removing the call though, because it may break in some odd condition. I won't be able to make the change to my codebase until tomorrow, but some comments would be appreciated. I could add this to the Known Issues list in the wiki once a stable solution is found. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Interesting Hierarchy Bug
Good catch! Add it to the bugzilla, as you have a better idea of what is going on than I do (busy bug fixing my own code). An interesting condition to say the least, anyone else w/ experience in this field wanting to comment? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Menard Sent: Friday, September 08, 2006 12:12 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Interesting Hierarchy Bug Well I've found an interesting hierarchy related bug. I figured I should notify the list about this one because it took me a while to wrap my head around it. I'm not sure if this has been fixed in the new SDK update (my mod is still running on the old codebase until we have time to merge in the new SDK), but I did a quick search in the known issues list and the new source and there doesnt appear to be a fix. It looks like a comment was left regarding parent attachments in the SDK update, but it doesnt resolve the parent issue. Anyways this bug occurs when a FL_EDICT_ALWAYS entity is parented to a PVSCHECK entity. When the PVS entity becomes dormant, it will call UnlinkFromHierarchy which will unlink it from its parent and do the same for all its children. The trouble comes when the PVSCHECK entity comes back into view. The entity loses its dormant state and it begins to move again, but the FL_EDICT_ALWAYS entity stops following (atleast client side). The reason being that the hierarchy system expects a full entity update from the server when it comes back into view (which would fix up the parent of the ALWAYS entity), but since the entity is always transmitted, it never receives the message to reset the parent because server side the parent never changed and the entity never went dormant. I have yet to find a concrete solution to the problem (though its only been about an hour or so since I figured it out), but I am beginning the think UnlinkHierarchy should never get called when an entity goes dormant in the first place. The EHandles would return NULL if the entity was ever removed and if anything is parented to an entity that is dormant it should stay where it is without unlinking. I'm weary of removing the call though, because it may break in some odd condition. I won't be able to make the change to my codebase until tomorrow, but some comments would be appreciated. I could add this to the Known Issues list in the wiki once a stable solution is found. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
