Git: 0.2 Contributor Thread

[LypyL]

Yeah, I had no problem doing that. But after pulling the latest commit from your master branch I did notice that I can no longer unsheathe weapons anymore, due to a missing texture - if these bugs are only happening on my end, then it might be the case my local build is messed up

[Interkarma]

Weapon thing is my side. I've stripped out the fake weapons and linking up proper equipped weapons from inventory. Will have the fixes pushed up soon.

[Nystul]

With a reference to the DaggerfallDungeon object, you can use these guys.

Code: Select all

GameObject enterMarker = dungeon.EnterMarker;	// Enter marker (e.g. bottom of Privateer's Hold)
GameObject startMarker = dungeon.StartMarker;	// Start marker (actual dungeon entrance/exit)

thanks!
this worked. but it will be difficult to make it "reveal" like the rest of the dungeon... going to do some more raycasting

[Nystul]

I think a found a small bug:
OnLoadEvent from SaveLoadManager is only fired when quick save is loaded, not when a vanilla game slot is loaded

edit: oh no - where has the capsule collider of GameObject "PlayerAdvanced" gone? this was used in my mechanism to reveal the dungeon entrance marker in my solution to reveal the dungeon entrance beacon (only in my git currently) - is there a replacement?
I raycast from the beacon entrace marker position to the player head position (the camera) and my test was if it hit the capsule collider from GameObject "PlayerAdvanced" instead of other geometry...

[LypyL]

[/quote]
edit: oh no - where has the capsule collider of GameObject "PlayerAdvanced" gone? this was used in my mechanism to reveal the dungeon entrance marker in my solution to reveal the dungeon entrance beacon (only in my git currently) - is there a replacement?
I raycast from the beacon entrace marker position to the player head position (the camera) and my test was if it hit the capsule
collider from GameObject "PlayerAdvanced" instead of other geometry...[/quote]

It's still there - if it wasn't, the player game object would just fall through the floor You can access it via characterController.collider....I'm guessing you might have actually been using the extraneous capsule collider that used to be on the player object, but was recently removed?

Some good news - we should layers & tags without restriction in the near future. Probably not until after .2 is out, but not long.

[Nystul]

It's still there - if it wasn't, the player game object would just fall through the floor You can access it via characterController.collider....I'm guessing you might have actually been using the extraneous capsule collider that used to be on the player object, but was recently removed?
long.

thx ok then the fix is easy

Some good news - we should layers & tags without restriction in the near future. Probably not until after .2 is out, but not long.

cool! looking forward to layer my socks off^^

btw, I still fail to reproduce the error - but next pull request will have some more checks included - maybe this will help.

update: @Lypyl: I think I found the issue - switching from UnityEngine.Object.DestroyImmediate to UnityEngine.Object.Destroy was a bad idea and made it possible for objects to be destroyed too late (I will explain). Event callbacks and Update function seem to be executed in arbitrary order/scheduling for a given frame. Or to say it in other words - events may fire whenever they like (maybe script execution order influences this as well). I use DestroyImmediate to destroy map specific GameObjects when the map window is closed or on certain events (transitions/loading). When a load event is issued I destroy existing map-GameObjects and recreate them (since they could have changed). Destroy simply can lead to being executed AFTER the objects have been created - leading to a deleted object where a object should be present.
Lesson learned: Destroy can even be more dangerous than DestroyImmediate even though the documentation says differently...

update2: Player Collision script is attached 2 times to PlayerAdvanced, further the new collider does not work well - is it too small? Is the camera position (head/eye position) now outside of the collider? seems so... anyway changed my code a bit and is now working again (pull request issued)

[Interkarma]

I think a found a small bug:
LoadEvent from SaveLoadManager is only fired when quick save is loaded, not when a vanilla game slot is loaded

This is intentional. Classic save import is considered a different process to normal save/load. Perhaps there is something else I can expose that will serve you better than a load game event? At the very least, I could add an OnSaveImport event to do the same job?

