On 22nd February, I submitted a bug report for the Line Renderer colour blending and a feature request for the Trail Renderer. I’m not chasing to have them fixed quickly as such, but it occurred to me that I didn’t receive case number messages for the reports, and maybe they were never received. Should I resubmit the reports?
Thanks. 
If you don’t receive the receipt. Please resend it.
We had a small down time with the report bug server at that point. Sorry for the inconvinience.
I just resent the two errant reports, followed by one new feature request. I got a response for one of the feature requests (2231) but not the other two - how strange!
Incidentally, would it be possible to have the bug reporter automatically keep a local log of reports so that it’s easier to see what we’ve sent in and when it was sent?
I still think it would be cool to be able to browse the bug reports on the site…
I wrote this post a few times and don’t feel I can express myself without inciting inflammation. I’ll summarize the gist of it by saying that various aspects of working with OTEE regarding bugs upsets me in tangible ways.
I realize that OTEE has a huge range of experience levels to deal with in their customers, and giving access to a list of bugs could create more support problems than they would solve.
At the same time, I do feel that customers with some decent level of professional experience should be given a bit more latitude/time when they feel they have an issue, perhaps even exclude tech experience and base it on Unity license level? I say this because I am fairly accomplished in programming, have found a few bugs (some that stumped me for quite some time thinking they were a misunderstanding of mine regarding the Unity paradigm), and one recently that I was sure was a bug and was told that it wouldn’t even be looked at if I couldn’t reproduce it in a simple project. I coded the problem area only and guess what? Its not reproduceable, but it happens every time in my main codebase, and the code that manipulates this component probably encompasses about 10-15 lines of code out of the thousands I’ve written so far.
I hate to focus on one problem and make it sound like the end of the world. I can re-code and work around it (sacrificing a feature that feels cinematically important to me), but given the fact that my project is pretty far along codewise I can’t take time away from my own contract work to do so, and my project is stalled until this contract ends and I can put more time to Unity again. That’s a frustrating feeling when you’re trying to develop a new business based on Unity!
I realize that game development is a lot more flexible than “traditional” development, and that if a bug pops up in a business application that prevents something from working it must be addressed (at least acknowledged or a workaround provided), while in game dev it seems the common idea is more that features are expendible when they can’t be made to work.
Is this a case where I should just suck it up, drop the feature and move on, or am I justified in getting a little frustrated?
Sorry for the overall negative tone, and OTEE guys I really do love you (can I have a hug?). I’m just sitting here frustratedly working on a contract, wishing I could spend about 15 mins or so playing with my Unity code and thought it would be a good time for a “Hell yeah!” or “attitude adjustment”.
Thanks if you slogged through. Feel like I just poured my heart out!
I just submitted another bug report and didn’t get a receipt for that either. Since the email address I use for this purpose is the one that successfully received the receipt for case 2231, I don’t see why it would receive some and not others.
Could someone look into this and let me know if my reports are being received or if they’re disappearing into the ether?
To summarise, I sent these reports/requests:
The 3 bugs where you say you haven’t gotten a receipt number for are not in our bug database. Please try reporting them again.
I feel you are unjust about the amount of support we give when reporting bugs. First of all i would like to point out that, there is no other development tool where the developers are willing to go through huge project folders looking for bugs - for free.
This is taking up an enormous amount of time. We are doing it because we are committed to providing the best possible free support for Unity.
Often looking through a project folder, we discover that it was actually a bug in the script or scene setup.
In your particular case, i spent 2 hours debugging the scripts in your project.
As you said, the project was quite big, so it was hard for me to follow the flow of your program. I remember getting a couple null reference exceptions in various places when playing the project in the editor. This was a sign for me that something in the setup / scripts was wrong.
After 2 hours i concluded that the problem was a bug in your scripts. Maybe i was wrong but i can’t justify debugging a whole day if i don’t know exactly that in the end it will actually turn out to be a bug in Unity and not bug in your scripts / setup.
Thus i asked you to provide a smaller project that shows the problem.
I’m sorry you wasted so much time (really!). As I said, there are about 10 lines of related code and I would have gladly pointed them out to you. I don’t think I’m being unjust at all. It would be unjust if I said, “Every time I submit a bug, those pesky OTEE guys do this”. I didn’t. I illustrated one case that bothered me because I felt severely undervalued.
Yes there were null references in that area of the code, and that was because of this bug!
The psuedocode of the problem (so that I can un-exaggerate your description just a bit):
thecamera = MainCamera
thecamera.parent = camerafollowobject
while introrunning:
... do some stuff
if introfinished:
thecamera.parent = playerobject # oops, Unity go boom!
Thats just about all the complexity of the problem. After the intro is finished, my reference to thecamera is totally lost and I get null pointer exceptions whenever I refer to thecamera.
I suppose I will re-code to try to avoid this condition since thats apparently my best at this point, but I hope I’m wrong about the bug!
I would like to suggest that even though you say you are “providing this support for free”, then what does that make me? Am I “paying you to do your QA”?
Thanks,
Russ
I sent all three again and I only got a response for case 2243. This is really strange. :?
Looking at the console.log, it seems that the bug reporter uses curl to send its data. There aren’t any error messages here and the status messages reach 100%, suggesting that the file is being sent correctly. Does the bug server filter out certain messages or something?
I’m not sure what to do about this. Is there anywhere else I can send the reports?
Elsewhere:
If you’re making the camera a child of camerafollowobject, is it possible that when camerafollowobject gets destroyed, the camera is destroyed with it? If that’s the case, references to it will be null by the time you try to set its parent again.
Send the bug report that didn’t get through to me via mail joe at otee.dk.
We will look into what is going on with Bug Report.app.
Thanks for the idea, Neil.
No objects are destroyed - the parenting is changed when camerafollowobject stops animating (its invisible, so I just leave it there).
Russ
Maybe it gets destroyed because of a level load?
Thanks Jo - this was one of those Unity paradigm problems I was talking about. Thanks for seeing through my strong wording. To everyone else, I probably would have brought this to the forums and discussed first if Jo didn’t have my code in hand already, working on a pretty big bug at the time. I should have gone to the forums after we discussed it, but then started on a 3-month contract and had to (self) grudgingly put this to the side.
To help anyone else broaden their troubleshooting knowledgebase:
I had assumed that since I created the camera in a parent class set with DontDestroyOnLoad() and set a reference to it in the inspector, it would be safe. Of course now that I know what caused the problem, that assumption doesn’t really make sense since the camera is reassigned to an object that can be destroyed on level load (and is thus destroyed).
So no matter how hard I studied the problem, it didn’t make sense so I was pretty confident it was a Unity bug (So far I’m batting about 8/10 when I submit reports).
Ah well, what happens when we assume?
Jo, if you’re ever in South Florida, come to claim your (imported of course) beers. I don’t drink much, so I’ll easily forget how many I bought you 
To OTEE’s credit, they have been providing support above and beyond what we (the Unity users) should be expecting. Assuming that the bug reporter is posting the bugs correctly, I don’t think any user should expect a personal response to their own bug reports. OTEE is not some giant corporation – it’s unreasonable to expect them to drop ongoing development and take on a public relations role every time a bug report is filed. If multiple people are experiencing the same bug, then hopefully that would become evident and that bug would be fixed in due course.
That said, the documentation could use an overhaul. Putting it all in one PDF (tutorials and all) would probably yield the biggest bang for the buck. As it is now, it’s very awkward to try and figure out why feature XYX is not working. Search the web site; search the forums; locate, download and search the various tutorials (which may or may not be up-to-date); search the user contributed script wiki; etc.
Intersecting support and documentation are the programming languages. I’m sure that supporting C#, Javascript, and Boo simultaneously is quite a headache. In general, I don’t think OTEE has an obligation to field general programming questions about these languages, unless the issue is something Unity specific. The exception would be the shader language(s), which I believe is Unity specific?
Finally, I highly recommend posting problems on the forums before filing bug reports. I’ve come to see that most problems can be fixed with help from the community, which lightens the load on the OTEE folks. I think the more sample code / sample projects are shared amongst the community, the more mature the community becomes, better able to respond to any other problems that come up.
Anyways, my two cents. :roll: