xale / itetrinet Goto Github PK
View Code? Open in Web Editor NEWTetriNET Client Developed for Mac OS X 10.5 Leopard
TetriNET Client Developed for Mac OS X 10.5 Leopard
The app hangs for up to thirty seconds when attempting to connect to www.tetrinet.us, with absolutely no response to user input or interface updates. Activity Monitor samples appear to indicate that the app is blocking on [NSHost hostWithName:] in the network controller; my guess is that this is a DNS lookup taking too long and preventing the next iteration of the run loop, which may be difficult to fix.
Toolbar needs a pause button, menu needs a pause menu item. Connect to the Tetrinet protocol's "pause" feature.
Also: determine whether a "pause" message can be sent by any player, or just the moderator/operator.
Support for channels has been partially written, but doesn't currently work. The implementation should probably use the TetriNET Query protocol, described here: http://jetrix.sourceforge.net/dev-guide.php#section2-5
Certain blocks in certain configurations can't be rotated when they first spawn on the board, and the collision-detection code prevents them from doing so. A special-case check should be added, to shift these blocks downward one row and allow them to rotate.
Several pieces ("blocks") are not properly centered when they first enter the board. This should be address, since it potentially creates a balance issue.
The list of actions on the game view is currently able to steal keyboard focus from the field, which means that all of the local player's keyboard input stops working.
The keyboard preferences pane needs to be configured to disallow the assignment of the top-of-keyboard number keys 1-6, which are used for sending specials.
See also: issue #11.
Growl support (for events like players joining and leaving, chat messages and games starting and ending) would be a very nice thing, especially if users could configure the notifications to be on, off, or only when the app is in the background.
There should be notifications for the following events:
Similar to #27. The game chat field should return keyboard focus to the local player's field after the user sends a message.
Having looked more closely at GTetrinet's implementation, the current two-table style for the winlist should probably be removed in favor of a single table, with an additional column indicating whether the entry is a player or a team.
Pressing the tab key while the game chat field has keyboard focus causes the focus to move to other parts of the UI, which can be a problem if the user is in the middle of a game and can't quickly move focus back to the game field.
The game is mostly playable, but at the moment, the local player cannot lose the game, since there are no checks in the game view controller for when the player loses.
For some odd reason, the ranges of text in the game actions list that are displayed in bold are also drawn in a larger size, causing the text to be clipped by the edges of the cell, and reducing the available space. This needs to be fixed.
The "Next Block" view box correctly shows the preview of the next block to fall, but it does not center the image. This has to do more with the way the block-images are created in the first place, so this probably needs to be solved by adding another method to the iTetBlock drawing category, that will render an NSImage of the block without any transparent padding, which is only necessary when the block is actually on the board.
All of the custom NSView subclasses with bindable properties don't actually have the bindings-compliant backend code necessary to make them work. How they are able to anything at all has me completely lost.
Sparkle (the third-party auto-update framework) support, while more difficult to add than Growl support, would also be a good addition to iTetrinet.
Noticed this in the logging output when testing the other day. Appears to happen after disconnecting from one server and connecting to another. Probably occurring in the network controller, but needs to be tracked down precisely, if it can be reproduced.
Field views currently have no indication (except perhaps a "death field" update sent by the server, like Jetrix's "Jetrix field") that the player in that slot is dead, which makes it difficult to determine if a player is still playing.
When certain field updates (specifically, updates after a line has been cleared) are sent to the server, jetrix spits out some information about index-out-of-bounds exceptions, and then complains about receiving a malformed field update from the client. The code for generating the fieldstring needs to be checked, as this is likely the culprit.
Version 1.14 of the protocol supports a feature that gives all players the same sequence of falling blocks. The implementation of this is described in the developer documentation on the jetrix site. At some point, iTetrinet should add this version of the protocol, adding a protocol version pop-up menu in the server list.
While the non-numpad 1-6 keys are reserved, the 7-9 and 0 keys are not, along with all keys on the numpad. This creates a minor issue with the user not being able to tell these keys apart from one another in the keyboard preferences pane; e.g., numpad 7 looks exactly like the non-numpad 7, but these are different keys "behind the covers." For clarity's sake, some sort of annotation should be added to the numpad key-images.
It might be beneficial to print the local player's name in a different color on the chat views, to help distinguish what the user has said from incoming messages.
User confirmation dialogs are needed for the following situations:
GTetrinet switches back to the chat view tab when a game ends; this should probably be added as a checkbox in the General pane of the preferences window.
The app should terminate when the user closes the main window (after asking for confirmation, of course.)
The client reliably receives an end-of-stream from some servers (e.g., nenoth.ietfng.org) very shortly after joining and receiving the player number message, causing an immediate disconnect in the eyes of the user.
It shouldn't be too hard to create an offline-play mode, allowing users to play Tetris without being connected to a server.
The specials view on the game tab needs some way of indicating its present capacity (i.e., how many specials it can hold at maximum.)
The network controller periodically receives a "HasBytesAvailable" event from the read socket, attempts to read, and receives no bytes from the stream. Currently, this occurrence prints a warning and does nothing else, but I believe this may be NSStream's way of saying "end-of-stream," in which case the client should probably disconnect and display an error message.
The current architecture of the game view (i.e., the code connecting the "Game" tab of the main window to the model) is in need of a major rewrite.
The specials view could really use a border, as this would make it easier to see the capacity of the queue, and possibly some subtle lines on the background delineating exactly how many specials would fit.
The code to push the field down by up to 6 lines after a switch field special is used appears to be commented-out in the game view controller; this is exceedingly strange, since I thought that code was working. Needs to be investigated further.
It appears that some other clients may reward multiple copies of acquired specials if the player collects them with multiple-line completions; e.g., a Tetris (4 simultaneous lines) awards 4-6 copies of any specials inside those lines. Needs investigation (i.e., read the GTetrinet source.)
The list of game actions (lines sent and specials used) should use formatted text; color, at the very least.
Pressing the "new game" button (which should be changed to an "end game" button) after the game has started, brings up a confirmation sheet asking whether to end the game in progress, but the sheet's callback does nothing. There is currently no way to end a game in progress.
Also, leaving the server does not clear the game controller's state, so it still thinks there is a game in progress.
iTetrinet currently discards the winlist sent by the server when the user first connects. Ideally, it should maintain this list in another tab of the main window.
A good deal of the code needed to play Tetris is still unfinished: specials don't work, there's no end-of-game detection, etc.
At the moment, Themes store only loose references to the original theme file's location, and load all information from that file when the Theme is loaded. This will break if the user moves any of the necessary files.
In future, Themes should automatically copy all the files they need to the user's Application Support directory, and hold references to those files only, ensuring that they are always available.
The blue and red text show up very well in the game actions even when drawn on a background of the similar color, (used for highlighting) but the green text is nearly impossible to read. The text should either be darkened or the background lightened to increase legibility.
The keyboard bindings preferences do no distinguish between ordinary, top-of-keyboard number keys and the number keys (and other keys) on a numeric keypad. This is an issue because most TetriNET clients reserve the (non-numpad) 1-6 keys as "targeting" keys for specials (i.e., press a player's number to send a special to that player.)
There appears to be an offset error in the parsing of text attributes on incoming message: attribute ranges end one or two characters two early. (To be precise, the attribute ranges appear to end early by exactly the number of open attribute tags.)
iTetrinet has so far been working under the naive assumption that the player with player number "1" in the current channel is always the "operator" (with start/stop game permissions, etc.) This is apparently incorrect, and the operator number can be shifted around under various conditions. This behavior needs to be pinned down more precisely, and then accounted for.
The "game chat" key binding hasn't been implemented yet; it should cause key focus to move from the user's field view to the chat field. (Focus should return to the field view as soon as a message has been sent.)
See also: #29
The images generated by the iTetKeyView views are not the finest graphic design. At some point in the future, I'll have to decide whether to make custom images for the keys, (ugh) or if there is a way to programmatically generate nicer images (perhaps using a set of template images.)
The highlighting needs work too.
Add a key binding specifically reserved for using a special on the local player. The reasoning behind this is that it is much faster to remember a specific key than fumble for the correct player number each game.
The TextAttributes -formattedMessageFromData: method currently leaves-in any non-printing characters in incoming messages used as formatting bytes by the TetriNET protocol; most of these cause no problems when the message is printed into the chat text view, but some (such as newlines) cause issues. This should be changed so that the characters are removed.
Some game action descriptions are too long to fit in the width of the game actions list, and are truncated by the table. GTetrinet handles this by drawing the remainder of the message on the next line, but this is difficult to do with table views.
Two items on the main window interface—specifically, the specials view and the label with the name of the currently-selected special—are bound to properties of the local player's specials queue, and when the local player is released (e.g., when disconnecting from a server) these bindings remain "attached" to the deallocated queue.
Probably would be fixed by #14.
Partyline messages are supposed to contain a small amount of formatting information, mostly just for text color, specified on the protocol page. iTetrinet does not presently support this feature.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.