Yep, sort of considering that included in the checkstyle and module extraction items
If only there were more hours in a day I could totally do all the things!
Cervator's work thread
- Thread starter Cervator
- Start date
If only there were more hours in a day I could totally do all the things!
We used single-player connecting to a local server in Footbrawl Quest, it is messy and I wouldn't want to do that in general. It is particularly unfriendly when multiple copies are running due to port conflicts, and you would essentially use double the memory with the server and client having separate state, not to mention chew up performance serializing and deserializing packets between the two ends running in the same JVM. Plus we'ld have to fix up all our singletons, which would be a huge mess (hate singletonsMultiplayer is the main thing to adjust all this after - what would be best to place when/where. I know we don't have a dedicated server setup yet and am wondering if local single-player would just use the trick to connect to a local server. In that case maybe it would make sense to have server stuff in its own sub-project that can be run separately and if needed tweaked for other platforms (like split-screen multiplayer on the OUYA) yet included normally in the standard client. Immortius - that's your expertise so I'd be happy to hear your take on it
).The way I'm heading at the moment Singleplayer is essentially a listenserver that doesn't allow connections. The localplayer(s) don't have a connection, but instead just exist in the world and are controlled directly.
For split screen play we would need to get the camera system sorted out to work with entities and allow multiple viewports, and have support for different input sources going to different player entities. Both reasonably achievable, and much more performant with network connections and clients out of the picture.
Doing some professional side cleanup after vacation as it inspired some wanderlust. Updated my LinkedIn profile and used a picture I had taken in Iceland in full viking regalia
If you can't have a little fun, your work aspirations are in the wrong place! Speaking of which, I added Terasology to my profile, though I stopped short of including my EVE Uni career as another job position
Feeling quite energized after vacation so going to make this thread move some more soon, dangit!
If you can't have a little fun, your work aspirations are in the wrong place! Speaking of which, I added Terasology to my profile, though I stopped short of including my EVE Uni career as another job position
Feeling quite energized after vacation so going to make this thread move some more soon, dangit!
Okay, progress at last! I'm trying to balance between contributor reach-out, general organization, and actually doing some work myself. Finally attached the module split-out to the point where something visible.
I've got Git commands that'll extract a module out of the current code base into its own repo on GitHub. It maintains commit history in the new repo which is important IMHO to keep attribution. Here's Portals in its own home (under the Nanoware test org). Wonder if could make "mod.txt" into a README that'll get displayed on GitHub yet still be parseable for the info we need.
Likewise we can fully remove the modules from the main code base including all history - beyond just doing a delete. I'm not sure that's really a good idea after testing it though, as doing it rewrites every single commit ever which beyond taking a while also splits a new branch into its own thing. You can see that on the network branch right now or on the Nanoware branches page - after removing Portals the "rewritten" branch is 2,225 commits ahead and 2,165 commits behind
If you scroll back on the network graph you can see both MovingBlocks and Nanoware contain roughly the same history, especially back before much was done for Portals. Oddly enough the two constructs do converge, but waaaay before we ever had modules, like only a dozen or two commits from the founding (they split in an ancient commit from begla about the light system, no clue why)
In addition to that I've got Gradle working with Git tasks and automatically cloning remote repos based on a passed parameter. Supports picking the organization/user as well, so modules could be fetched from different spots. Needs more work though. In addition to cloning the repo the module should also be configured as a sub module in IntelliJ like they currently do, and would independently maintain their own Git roots
My suggestion is that when Immortius is happy with the multiplayer branch we break off the modules and either finish deleting them in that branch or rewrite history to get rid of them. Then any non-module changes in develop we can consider bringing over manually. Or maybe we can do it early and get modules to work fully externally first. Will keep tinkering with it - for now I need sleep!
I've got Git commands that'll extract a module out of the current code base into its own repo on GitHub. It maintains commit history in the new repo which is important IMHO to keep attribution. Here's Portals in its own home (under the Nanoware test org). Wonder if could make "mod.txt" into a README that'll get displayed on GitHub yet still be parseable for the info we need.
Likewise we can fully remove the modules from the main code base including all history - beyond just doing a delete. I'm not sure that's really a good idea after testing it though, as doing it rewrites every single commit ever which beyond taking a while also splits a new branch into its own thing. You can see that on the network branch right now or on the Nanoware branches page - after removing Portals the "rewritten" branch is 2,225 commits ahead and 2,165 commits behind
If you scroll back on the network graph you can see both MovingBlocks and Nanoware contain roughly the same history, especially back before much was done for Portals. Oddly enough the two constructs do converge, but waaaay before we ever had modules, like only a dozen or two commits from the founding (they split in an ancient commit from begla about the light system, no clue why)
In addition to that I've got Gradle working with Git tasks and automatically cloning remote repos based on a passed parameter. Supports picking the organization/user as well, so modules could be fetched from different spots. Needs more work though. In addition to cloning the repo the module should also be configured as a sub module in IntelliJ like they currently do, and would independently maintain their own Git roots
My suggestion is that when Immortius is happy with the multiplayer branch we break off the modules and either finish deleting them in that branch or rewrite history to get rid of them. Then any non-module changes in develop we can consider bringing over manually. Or maybe we can do it early and get modules to work fully externally first. Will keep tinkering with it - for now I need sleep!