One week in the shoes of an engineer

Started by
2 comments, last by frob 9 years, 7 months ago

Hello gamedev.

I thought I would do something unusual, I will speak of my work so that beginners or hobbyists and passionate people who wonder how it is out there in the wild, can get an image of what it is to work in this industry.

Also, as a bonus, it will give hobby programmers a sense of scale into why it takes so much more time to professionals to get things done, compared to when its done home. This is linked to the difference between what we call, a prototype, and a production code.
Disclaimer: the post is detailed, on purpose. It can be boring. So bear with me :)

So, last week, I had to start development of a task that is related to making a tool I develop, cooperate with Maya, in the sense of being able to control Maya remotely, and export/import stuff from it.

The first part of this is to document yourself, if like me you are not familiar with Maya. So I use google, and I stumble across the commandPort mel command. (Mel is the script language inherent to Maya)
This command allows to command Maya remotely. Just what I need.
It happens to have a port open by default, but this port when accessed pops a security dialog (for good reasons), but it is just too bad in our workflow because it disrupts the "automation" and make our tool integration bad.
So rather, I found that starting my own commandPort didn't raise this problem.
But, the user would have to click a button to start the service, which is the same problem as the security dialog from before. Back to square one.
Only, there is something called userSetup.mel/.py that can be used to put startup scripts.
Perfect this is the good place to put our command.
Except its not that simple, will artist need to paste this line by themselves ? No, it needs to get automatically installed when installing the company's internal toolsuite. That is all ok, I just need to put the file containing the one-liner into the installer and specify the destination.
If only it was that simple.
userSetup.mel/py is a script that is shared by other applications that wants to make exactly this kinds of things. Therefore you cannot overwrite it stupidly.
Most companies don't care. Like 3d connexion or Substance, they just overwrite it, and they are doing-it-wrong™.
The good way to do it, is to APPEND your modification to it.
Fine, I'll write a python program that does that.
Except, how do you locate the folder for the script ?
Most of the time it is in the user's document/maya folder. But sometimes it may be located by the environment variable called MAYA_APP_DIR, therefore you need to check if it is defined and follow it if so.
Then, it is not over, because in case the installer fails at some other point (remember its a tool suite), it must be capable to rollback, so uninstall as well. Which means detecting your addition (I used recognizable patterns that I put in comments) and removing it, using some string operations. Fortunately python is awesome for that.
But in the end, the script is 200 lines, to install a 1 line script. Yep... Actually the one line script ended up being around 20 because of exceptions safety, and modularization for the future I chose to load code located in another sibling script file on the side of userSetup.py, using python's awesome self interpretation "execfile".
However, one-does-not-simply™ load a script on the same folder as the current script, because it uses the current APPLICATION working directory.
For that, I fixed it using a debug stack inspection system internal to python, that is able to tell the current script's full file path. Yeah !

Then, I need to integrate invocation of this installer by the parent installer, which is written in C++, so I used PyInstaller to make an .exe out of my python script, and then used CreateProcess and WaitForSingle stuff from Win32 API to invoke my sub-installer. Then add the files into the all-mighty installer solution.

I had to write a C# GUI to test rapidly if the Socket connection was working with Maya, it didn't take long at all thanks to google again, the code was already posted somewhere, so copy paste + do a quick GUI over it and rollin' !

Then I needed to modify my main application tool, the one I want able to speak to Maya, its in C# as well, I factorized the code from my GUI tester, and integrated it, then used it to start by opening the maya scene.
Which... could only have happened after I made a Maya launcher, by detecting the install path (or requesting manual input if not found), and execute maya with some Process.Start stuff.
Only it is not that simple, because you do not want to start a flock of Mayas, so you need to check the running processes on the machine. I used "maya" as a string identifier, it works for me now, I hope Maya is always called Maya... Dangers of hardcoding...
The scene path itself was difficult to retrieve because my tool works with derivatives assets that are exported, but thankfully enough they bare the original Maya path in their headers. Which are readable by a library a colleague did.
So a little toying with my C++ utility helper, and bit of PInvoke and up and rollin' again.

And then I realized that I had to send multiple commands one after the other, like "load scene" and "select some stuff". But my system was spawning a new thread for every command, therefore creating a potential race condition which would have made the selection command appear first to Maya.
I fixed it by using only one thread, and a .NET4 concurrent collection called BlockingCollection using an underlying ConcurrentQueue. Ok, go to next !

I had something working at this point, but then I realized the auto-sync, which is a feature of a Maya plugin we have, didn't work, and I learned it was due to the name of the scene being different in the (third) external tool I have and the Maya scene's name.
This is actually a huge issue because all of my internal identification system works on string made of the exported name, which can be anything. This will take a long time to fix, and is not done today, it will be for this week.

And this is how, from something as simple as that, and that should take 4 hours tops, according to common sense (non programmer sense), you end up using a week and to finally realize that it will actually take 2 or more.
This is typical your-everyday-story as a professional. It is typical that a solution to a problem cascades into a deep tree of implications like this very small original problem.

Share your own if you think you have a story :) ^^ !

Advertisement

Today at work i wept pathetically in a toilet cubicle for about 25 minutes and considered hurling myself from the roof of the building. This is the third time this month I have done this.

Donkey1.jpg

We put Glad wrap and vegimite on the toilet seat and the engineer happened to be the one to use it. well that created a work meeting. LoL.

PS. He Sprayed the bowl too hehehe

Today at work i wept pathetically in a toilet cubicle for about 25 minutes and considered hurling myself from the roof of the building. This is the third time this month I have done this.

If serious, PLEASE get help.

Several of us on the board are outspoken bipolar individuals. Even on medication my swings aren't gone, they're reduced. On the negative weeks I think about death all the time.

There are two important scores: Ideation and intention. When depressed, ideation about death (thinking about death, thinking about non-existence, etc) is common and somewhat safe.

But since you mentioned that you were considering doing it, that is intention.

Intention means time to call a crisis hotline.

This topic is closed to new replies.

Advertisement