-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start a KickStarter #1053
Comments
|
The issue is not that he isn't working on TT at the moment, the issue is that no one else can work on it. None of the code is commented so no one else can pick it up or make heads or tails of it. He needs to get it fixed for 1.6 and 1.7 or pass the torch. It really was an essential mod. |
|
I've decided to start a development team to get around the need to use TT or have it fixed. We are going to create a server wrapper that initializes a job queuing system to farm out jobs to separate threads and processors as is needed. It will be designed to work with all major server systems (vanilla, bukkit, spigot, forge, mcpc+) from the start. There are too many people that depend on this work to be done and Nallar isn't working on it. Might as well do our own thing. |
|
Is it at all possible to make it Minecraft version independent? So launch a patcher that patches what needs to be patched without having to launch the server? If you can get a threading mod that would be amazing, I'd even bake you a cake and mail it. I can help... with like, morale and things :P |
|
That's what we aim to find out. I talked to a lot of people including some Mojang staff before starting this up. No one seems to want to do it, even though it is possible. It might just take a lot of work. As far as making it Minecraft version independent (between 1.5, 1.6, 1.7, etc), I'm not entirely sure this will be possible. But we will start work on 1.6 and move up from there. |
|
Well I might start leaning Java, I see so many things for MC I just want to fix lol. Maybe if I get good I can do something like you guys are. One thing I can do is give you guys a server to test on if you need it. I have it for free so no cost to me or you. Hosted out of Canberra, ACT, Australia. It's modest but does have a fibre connection and two Core 2 Duo processors. I use it for my Direwolf20 server at the moment, I have no problem testing your builds for you. |
|
That's generous, but we have it covered, thanks! We have several top of the line servers to test on. We have access to an e3 1245v2 w/ 32gb ram to suit many needs as they arise. |
|
The problem with version independence is just that bits of minecraft On holiday skiing, will be back on Monday. More developers are always
|
|
I love how Minecraft is near three years old and we still do not have a standard. No official API, lots of competing APIs. It's just a mess, and then there's Java, let's not get into why that isn't the best platform Minecraft could run on. Minecraft has really turned into two seperate games at this point, the one that Mojang updates and then the one that the modding community builds on top. |
|
@nallar Forge is the standard for anyone modding the game. Bukkit is for modding the server. They have different pros and cons. But it's the closest we have to a standard since the modAPI was cancelled. Java isn't the best way to implement this. And I've been told that even with oopl's such as java, Minecraft itself implements the objects in such a poor way that it causes more updates than should be necessary to process the same amount of data. Optimization is required. |
|
Can't just now, on my phone with intermittent internet access.
|
|
Alright! I'm usually online all day long. Drop by whenever. Can't wait to discuss the project :D! |
|
I think minecraft atm is in a state where noone really knows what Mojang wants and what to do. They keep pushing updates which help the vanilla users but break the modding community every time. now they implement name changes screwing every single player database over. While i think yes there is a fix needed for lag, i think its a task which takes too long in the scope of how quick Mojang changes well everything. We need a stable point. something in Minecraft which doesnt change for once. Untill we get that modding will allways be buggy/laggy or incomplete. Minecraft 1.4.5 was the height of Minecraft modding due to the fact that it stayed long and with minecraft 1.8 around the corner we have modders barely keeping up. I hope you make some progress with your project and id love to be able to help. Im not an expert at java but i understand code when i look at it. All i really have is experience with the mess called minecraft modding 😄 |
|
Maybe they need to do something like the Chromium project and fork Minecraft at 1.8. But you do have to remember that in the past Notch has stated he does not support modding for Minecraft, that he isn't a big fan of it, and I guess this is Mojang's drum beat too. If they don't support it then it will eventually be replaced by open source alternatives, and we don't want 100 different MC clients that arent compatible with one another, we need one unified source base that the community can contribute too and then the modpacks, a la Linux kernels and Linux Distros. |
|
@Voyevoda Fork minecraft? It was never open source in the first place, I doubt you can fork it without violating Mojang's T&C. |
|
'They' as in Mojang. Mojang needs to fork Minecraft. |
|
Mojang needs to wake up and smell the roses Nallar should have never had to even create this mod minecraft should have had implementation from the get go ive used my modified version of the the 1.5.2 tick-threading for close to 6 months now with no issues. It makes no sense to not have multithreading in minecraft servers when even when they started developing Minecraft there was multicore computers and they were common. |
|
@tf101-wizard That does sound well and good, but it's not just as simple as that. Multiple cores existing != coding for multiple cores is easy to implement. Yeah, Mojang could do it, but they would have to do a huge rewrite of their base code. I even talked to two Mojangsters a few weeks back and they said that it's on a list of things to do (add a job-queuing system) based on some things they learned how to do while working with the 360 and PE editions. It's also easy to say these things in hindsight, but it just wasn't the same when it started out. There was no expectation from Notch that people were going to start modifying the game to the extent that they do or that it would require the kind of resources that it does. He didn't have the kind of foresight necessary to see the demands of his future community, which is alright. However, the problem comes in when those demands have been clear for a long time and they do nothing to meet them even with their vast resources. Most people play the game in some modified form (Bukkit, Spigot, Spout, Forge, MCPC+, etc...), but none of these people receive any support from the company that has received tens of millions of sales. They still act like an indy startup. |
|
Yeah like my server that is a server that supports clients from 1.6.2-.1.7.9 right now + forge support it runs well and mojang would not be in the place that it is if not for the modding communities the player base has moved away from vanilla to modded sections and mojang needs to start supporting them in their efforts. Its whats making them the game they are and is not to over look |
|
@tf101-wizard I agree with you 100%. In fact, I think most people would. However, the modding API has died. They are moving away from modding. And now they have decided to make a plugin API. As someone said above, Notch has said in the past that he doesn't support modding Minecraft officially. Mojang has hired a lot of Bukkit staff, and anyone who knows about their stance knows that they don't support modding Minecraft at all either. My problem with this is that they are forcing their view of how the game should be played onto people rather than letting the player choose how they would like to play it. Most of the time (in most gaming communities where modding isn't a thing), that's fine. But with Mojang's extremely weak EULA and very stand back attitude about most things, this behavior is very frustrating. It's like they say, "You can do whatever you want to have fun with this game!... except you know the things we don't want you to do that we don't specifically state..." Dinnerbone didn't like my idea a few days ago to dump Minecraft onto github and let the community fix it for them. I think mostly it's fear. All they have is Minecraft. All of their other games are duds. If they don't hold onto it with an iron fist, they feel as though they will lose their only source of income. I think they lack creativity.. |
|
Actually it would be a good idea to dump it to github cause they don't have to implement the changes that people make into the git they only have to implement things they think are good or better implemented than the system they used. It might if you get 1000+ devs modifying building a game you can make a extremely stable, feature orientated game with little to no issues off the bat even with vanilla minecraft the more people looking over the system and fixing things that mojang over looked may actually help but its still their choice it implement it or not. |
|
@tf101-wizard This was Dinnerbone's response: https://twitter.com/Arcanis_/status/455711056069791744 ..... |
|
50% of 1.4.7 TT (which worked, and reliably) was writing the patcher, 25% Mojang making it threaded would only require the 25% of the time taken, @tf101-wizard https://github.com/tf101-wizard That does sound well and good, but it's not just as simple as that. It's also easy to say these things in hindsight, but it just wasn't the — |
|
Well, I've got a few people interested in picking this up and making it a thing again. It will go much easier if you are there. We have resources and cross-discipline programmers. We were getting ready to write something like this from scratch. But we won't have to if we all work together. |
|
Well we are in that place to its gotten to a point where we already have made own from scratch its quite the pain and they way we implemented it was way over thinked we need @nallar to make this as we can't seem to make anything worth using. Also if nallar is not going to make it in a considerable amount of time @Dark-Arcana are you going to make your rewrite public? |
|
@tf101-wizard Public, open source, freely available, etc. But until a viable model has been established and we know exactly how we want to do it, it's private. Haven't gotten off the ground yet though. Just in the planning phase. |
|
Well hopefully we can work out a deal to get some early access my servers that were 1.5.2 before ran perfectly on our 24 core server we run a bunch of 1.6.x servers now on it and its not utilizing all that we pay for so we have no problem testing. We need to get something working as right now its useless to keep paying for the box if we don't use it to its potential. Best Regards, Kevin Hawkins |
|
@tf101-wizard I understand. Most machines are useless. We have access to some of the most powerful systems available (single thread performance) and they can't stand up to Minecraft. I don't know about early access. Like I said, we are still in the planning phase. We have to know exactly what steps we want to take before we can take them =P. That being said, we at least want to do something because this is getting really old. Too many people depend on these systems to function, and they just don't. |
|
Also nallar if your in financial trouble on this let us know we can work something out as not having this for extended period of time put us in our own section of financial trouble cause it makes no sense to pay for powerful servers if they are not used. |
|
I support this motion! I'd be willing to help financially, or providing services (web, hosting, etc). This mod is vital for larger servers, and makes running with low levels of lag difficult. I'd love to see development pick up again, whether with a team, or just whatever. |
|
I'd say it's vital for any FTB server. Even if you're just playing with your friends, the complex world generation that packs like Monster and Direwolf20 force on the game really slow even the smallest servers down when you're playing with a small group of people. |
|
@Nentify That's actually a great point. The only thing about 1.7 that I think needs to be a thing in 1.6 that isn't... is the removal of ID's. They are so stupid to work with. Mojang can do their own thing and we can just sit back on an older version and have what we want without it breaking. And slowly over time patch up their junk code. Maybe if the community takes this approach and people stop updating, Mojang will finally get the hint? |
|
1.6 is actually a good base isn't it? 1.5.1 had some bugs and so did MCPC+ didn't it? I thought 1.6.4 was said to be relatively stable over the versions below it. |
|
1.6.4 is great so far as I know. I've heard 1.7 is filled with bugs. This would be a great place to stop. |
|
It is quite more stable it brought mostly more plugin and mod compatibility but at the end of the day our servers are only as strong as tickthreading. Without it we would be in a bad place and its time something is done. @nallar if you are reading this we will support you collectivly in every way we possiblibly can just remember that. |
|
I'd pay to see you work on it. Or at least comment it well enough so that other people can pick it up. About "asie's posts", the quote I believe is this: |
|
@asiekierka Every major release will break something. Thats why many developers are still on 1.6.4. Some have moved to 1.7 but still develop for 1.6.4. |
|
It'd be nice to be able to skip up to 1.7 - being stuck a version behind permanently isn't very good. What are people's thoughts on this? How long do we expect it'll be until everyone moves to 1.7? |
|
Most are waiting for a full stable API from forge. Its stable enough but not completely to how many are wanting |
|
Most major servers are still on 1.6.4. It's the most stable and modular build. 1.7 is still buggy as hell. blood over at MCPC+ is on an indefinite hiatus right now which is understandable from the amount of work he was doing, so mcpc+ 1.7 has stopped at build 51 and isn't receiving much maintenance. There is a push in the community to stay on 1.6.4 and backport new features from later versions of the game to 1.6.4 which has proven to be a very stable version. And then, when 1.7 has all of the bugs worked out and can be more easily moved to, we will do that. Those are my thoughts on the matter. |
|
It's difficult to say what version should be worked on. While 1.6 is a very stable build, we will probably move to 1.7 at some point in the future when most mods have updated. But by then, 1.8 will be round the corner. 1.6 feels like quite a stable platform at the moment, and I feel like a lot of devs will either update to both 1.7 and 1.8, or skip straight to 1.8. I don't feel, personally, a 1.7 version would be /extremely/ beneficial, seeing as 1.8 is so close. However, I can't really speak for a lot of modders, and a lot may be working on 1.7 ports still for all I know. |
|
Either way, 1.6.4 is a good place to start. Maybe add in a lot of commenting and get a few people who are willing to help you with your project and it won't be as hard to support a few different versions when the time comes? |
|
While porting to 1.7 may be tough, I believe jumping straight to 1.8 will be tougher. |
|
Getting more team members to help create and work on TT may also be beneficial and make it easier when it comes to MC updates. I'm sure others would be willing if code was commented and others knew how the code base worked. Also with what GUIpsp said, I can see how updating to 1.7 and then 1.8 would make work perhaps a little easier. |
|
@AbrarSyed What is the best way to replace the prepatcher? |
|
umm.. prepatching... well... For mods using ForgeGradle... The there is the setupDecompWorkspace which essentially does what the old setup did. Decompile, clean up sources, apply forge/fml patches and stuff, then these sources are recompiled into a jar. SO.. for prepatching.. there are a few ways you can do it. Warning you now though.. its not going to be easy
For both options above, this will take place after the forge or fml patches and binary patches are completed. If you are interrested in pursuing one of these paths, I can rig you up a basic setup (except the ASM and source editting) with which to do this stuff. If you are using a Dev workspace though (in the family of the Forge, Fml, and MCPC repos).. well... in such a workspace pre-patchng is kinda pointless. |
|
My other idea over prepatching is creating a fake class (A) that extends the class we want to patch (B) with all added methods, fields, etc. Then, at runtime, that class (A) would be merged into (B), and all references to (A) would be changed to (B), effectively side-stepping all possible compile problems. |
|
@GUIpsp That doesn't work too well, as for example I need to use PatchWorld.aMethodIAddToWorld. Now I have to cast World to PatchWorld any time that is used, which makes the code more complicated, makes refactoring more difficult, and makes my IDE complain. The prepatcher was created to avoid doing it that way. It also makes the bytecode overly complicated, and I can't be confident that a transformer I create to remove the casts will produce the same bytecode as not having the cast in the first place. That shouldn't break anything, but I'm concerned the different bytecode could break some optimisations made by java during JIT compilation. Just trying to use gradle to decompile stopped working without any changes on my end - seem to be having the same problem as this person on the forge forums. It worked before going on holiday for a week. I've tried deleting my .gradle directory then performing a clean install from 9.11.1.964, still gives that error. The non-gradle 1.6.4 build system has also been broken for some time, so it seems it's impossible to build for 1.6.4 now unless you have an already set-up workspace. @AbrarSyed, that would be really helpful :) By ASM patching you just mean that I need to return patched class bytes? Presumably modifying the class using another library such as javassist is still possible. That should work perfectly, and in fact is more elegant than the current solution of applying regexes to source files which are broken by minor formatting changes in what MCP produces. Method 2 sounds correct. I've had no experience with gradle so far. By setting up a workspace similar to Forge/FML/MCPC+, is it still possible to maintain compatibility with both MCPC+ /vanilla installs? Doesn't that produce a full MC server jar? I had considered a hackish workaround of modifying the source jar using the current prepatcher, and modifying the classes in the compiled jars in the ~/.gradle directory, due to a lack of experience with gradle. Your method 2 sounds much better! |
|
@nallar Most optimizations done by javac are peephole optimizations. Those will still happen because they happen within the context of a function. You could make your IDE ignore that cast warning. While this isn't as clean as abrar's option 2, it's much, much simpler. Also, it would be better to talk about this over IRC or TeamSpeak. |
|
We have an irc open specifically for talking about this at #TickThreading on Esper. |
|
|
@GUIpsp I'm just worried that some of the runtime optimisations made by java's JIT may not work correctly if the bytecode is overly-complicated, and the extra casts are liable to do that. Depends on how general its optimisations are - I have no understanding of the inner workings of the JIT. I'll check if there are any discussions of other JVM languages seeing bad performance compared to java due to runtime optimisations being too specific for the way javac generates bytecode, you may be right that it won't matter. Still doesn't solve the unclean code issue, but it's a lot better than it not working at all. Would it be possible to manipulate the bytecode before the source jar is created, so that the bytecode manipulations automatically create the source changes too? |
|
@nallar Extra casts would be either be removed by our manipulations or the JiT. |
|
For the decomp workspace.. it goes like so.... |
|
For anyone reading this comment thread, we're currently discussing on IRC and I'll post a summary here when we're done. Abrar is being awesome :) |
|
@AbrarSyed has provided this example gradle script here: https://gist.github.com/AbrarSyed/e2e4a9047d5f08d8dc0e Should have it commited and working some time soon. |
|
What is the irc? |
|
irc.esper.net:6667 and channel moved to new official channel #TickThreading |
Everywhere I look, people wish TT was still a thing. Tech servers are drowning in lag. My server is barely staying above 20tps because of extensive maintenance, but any more players and I can see it dipping really fast. I requests MCPC+ add tickthreading and blood said no. I looked for other things such as job queuing with something called gearman. I even talked to Mojang and they said they will be making a job queuing system in the future. But at their pace of development and the devastation that is 1.7, modded servers won't be seeing anything like it for a long time.
I've looked through posts, I read your issues here. Either you're being lazy (whatever, I can understand not being motivated haha), or you have other pressing matters going on in real life. But I'm sure server owners and players especially would love to be able to enjoy their games again. Why not start up a KickStarter campaign (or something equivalent, I was just using that as an example) to get a feel for how much people want it and to help raise money for you to work on it.
Help us end the lag... It's pretty bad.
The text was updated successfully, but these errors were encountered: