» Goto page Previous  1, 2, 3 ... 6, 7, 8, 9, 10, 11  Next
» View previous topic :: View next topic  
I have replaced the exec function with:

Code:
 echo `/usr/local/bin/convpng -i /home/trek/server/{$makefile} >> /home/trek/www/srv/convpng.log &`;


The webserver no longer hangs, but the error log says the following.

Code:
/usr/local/bin/convpng: 1: /usr/local/bin/convpng: Syntax error: word unexpected (expecting ")")

Also, nothing gets piped to the log file.
Update

Thought I'd post on this so people know this project isn't dead... again.
Since much of the substance of the game has to wait for a functional USB and/or TCP/IP library to begin networking aspects, progress has slowed on the calc side of the game. In the meantime, the website has seen a redesign, coming to look less like an informational mess and more like something eye catching... and something that uses the CSS Flexbox model so that it scales a bit better to random browser sizes.
http://titrek.us
Our social media buttons, Donate button, Financial statements, and Web Deck (in-game customizer) are now moved to the footer, Disweb is removed because it was slowing my page load times and was like... always down. Most of the social media buttons, except for the RSS one, is just a link now.

As for in-game progress, there is *some*. Since I had to destructively revert from Catalina to Mojave, I ended up losing the tail end of progress on the game, where I designed the module pop up informational window. As the saying goes, what doesn't kill you makes you stronger... said pop up is now even more spicy than it was. It's still a WIP, but screenshot is here.
I like the new website! But it isn't working perfectly on my computer. The buttons on the bottom of the screen are too low and only a bit of their upper portion is showing. Other than that, I really like the new feel of it.
Argus wrote:
I like the new website! But it isn't working perfectly on my computer. The buttons on the bottom of the screen are too low and only a bit of their upper portion is showing. Other than that, I really like the new feel of it.

Can you post a screenshot?
Here:

I cannot scroll down to the buttons.
Argus wrote:
Here:

I cannot scroll down to the buttons.

I can't view this. Check viewing permissions, or use imgur.
I'll just use google drive: https://drive.google.com/open?id=17jLMDJCCVOz6vxVCfufHRtIU5bAeQt3f
That seems to be unfortunately an issue caused by the Dock on your computer that renders on the bottom on top of the browser window. Sadly, I cannot do anything on my end to prevent that.
Ok I guess it's fine. I don't use that computer too much anyway, it's really bad.
* I deleted the previous message because the bug I was having was fixed *

UPDATE

Project TI-Trek has now been successfully compiled with full USB support... using srldrvce. Due to wonkiness in CEmu's usb support, it is no longer possible to test networking on the emulator (the lib cannot initialize the driver properly). I will need to move to on-unit testing for the remainder of client-side development of this project. I have gotten written the ntwk_Login(), ntwk_Register(), and ntwk_Disconnect routines, which are the first aspects of gameplay that will be tested. While I have been hard at work on client-side things, commandblockguy has been working on a USB=>IP bridge similar to the one Kerm devised for gCn over DirectUSB. And last but not least, beckadamtheinventor has been hard at work developing the server side of things... from map generation to control codes and saving/loading data. For those interested, the server is written in Python, runs on port TCP 1701 (the registry number of the Enterprise), and uses json for long-term storage. It stores connection descriptors to an array of Client objects, which also contain the IP address, username, and some more information about the connected user.

The game will implement semi-accurate space physics. When the map generates, the server pre-generates some paths for celestial bodies using formulas for things like gravity and inertia. Those objects will follow those paths every tick, scaled to the time-rate of the game. In addition to fluidity in space (meaning planets, starbases, etc will not be in exactly the same spot every time you look for them), other objects will pose a threat... black holes will exist and end your journey very fast. Stars will tick their life cycle and then die in a manner determined by their size. Major celestial events, such as star death or planet destruction will result in a path-adjustment for entities within gravitational range of the changed section.

Also, after discussion with beck, another feature will be added to the game, called a synthesizer. This component will allow you to interact with materials you own on a molecular level to enhance them in certain ways. For example, say you place a piece of tempered steel into the synthesizer. You can then select from reserves of any type of element, and the properties they enhance/detract from will most reflect their actual chemical properties (toughness, deflection, malliability, heat resistance, etc). Say you choose to combine the tempered steel with a type of element that increases toughness but decreases heat resistance. You would wind up with steel (hull plating, for instance) that provides a boost against projectiles and physical impact, but is damaged more by heat sources, phasers, and the like. You could also, for instance, infuse your hull plating with a mineral that enhances magnetism, which in turn enhances your shield deflection. And if you attempt to combine unstable materials, you could, for example, wind up inflicting feedback damage to an attacking enemy, but also winding up with vastly increased damage to your own ship.

For anyone wishing to have a look at the code-base so far (yes, it will need some optimization), here it is. I will say, in my opinion, at least the network handling is remarkably well-organized... for what I usually do.
https://github.com/acagliano/titrek-calc
Wow... I can't believe that you can finally connect the calcs together! It's a big step, and an exciting one. This is going to be one game that I will surely play a lot when it comes out.
Well it's not the calcs you are connecting together technically. You're plugging your calculator into a computer running the serial=>IP bridge. The bridge is translating USB speak into IP speak and forwarding it to the server.
UPDATE and Help Needed (Testing)

Another good day of work on the game. I was able to get an input routine, courtesy of beck, for inputting the username and password to log in to the network. While you await log-in, a pop up occupies the screen, informing you that the game is trying to log you in. This message remains until the client receives a registration success packet, or receives some other form of message, such as invalid login, banned, or account doesn't exist.

I also changed how the game's assets are handled. Formerly they would be extracted to the BSS and sit there until freed by the program exiting. Now, whenever you launch the game, the game checks for the presence of either appvar trekgui or trekGFX. trekgui is an updater, it contains compressed sprites. trekGFX is created by the game, shortly before extracting the assets into it, moving it to archive, and then passing it's pointer to the convpng-generated initialization routine. trekgui is then deleted. As long as you have trekGFX, you no longer need trekgui. Should you need to update sprites, you only need to send a new trekgui to your calculator, and it will update your assets database. This is how assets will be handled for the foreseeable future, as the priority will be getting gameplay itself working; sprite stuff can wait when there's a system that works.

Here's where the help request comes in. Beck has been experiencing keyboard lockups and crashes when pressing [Clear] to exit the game loop. I experience some keyboard lockups, but no crashes. I am asking people to please grab version 0.0.90 from https://github.com/acagliano/titrek-calc/tree/master/bin. Experiment with it and inform us of any crashes. You can come to the game's discord server: https://discord.gg/3GxXhE3 and submit a big report there. If you experience weird behavior from the game, please provide your hardware revision, your boot and base code, your OS version, and the version of the C libs you are using. This requires a UBS mini cable and srldrvce and usbdrvce to test.
There is a good to fair chance this will crash your calculator, but shouldn't do any lasting damage beyond that. Make sure you back up anything you need before testing.

Thanks in advance.
Update

Confirmed through a packet analyzer that calc => computer communication is working.


Now need to work on computer to server, and make said communication 2-way. The existing command I used to test (on my Mac) is:

Code:
netcat remote.titrek.us 1701 > /dev/tty.usbmodem1432401 < /dev/tty.usbmodem1432401

It is my understanding, however, that this is only a 1-way bridge... calc to computer and server to computer. It doesn't send to the server, nor does it respond to the calc. Correct me if I'm wrong.
Update

As of 5 minutes ago, all 7 legs of the networking system for the game work.
Client packet creation: Working
Client => Bridge: Working
Bridge => Server: Working
Server Analyze/Response: Working
Server => Bridge: Working
Client Analyze/Response: Working

Here's a video of the login/register in action: http://titrek.us/gallery/demo-vids/NetworkTest1.mp4

It's unfortunate that this game network has so many failure points. Literally 7 per packets sent. If we/I/command can convince those who deal with Libload to support nanotube, and I can develop for that, we can reduce it to basically 2/3 points of failure. But until then, this is the best I can do.
Quick Update:

In ~2 weeks time, Version 0.1.0 will be released. Also, this is the nomenclature I will be using:

MAJ.MIN.REVISION

Revision number incrementation will mean alpha releases (or feature additions)
Minor number incrementation will mean beta releases to fix alpha features (or 0>1 will indicate a transition from alpha to beta for that featureset)
Major numbers will increment to indicate that the latest added featureset is stable.
So for the current pre-releases, 0.1.0 will be the first beta release, but will be only with some of the networking packets implemented. After that, incrementation of the 3rd number will indicate the addition of more packet handlers, incrementation of the second will be bugfixes for existing features.