update: @Lypyl: I think I found the issue - switching from UnityEngine.Object.DestroyImmediate to UnityEngine.Object.Destroy was a bad idea and made it possible for objects to be destroyed too late (I will explain). Event callbacks and Update function seem to be executed in arbitrary order/scheduling for a given frame. Or to say it in other words - events may fire whenever they like (maybe script execution order influences this as well). I use DestroyImmediate to destroy map specific GameObjects when the map window is closed or on certain events (transitions/loading). When a load event is issued I destroy existing map-GameObjects and recreate them (since they could have changed). Destroy simply can lead to being executed AFTER the objects have been created - leading to a deleted object where a object should be present.
Lesson learned: Destroy can even be more dangerous than DestroyImmediate even though the documentation says differently...

If an object scheduled for destruction is triggering code, that's sign of a problem with that object or something still holding a reference to it. When calling Destroy() also clear out any old references to objects, and on the object itself use OnDestroy() to clean up first (unregister events, etc). You could also implement IDisposable and and call Dispose() before releasing references. Object can clean up and schedule itself for destruction. Best to fix the base problem if possible. I would rather not use DestroyImmediate() when inappropriate, as this could potentially add new problems later.

Anyway, I've run with the current pull request and DestroyImmediate() for now, but would love for the object management design to be improved one day so this becomes unnecessary.

update2: Player Collision script is attached 2 times to PlayerAdvanced, further the new collider does not work well - is it too small? Is the camera position (head/eye position) now outside of the collider? seems so... anyway changed my code a bit and is now working again (pull request issued)

Thanks for the spot, removed second reference now. There's no new collider, it's still the same CharacterController handling all the physics. The removed trigger collider was just for certain things (like enemy attacks or firing traps). Happy to restore this trigger collider if preferred, it can probably be useful anyway.

[Nystul]

This is intentional. Classic save import is considered a different process to normal save/load. Perhaps there is something else I can expose that will serve you better than a load game event? At the very least, I could add an OnSaveImport event to do the same job?

ah ok - it would be handy to have, but no hurry needed

If an object scheduled for destruction is triggering code, that's sign of a problem with that object or something still holding a reference to it. When calling Destroy() also clear out any old references to objects, and on the object itself use OnDestroy() to clean up first (unregister events, etc). You could also implement IDisposable and and call Dispose() before releasing references. Object can clean up and schedule itself for destruction. Best to fix the base problem if possible. I would rather not use DestroyImmediate() when inappropriate, as this could potentially add new problems later.

yeah I am also not happy, but Destroy() is giving me headaches, here is what basically is the problem:

• GameObject with e.g. interior geometry on it (only reference is the handle to the GameObject - nothing else)
• Loading Savegame where player is inside dungeon (so I want to destroy interior geometry and create gameobject with dungeon geometry)
• calling Destroy();
• afterwards creating dungeon geometry GameObject and storing the reference in the handle
• later in a different function when I want to use the new gameobject via its handle it is null because (I think) Destroy() somehow destroyed not the old but the new gameobject because it did it too late (at the end of the frame) and mixed up its reference somehow (and I bet the old one was not deleted but gets destroyed eventually by garbage collection))

maybe just setting the handle to the new GameObject will be the better way and hope for the garbage collection to do its job...

Anyway, I've run with the current pull request and DestroyImmediate() for now, but would love for the object management design to be improved one day so this becomes unnecessary.

I will be glad if we can find a better solution - just let me know what you think about the problem.

Happy to restore this trigger collider if preferred, it can probably be useful anyway.

I don't need it for now as it seems

[Narf the Mouse]

You can set the script execution order. Normally it's arbitrary, but there's an option to set it specifically. It's in Edit->Project Settings->Script Execution Order.

Also, some script functions do execute in a certain order. Here's a link:

http://docs.unity3d.com/Manual/ExecutionOrder.html

Hopefully that's helpful.

[Nystul]

thanks!
I knew about the script execution order stuff - although it is not really of much benefit if the script number gets larger and larger for the given problem everything is within one script - so this will not make a difference here I fear.
thank you for the link. This might help at some point!