Team:Calgary/25 June 2009
From 2009.igem.org
(Difference between revisions)
PatrickKing (Talk | contribs) |
|||
Line 417: | Line 417: | ||
<br> | <br> | ||
<div class="heading"> | <div class="heading"> | ||
- | + | Heads Up Display Screens | |
</div> | </div> | ||
<br> | <br> | ||
<div class="desc"> | <div class="desc"> | ||
</html> | </html> | ||
- | + | Retrospective Notebook: This entry was not written on this day, but derived later from working notes I made that day. | |
+ | |||
+ | Began planning out the navigation scheme for the HUD, what screens would be available for you to click through. Very quickly realized that displaying lots of text on a 15x8 character screen was a bad idea, long form communications would have to happen by giving the user notecards (text documents in second life). | ||
+ | |||
+ | Initially, I was sending the display messages to each of the 120 display tiles by name, using chat messages. This was extremely slow... and because each object only has a 100 message queue, and each object received every message whether it was the intended recipient or not, some tiles would have their message dropped! Naming all of the display tiles accurately also turned out to be obnoxious, as a handful of typos didn't become obvious until much later. | ||
+ | |||
+ | Also, updating the script contained in each display tile object for bugfixes or new functionality became a *major* hurdle. Either I would have to create a single new tile, copy it 119 times (easy, fast) and rename each tile with its coordinates (slow, painful), or I would have to go into each tile, delete the old script and replace it with the new one (slow, painful). This system would get rehauled for something a good deal better (though perhaps still not optimal). | ||
+ | |||
+ | The basic outlines of the HUD were established: a main menu, the unbind screen, the build screen a level selection screen, as well as 'count mode'. Count mode would be renamed interaction checker, the idea being that I could check whether the user had made an error in using the biobrick simulator by checking each object for interactions it could have with other objects. The idea is that if a reaction could happen, it should. If a gene is on but it has no gene product around, it should be expressed; or if a repressor is floating about with a compatible promoter still active, the promoter should be turned repressed. Or alternatively, if all copies of a gene are turned off, then none of their gene product should be present. This is another feature that has yet to make it into the simulator proper, but I've designed the sim's objects in a way that will make it easy to implement when I get the time. | ||
<html> | <html> |
Revision as of 20:34, 21 August 2009
UNIVERSITY OF CALGARY