As for what this release will allow testing of:
1) Basic graphics (interface, key input, etc)
2) Login, Registration, Default Ship creation, Ship loading
3) Anti-cheat code
4) Version checking upon login:
[As you can see at http://titrek.us, the homepage now shows server information, including IP, earliest supported client, number of users connected, and more.]
Although the IP is posted, I will ask everyone to NOT try to actually connect until I give you guys the go ahead. We are still wrapping up testing and bugfixes over the next 2 weeks before we get this prerelease out.

Also special thanks to beckadamtheinventor who's work on server has been incredibly valuable, and thanks to commandblockguy who wrote the server<=>client bridge we have been using for testing. If you care enough to poke around, you probably can locate the code to this project (client, server, and bridge) however, while I will not stop you from doing so, I will not share it rn to avoid potential use of potentially unstable code.
Unrelated question: since the game is able to talk to the server, could it fetch software updates?
Xeda112358 wrote:
Unrelated question: since the game is able to talk to the server, could it fetch software updates?

At some point perhaps there may be a sort of "nexus" server for calc software updates. TBD though
Xeda112358 wrote:
Unrelated question: since the game is able to talk to the server, could it fetch software updates?

The problem with software updates is you'd have to hand over control to a program that writes new data to the program and to saferam, then updates the size word, which is quite hard to do in C. It might require an assembly "updater program" that is launched with assembly (inline), but inline asm is currently unsupported by the llvm toolchain.

You can, however, do normal asm.
Progress Update

** This is quite lengthy. Bear with me. **

Beck and I have been hard at work hardly working on both client and server stuff for TI-Trek. In the meantime I have been working on the rewards plaques for the sprite design contest winners and contributors, working on a redesign of the Web Deck, and implementing the LoadShip and NewGame packets client-side.

To fill you all in on the packet system the game uses:

Code:
INBOUND
void ntwk_process(void) {
    uint8_t i;
    static size_t packet_size = 0;

    for(i = 0; i < 2 * settings.limits.packet_limit; i++ ) {
        if(mode->process) mode->process();

        /* If the device was disconnected, exit */
        if(!gameflags.network) return;

        /* Handle input */
        if(packet_size) {
            if(mode->read_to_size(packet_size)) {
                conn_HandleInput((packet_t *) &net_buf, packet_size);
                packet_size = 0;
            } else break;
        } else {
            if(mode->read_to_size(sizeof(packet_size))) packet_size = *(size_t*)net_buf;
            else break;
        }
    }
}

The code above essentially reads the in-buffer, non-destructively until it has a 3-byte size word, then strips that and waits for size bytes, then reads that to in_buf. Once we have a full packet, the processing routine is called.

Code:

typedef struct {
    uint8_t control;
    uint8_t data[1];
} packet_t;

void conn_HandleInput(packet_t *in_buff, size_t buff_size) {
    uint8_t ctl = in_buff->control;
    uint8_t response = in_buff->data[0];    // for handlers needing only response codes
    uint8_t* data = &in_buff->data[0];      // for handlers needing arbitrary data
   
    switch(ctl){
   // handlers for each control code
   // response and data both point to the same thing, however, response is a 1-byte value, the *value at* the first byte of data (used for response codes for packets with no data), meanwhile, data is a pointer to the data for packets with data.
   }
}

Embedded within the packet-in and packet-out routines is a switch that changes the routines called for all the networking functions to use either slrdrvce or the pipe functionality in CEmu's USB branch, depending on a special assembly routine that detects CEmu.

Note: The packetizer functions, the switch, and the following packet-send code was all contributed by commandblockguy


Code:
OUTBOUND
bool ntwk_send_(uint8_t num_parts, uint8_t ctrl, ...);

#define PS_STR(str) (str), 1+strlen(str)
#define PS_VAL(val) (val), sizeof(val)
#define PS_ARR(arr) (arr), sizeof(arr)
#define PS_PTR(ptr, size) (ptr), (size)

#define ntwk_send(ctrl_code, ...) ntwk_send_(VA_NARGS(__VA_ARGS__) / 2, ctrl_code, __VA_ARGS__)
#define ntwk_send_nodata(ctrl_code) ntwk_send_(0, ctrl_code)

The code above uses a max-5-segment variable argument function, where you can build a packet using "packet segment" builders. These also can operate in either srldrvce mode or CEmu pipe mode.

The bridge software (also contributed by commandblockguy) can also be launched in pipe or calc mode, though it can be a bit of a pain to get the bridge to recognize and initialize the CEmu pipes... just keep trying it a few hundred times and eventually it will work (jk, but not really).


Last but not least, for those with the requisite patience to have made it to this point in the post, I have a request for advice from ya'll. We are thinking about how to implement a "New Game" system. The options are as following:

1) New Game simply deletes your existing game data, and generates you a new ship from scratch.
2) New Game deletes your existing game data, generates you a new ship, but also gives you materials/credits/etc equivalent to your prior progress, minus a percentage to incentivize not restarting.
3) New Game allows you to create a "new player" associated with your user account without overwriting any existing ones. This would allow multiple players per account.

I'll let you guys sound off on which of the 3 options you would most prefer to be implemented.



** Networking Functions Planned **

*** Implemented ***
Register
Login (this serves as login/register. If account doesn't exist, another gui pops up to complete reg)
Disconnect
Program Autoupdate

*** To Be Implemented ***
Request Chunk
Request Entities
Request Sensor Data
Request Module Details
Graphics AutoUpdate (will work in tandem w/ Program Auto for updates with graphics changes)

And last but not least, the new Web Deck: http://play.titrek.us
On this version of the Web Deck, you CANNOT register an account using the Web Deck. You can only Log In to an account already created via calculator login. This is done deliberately, to ensure that the only accounts created are ones that will actually be playing.

A first public (beta) release of the existing functionality as described above is not too far off. Stay tuned.
  
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
» Goto page Previous  1, 2, 3 ... 6, 7, 8, 9, 10, 11  Next
» View previous topic :: View next topic  
Page 7 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

 

Advertisement