You could try updating your OS to the latest version and lmk if the issue persists. Also, make sure you are running the bridge with `python3 bridge.py` (not python) and that you installed pyserial with the command `pip3 install pyserial` (not pip).
» Forum
> Your Projects
I was using Python 3, and believe me, I would update my OS if I could. It's just that a 2008 iMac can't run anything later than 10.9.5. Does it work on Linux (speciffically Ubuntu 20.4)?
New Pre-Release - Version 0.0.93
link http://titrek.us/downloads.php
Changelog
- "Serial Connected" text added to main screen
- Load Ship functionality added
- Winning sprite from contest added to assets
- Settings display and customization added
- Automatic client timeout for network inactivity added (fix for inability to exit program if server disconnects)
- "Bad GFX Version" shows on main screen if your graphics version is incompatible
The new graphics pack is built with the newest version of convimg that allows you to insert a header -- that header indicates the version of the graphics. The program itself lists the compatible graphics version, causing a Bad GFX message to appear if they don't match. You also cannot play the game if the version doesn't match.
At this point, it is now possible to build your own sprite pack if you do so with the latest version of convimg, and you enable the building of a 24-bit LUT for the sprites, as well as a 2-byte header matching the required graphics version for that program.
We are having some problems with the bridge in certain conditions. Stay tuned for updates.
Screenshots
The Settings UI
The Login/Module Display
The Bad GFX String
link http://titrek.us/downloads.php
Changelog
- "Serial Connected" text added to main screen
- Load Ship functionality added
- Winning sprite from contest added to assets
- Settings display and customization added
- Automatic client timeout for network inactivity added (fix for inability to exit program if server disconnects)
- "Bad GFX Version" shows on main screen if your graphics version is incompatible
The new graphics pack is built with the newest version of convimg that allows you to insert a header -- that header indicates the version of the graphics. The program itself lists the compatible graphics version, causing a Bad GFX message to appear if they don't match. You also cannot play the game if the version doesn't match.
At this point, it is now possible to build your own sprite pack if you do so with the latest version of convimg, and you enable the building of a 24-bit LUT for the sprites, as well as a 2-byte header matching the required graphics version for that program.
We are having some problems with the bridge in certain conditions. Stay tuned for updates.
Screenshots
The Settings UI
The Login/Module Display
The Bad GFX String
Anyone who wishes to test out the program's ability to work with custom graphics can follow the procedures outlined at the link below to generate their own graphics pack and install it.
http://titrek.us/components/downloads/customgfx.html
http://titrek.us/components/downloads/customgfx.html
A few teasers from the upcoming 0.0.94 release.
1) Custom graphics packs supported. To indicate that the graphics pack is custom made (so the client doesn't do a normal version check), you use the following settings in convimg, in addition to the normal ones.
Code:
Special thanks goes to MateoC for implementing the `lut-entries` option in convimg... it simply moves the offsets LUT into the appvar itself, rather than leaving it defined in the program. This allows the program to load any array of sprites as assets. You will still have to keep the same sprite order, however. Refer to the link I posted previously for details.
2) The splash screen has been completely reworked.
The menu interface is cleaner, and the networking status is indicated by icon now, instead of by text. A green USB icon indicates that the serial device is ready, a red icon indicates some error. If we implement nanotube, or internetce support, an icon will indicate if the program is preferring that connection.
3) The program now alerts you on the splash screen if your graphics version is incompatible.
The incompatible graphics is triggered in one of two ways:
a) You are using a default sprite pack and the version header does not match the one set within the program's `reqd_version` array.
b) You are using a custom sprite pack (version string 0xff, 0xff), and the number of sprites in the LUT does not match the number of sprites in the program build.
Either of these being the case causes the above alert to show up, and the "Play Game" menu option to just return you to the main menu.
All splash screen and error/alert icons are built directly into the program to ensure they are available... the asset pack only supplies stuff used for the game.
1) Custom graphics packs supported. To indicate that the graphics pack is custom made (so the client doesn't do a normal version check), you use the following settings in convimg, in addition to the normal ones.
Code:
lut-entries: true
header-string: "\xff\xff"
Special thanks goes to MateoC for implementing the `lut-entries` option in convimg... it simply moves the offsets LUT into the appvar itself, rather than leaving it defined in the program. This allows the program to load any array of sprites as assets. You will still have to keep the same sprite order, however. Refer to the link I posted previously for details.
2) The splash screen has been completely reworked.
The menu interface is cleaner, and the networking status is indicated by icon now, instead of by text. A green USB icon indicates that the serial device is ready, a red icon indicates some error. If we implement nanotube, or internetce support, an icon will indicate if the program is preferring that connection.
3) The program now alerts you on the splash screen if your graphics version is incompatible.
The incompatible graphics is triggered in one of two ways:
a) You are using a default sprite pack and the version header does not match the one set within the program's `reqd_version` array.
b) You are using a custom sprite pack (version string 0xff, 0xff), and the number of sprites in the LUT does not match the number of sprites in the program build.
Either of these being the case causes the above alert to show up, and the "Play Game" menu option to just return you to the main menu.
All splash screen and error/alert icons are built directly into the program to ensure they are available... the asset pack only supplies stuff used for the game.
@Mateo, if you see this, scroll down to the bold headline please (unless you want to read this mess first).
As development on this continues and I come up with a method for handling terrain and assets for dynamic stuff, I arrived at the following:
1) Unlike elements of the GUI which are stored in an appvar on your calculator, assets for terrain and player ships will be stored server-side. When a player logs in, they will be sent an array of sprites for each element of the terrain, from nebula to asteroid to star to planet. Those will essentially be tiles. Then, the server will send the player ship sprites for each player currently logged in. As of the first beta (which will be hopefully be out soon), the engine will be simple as heck... basic shapes (circles) for planets and other elements of the terrain, and 2 default sprites for player's ships...one for top-down, one for side-view.
2) All the terrain assets will be dumped into a cache which stores the sprite's pointer (malloced) based on the size metadata in the sprite data streamed from the server. When a player joins, that sprite is added to the cache. When a player leaves, those sprites are removed from the cache.
Cache Dynamic Mallocing and the Convimg Issue
I'm not quite sure if this is an actual issue with convimg, or if there IS a way to deal with this but, let me know based on the following.
every sprite has a ->width and a ->height. Those values correspond to the actual width and height of the sprite. However, for a sprite that is RLE compressed, these numbers do not accurately reflect the actual data-length of the sprite data. This is not a problem for programs built with static graphics like (I assume) convimg and the graphx library were intended, but for the use case where I stream a series of back-to-back RLE-compressed sprites from a server to a client and attempt to write them into an array of `gfx_rletsprite_t*` objects, this is a problem because I will be unable to definitively know how large a single sprite is.
There are workarounds... I could give beck an aneurysm by asking him to prepend each sprite with a true size word in the graphics stream, but before I sink to such extremely sadistic measures, I wanted to make sure that there was no mechanism in convimg or graphx for handling this.
As development on this continues and I come up with a method for handling terrain and assets for dynamic stuff, I arrived at the following:
1) Unlike elements of the GUI which are stored in an appvar on your calculator, assets for terrain and player ships will be stored server-side. When a player logs in, they will be sent an array of sprites for each element of the terrain, from nebula to asteroid to star to planet. Those will essentially be tiles. Then, the server will send the player ship sprites for each player currently logged in. As of the first beta (which will be hopefully be out soon), the engine will be simple as heck... basic shapes (circles) for planets and other elements of the terrain, and 2 default sprites for player's ships...one for top-down, one for side-view.
2) All the terrain assets will be dumped into a cache which stores the sprite's pointer (malloced) based on the size metadata in the sprite data streamed from the server. When a player joins, that sprite is added to the cache. When a player leaves, those sprites are removed from the cache.
Cache Dynamic Mallocing and the Convimg Issue
I'm not quite sure if this is an actual issue with convimg, or if there IS a way to deal with this but, let me know based on the following.
every sprite has a ->width and a ->height. Those values correspond to the actual width and height of the sprite. However, for a sprite that is RLE compressed, these numbers do not accurately reflect the actual data-length of the sprite data. This is not a problem for programs built with static graphics like (I assume) convimg and the graphx library were intended, but for the use case where I stream a series of back-to-back RLE-compressed sprites from a server to a client and attempt to write them into an array of `gfx_rletsprite_t*` objects, this is a problem because I will be unable to definitively know how large a single sprite is.
There are workarounds... I could give beck an aneurysm by asking him to prepend each sprite with a true size word in the graphics stream, but before I sink to such extremely sadistic measures, I wanted to make sure that there was no mechanism in convimg or graphx for handling this.
Question
If I have a sprite of an object, looking at it from the top, the side, and/or the front. What's the simplest/quickest way to draw a sprite that *looks* as though you're looking at the object at the proper orientation without implementing a full 3D rendering system?
If I have a sprite of an object, looking at it from the top, the side, and/or the front. What's the simplest/quickest way to draw a sprite that *looks* as though you're looking at the object at the proper orientation without implementing a full 3D rendering system?
Question 2:
I have a logfile that generates using the following code:
Code:
How would I configure the fail2ban service to detect and respond to this?
I have a logfile that generates using the following code:
Code:
try:
ts = time.asctime()
j = {"time": ts, "match": True, "host": str(self.addr)}
with open("malicious.txt", 'a+') as f:
f.write(f"# failJSON: {json.dumps(j)}\n{str(self.addr)} @ {ts}:\
Attempted request without login. Control code: {hex(self.fromControlCode(A))}")
self.elog(f"Malformed or malicious packet from host {self.addr}")
self.send([ControlCodes["DISCONNECTED"], ResponseCodes["BAD_MESSAGE_CONTENT"]])
except:
self.elog(traceback.print_exc(limit=None, file=None, chain=True))
self.close()
How would I configure the fail2ban service to detect and respond to this?
Update
Server now implements a whitelist.
The server itself is pseudo-greylisted meaning that you can still connect if you aren't on the whitelist, but you can only send a few mundane packets...Login, Ping, ServInfo, and PgrmUpdate.
The client now has a `self.trusted` field.
If your first packet is Login, and you log in successfully, the IP is whitelisted. `self.trusted` also becomes set to true.
If a subsequent packet commits an offense (malformed packet) or attempts to do something it shouldn't, self.trusted is downgraded to False. If another offense is committed the IP is moved from whitelist to ipbans and the connection is closed.
Also I have to say something. Coming here to post a question, and then getting flamed in SAX for something completely unrelated to the issue I asked about, and when much of this code is still a WIP is not a very kind thing to do, and doesn't encourage me to work on this, or to come here when I need help. Just saying.
Server now implements a whitelist.
The server itself is pseudo-greylisted meaning that you can still connect if you aren't on the whitelist, but you can only send a few mundane packets...Login, Ping, ServInfo, and PgrmUpdate.
The client now has a `self.trusted` field.
If your first packet is Login, and you log in successfully, the IP is whitelisted. `self.trusted` also becomes set to true.
If a subsequent packet commits an offense (malformed packet) or attempts to do something it shouldn't, self.trusted is downgraded to False. If another offense is committed the IP is moved from whitelist to ipbans and the connection is closed.
Also I have to say something. Coming here to post a question, and then getting flamed in SAX for something completely unrelated to the issue I asked about, and when much of this code is still a WIP is not a very kind thing to do, and doesn't encourage me to work on this, or to come here when I need help. Just saying.
ACagliano wrote:
Update
Server now implements a whitelist.
The server itself is pseudo-greylisted meaning that you can still connect if you aren't on the whitelist, but you can only send a few mundane packets...Login, Ping, ServInfo, and PgrmUpdate.
The client now has a `self.trusted` field.
If your first packet is Login, and you log in successfully, the IP is whitelisted. `self.trusted` also becomes set to true.
If a subsequent packet commits an offense (malformed packet) or attempts to do something it shouldn't, self.trusted is downgraded to False. If another offense is committed the IP is moved from whitelist to ipbans and the connection is closed.
Also I have to say something. Coming here to post a question, and then getting flamed in SAX for something completely unrelated to the issue I asked about, and when much of this code is still a WIP is not a very kind thing to do, and doesn't encourage me to work on this, or to come here when I need help. Just saying.
Server now implements a whitelist.
The server itself is pseudo-greylisted meaning that you can still connect if you aren't on the whitelist, but you can only send a few mundane packets...Login, Ping, ServInfo, and PgrmUpdate.
The client now has a `self.trusted` field.
If your first packet is Login, and you log in successfully, the IP is whitelisted. `self.trusted` also becomes set to true.
If a subsequent packet commits an offense (malformed packet) or attempts to do something it shouldn't, self.trusted is downgraded to False. If another offense is committed the IP is moved from whitelist to ipbans and the connection is closed.
Also I have to say something. Coming here to post a question, and then getting flamed in SAX for something completely unrelated to the issue I asked about, and when much of this code is still a WIP is not a very kind thing to do, and doesn't encourage me to work on this, or to come here when I need help. Just saying.
How can I create an account for this?
You do it all via calculator, connected from the bridge. You can find the files needed on the discord, and there should also be documentation on the website. If you need help, just ask around here or on discord and you should be able to get it!
TIny_Hacker wrote:
You do it all via calculator, connected from the bridge. You can find the files needed on the discord, and there should also be documentation on the website. If you need help, just ask around here or on discord and you should be able to get it!
I'm forbidden on discord so I can't grab files from it
BioHazard wrote:
TIny_Hacker wrote:
You do it all via calculator, connected from the bridge. You can find the files needed on the discord, and there should also be documentation on the website. If you need help, just ask around here or on discord and you should be able to get it!
I'm forbidden on discord so I can't grab files from it
http://titrek.us/downloads.php
Should have all the information you need.
Pre-0.0.95 Update
[Feature Addition] Server List
The client will come with the default game server IP pre-loaded (play.titrek.us). Should there be other hosted instances of the server elsewhere, the client will add the support for saving up to 10 of them, buy IP or hostname. You will be able to select from that list before the connection is started.
To facilitate this, the bridge will alter its functionality slightly. When you start the bridge it will at first only seek out the calculator and connect to it. It will not actually initiate a connection to a TCP socket until it receives the directive to do so from the client. This comes in the form of a 2-part packet, starting with the CTL code for CONNECT, followed by the hostname or IP string to connect to. The bridge will then respond to the client with CONNECT (allowing the client to proceed with starting the game), or with BRIDGE_ERROR, causing a return to the main menu.
Similarly, the client will tell the bridge when to disconnect, meaning you will no longer need to Ctrl+c to stop the bridge/disconnect.
[Feature Addition] Server List
The client will come with the default game server IP pre-loaded (play.titrek.us). Should there be other hosted instances of the server elsewhere, the client will add the support for saving up to 10 of them, buy IP or hostname. You will be able to select from that list before the connection is started.
To facilitate this, the bridge will alter its functionality slightly. When you start the bridge it will at first only seek out the calculator and connect to it. It will not actually initiate a connection to a TCP socket until it receives the directive to do so from the client. This comes in the form of a 2-part packet, starting with the CTL code for CONNECT, followed by the hostname or IP string to connect to. The bridge will then respond to the client with CONNECT (allowing the client to proceed with starting the game), or with BRIDGE_ERROR, causing a return to the main menu.
Similarly, the client will tell the bridge when to disconnect, meaning you will no longer need to Ctrl+c to stop the bridge/disconnect.
Update - v0.0.95
Planned to make this the full combat beta, but some security enhancements to the server and the whole setup make it necessary to release a client and bridge update before then.
NEW FEATURE - Client-Side Server List
As of right now, the server to connect to (through the bridge) is no longer controlled by the bridge's config file... it's controlled by the calculator itself.
Slot 1 is set by default and cannot be edited. Slots 2-10 are blank and can be edited (so that the game can connect to other hosted instances of the server).
The client adds 2 new packets, CONNECT and DISCONNECT.
Connect: Instructs the bridge to open a tcp socket to the server or host name following the control code in the serial packet.
Disconnect: Instructs the bridge to close the current socket.
* So long as the calculator does not unplug or disconnect from the bridge, you can connect/disconnect/reconnect without needing to restart the bridge. *
* Special thanks to commandblockguy for implementing this change. *
NEW FEATURE - On-Calc Mini-Log
The calculator has a 4-line mini-log, with each log-line buffered to 50 characters. This log can display errors, info, debug messages, and server broadcasts. The widget has variable height based on how many of the 4 lines it needs to display, and also remains on the screen for a configurable time. Default is 100 ticks. Any time a new message is written to the log, the clock resets.
And here is the new Settings interface to change the log timeout:
NEW FEATURE - Server Supports SSL
This may have been posted in this thread earlier, but the server is written with an optional SSL context. This can be enabled in the server config. The actual handling of certificates and renewal is not something the server does, so anyone hosting an SSL instance will need to handle ensuring their SSL config is up to date. The SSL path is also configurable, it just needs to be readable by whatever user is running this service.
*As of right now, the bridge does not support SSL, so any SSL servers will be unable to be connected to.*
NEW FEATURE - Verification-Based Authentication
As an attempt to dissuade connections to this service that are not from the calculator, such as random port probes or script kiddies, the server now implements a code-based verification system. When a user registers an account, an 8-digit code is generated and written to the user's account file, as well as sent to the calculator for display. You will be required to log into the web deck and input your verification code before you will be able to log in to the game server. This will allow us to filter unsolicited connections, as well as remove any anomalous user accounts created.
Also:
Planned to make this the full combat beta, but some security enhancements to the server and the whole setup make it necessary to release a client and bridge update before then.
NEW FEATURE - Client-Side Server List
As of right now, the server to connect to (through the bridge) is no longer controlled by the bridge's config file... it's controlled by the calculator itself.
Slot 1 is set by default and cannot be edited. Slots 2-10 are blank and can be edited (so that the game can connect to other hosted instances of the server).
The client adds 2 new packets, CONNECT and DISCONNECT.
Connect: Instructs the bridge to open a tcp socket to the server or host name following the control code in the serial packet.
Disconnect: Instructs the bridge to close the current socket.
* So long as the calculator does not unplug or disconnect from the bridge, you can connect/disconnect/reconnect without needing to restart the bridge. *
* Special thanks to commandblockguy for implementing this change. *
NEW FEATURE - On-Calc Mini-Log
The calculator has a 4-line mini-log, with each log-line buffered to 50 characters. This log can display errors, info, debug messages, and server broadcasts. The widget has variable height based on how many of the 4 lines it needs to display, and also remains on the screen for a configurable time. Default is 100 ticks. Any time a new message is written to the log, the clock resets.
And here is the new Settings interface to change the log timeout:
NEW FEATURE - Server Supports SSL
This may have been posted in this thread earlier, but the server is written with an optional SSL context. This can be enabled in the server config. The actual handling of certificates and renewal is not something the server does, so anyone hosting an SSL instance will need to handle ensuring their SSL config is up to date. The SSL path is also configurable, it just needs to be readable by whatever user is running this service.
*As of right now, the bridge does not support SSL, so any SSL servers will be unable to be connected to.*
NEW FEATURE - Verification-Based Authentication
As an attempt to dissuade connections to this service that are not from the calculator, such as random port probes or script kiddies, the server now implements a code-based verification system. When a user registers an account, an 8-digit code is generated and written to the user's account file, as well as sent to the calculator for display. You will be required to log into the web deck and input your verification code before you will be able to log in to the game server. This will allow us to filter unsolicited connections, as well as remove any anomalous user accounts created.
Also:
Log Lines Improvement
The duration of individual log lines is specific to that line now, and the log widget shrinks (while still displayed) as lines expire.
The duration of individual log lines is specific to that line now, and the log widget shrinks (while still displayed) as lines expire.
Anyone involved in testing this project out, please update your client immediately to 0.0.96. The download is available on the site page (http://titrek.us/downloads.php... older versions have been removed and their support by the server has officially ended.
This version implements a version check when connecting, to ensure you meet the minimum client version supported. If you are not using 0.0.96 or higher from this point forward, you may still be able to log in (due to no processing of the version check packet), but you may experience compatibility issues.
This version implements a version check when connecting, to ensure you meet the minimum client version supported. If you are not using 0.0.96 or higher from this point forward, you may still be able to log in (due to no processing of the version check packet), but you may experience compatibility issues.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2, 3 ... 8, 9, 10, 11 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 9 of 11
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement