Posts by Two

There should maybe a check in the net code that if sender and receiver are the same, it does not transmit power over that segment. This should prevent several pointless loops you might accidentally construct when wiring in tight space.

Quote from Elessar_Elanesse

Hmm sort of wish the recipes for plantballs was configurable.

Use extrabiomes and it has a bunch of stuff that you could compact into plantballs. Same with twilight forest, unless it's a issue on those mods sides?

I understand that you want to add recipes to be able to turn other plant-stuff into plantballs, correct? Adding IC recipes is easy to make as a mod, but that probably belongs in the suggestion/modding section then.

Quote from Equidox

Argelbargel y u use strange letters xD cant read this stuff

This is encoded Computer Science: if you read letters like these, you know that very soon solutions for all your problems will be ready. Just don't ask for the details...

Quote from Saul_Goode

Have you ever tried dev'ing wasted?

I am beyond that point.

Quote from Saul_Goode

Other than that- Alblaka, Richard, Featnuri and Player have shown themselves to be rather intelligent individuals. If they were able to figure out how to mod minecraft then I'm sure they can figure out how to set up an auto-build system.

Just imagine for a second that one of the devs is coming home from work wasted and only wants to spent some quality time with his girlfriend or the TV (whatever is available) and not setup servers, maintain code or a community. I have no doubt that they are capable of doing that, but setting up all that stuff primarily takes time. And that is why I said: if we ask them to do that, it is only fair if we assist them.

My idea on a brainstorming was not to tell them how to do the entire open-source thing properly, but to give them ideas on what can be done. You for example mentioned a good point, that bying a GITHub space costs 100$ a year, so who is going to pay that? Are there free/cheaper alternatives? These and many other details are things that we, the community, can brainstorm about and in the end present the IC team a set of options to choose from (or ignore all if they choose to), so they do not have to take the time to do that brainstorming. In addition there is a good chance that someone from the community knows a solution that none of the current dev team knows about, so providing that idea as a possible solution might solve some issues the team alone wouldn't have been able to solve in such a good way.

As I wrote in my recent post: only the IC team decides the way to go, however giving ideas and ready-to-be-used solutions will take a lot of time off their head and in general make the whole thing a lot easier for everyone. It has been very kind of Alblaka to give into the wishes of the community to such an extend and I figure it would be kind of rude if that community now just sits and waits for them to do all the work.

Quote from Saul_Goode

Alblaka has made his semi-final comments on the situation, the only think left is to sit back and give him a chance to get with Richard, Featnuri and Player to internally plan their next moves.

Yes, he said:

Quote

My current 3 issues are:
-I've got no clue of the technical implementation of the two things mentioned above.
-I could neither reach Player nor Richard so far.
-Actually I'm supposed to be learning instead of typing this '

So in short: he has some clear ideas, but no idea how to implement them properly nor the time to actually do this. So I took the liberty to start a brainstorming thread on this to for once flesh out that idea a bit (it's always the details that hurt in the end) and for second come with some solutions or people to stand up and say "I'll do this for you".

Imo it is only fair that if we ask Alblkaka to go open source, that we help him on that.

As things start to get mixed up, I created a post on how to do this open source in the suggestion board: The IC² might go open source brainstorming thread.

Repost from the other thread:

Some ideas I had during lunch on how to define the development process in an open source community version:

- Use GIT differently from how you're using it right now (~Alb). It has the wonderful option to create as many branches as you want and merge them together usually flawlessly. This allows people to submit minor changes on a one-per-branch base, without affecting development on other branches. People should do baby-steps here in the beginning as one branch/commit per bug, as I expect the code-base to be volatile once this is really open until the major things have been done.

- In general everyone can pull the code at any time from any branch. This allows devs, wannabe-devs and testers to have a look and maybe give their feedback and input.
- To get commit rights, one must first send in a patch file that is reviewed and if considered accepted, the person is granted commit rights. This is the base hurdle so only those who really want to contribute (and know how to use their tools) are able to request permission. More on the commit rights later.
- For all Alblaka as the Mod-Owner has the last word. Only he may accept feature changes and he reserves the right to reject everything he doesn't like.

There are 3 main branches:
- Experimental: This is where Alblaka (and maybe others) pur in their ideas/major code changes, the "What if?" branch. Only requirement: game must still be playable, as in "doesn't crash too often". Bug-fixes may happen but are not required.
- Development: One a feature or set of features has been accepted, it is put into the development branch. Here all bug-fixes happen and ideas/code might get improved or slightly modified (under the control of Alblaka) with the target to have a fully releasable version in the end. Requirement for all commits is to be compilable and fix bugs/improve code without introducing new bugs.
- Release: Once a development branch has been stabilized enough, it is branched out to a specific release version branch. Once this is done that version is considered released and only bug-fixes that address stability issues may happen to this branch. New features or improvements of existing features do not belong here. There is a minimum delay of 1 month per release, so not every minor change caused server admins the trouble to update.

To sort out those who contribute to the mod and those who rather don't contribute, the Jenkins build system uses a Karma-System (there are several existing plugins for that), that in general gives points to good contributes and decreases those points for bad commits. As an idea:
- Everyone starts with 0.
- Every commit that works fine and fixes bugs gives +1.
- Every commit that works but introduces more bugs that it fixes gives -1.
- Every commit that does not compile or has other very obvious bugs as in "You never tested this even once!" gives -5.
- If someone gets too low on score, his commit rights are revoked.

While the "not compiling" thins is pretty easy to measure (compile fails), the big question is how to detect the amount of bugs added/removed. Tools like FindBugs might be helpful here. On the other hand those only detect coding bugs and not logic bugs. so some kind of human interaction seems to be inevitable.

Other things:
- For every branch there is a thread/mailing list so people can give feedback to the right code and version.
- There should be a standardized way of submitting bugs/requests. The primary focus here is ease of use as I expect more non-technical feedback than actual coders to use it. This doesn't have to be a highly sophisticated tracking tool, even the forum could be a solution, just something that works fine for the task.

As you maybe read in this thread, Alblaka is considering to make IC² an open-source project with the current IC² team as the main drivers and everyone else has access to the real sources to fix bugs or be able to write addons in a much easier way than before. The big question is how to do that in a way that it is more helping than hurting?

As this is all just a hobby project for Alblaka and team (surprise, they don't get payed for it), a concept must work in a way, that the team does not have more work to do than they currently have. In an optimal world they just put in their ideas and they get magically fixed and improved so we all have a perfect IC² version in the end. This includes things like:
- How to restrict write access to the source in a way that only those who really contribute have it?
- How to check progress and quality of code mostly automatic?
- How to handle code submits which are incompatible or not helping?
- How to manage the whole thing from a technical perspective?
- How can people submit bugs and verify that they are fixed?

As no one is perfect, keep in mind that mistakes in all kinds of form in this project will happen on a common basis and detecting and removing those needs to be included in the idea. Don't expect people to be all without mistakes, you might get surprised.

I already found some bronze boots in a dungeon chest, right in the first one I encountered. As with everything random: it might be that you are lucky and can't find any in 10 dungeons in a row, then find some in the next 5 chests.

Quote from selurgniman

Actually this isn't the way you should use git

The idea above is actually part of the intention from the author of GIT Linus Torvalds himself, I shamelessly copied that.
In general the main advantage over SVN and other repository systems is that GIT is able to handle branches usually flawlessly. It can switch and merge branches within milliseconds and that gives you the great advantage that you can work with any kind of code state that you have "saved" in a branch at any time.

Imagine the following: you just work on the master branch, commit all stuff there and then you have this idea you really need to try. A few weeks later you realize that this idea isn't going to work and you'd like to undo it, but reverting to the state 2 weeks ago as well will kill several hundred bug-fixes you made on the way. With everything just in the master branch, you'd be lost at this point. Now do the same with 3 branches: master, idea and bugfix. Since your idea hasn't been done yet, it hasn't been committed to the master branch yet, but all bug-fixes have been. The moment you realize your idea isn't going to work, you just delete that branch and there you go. And even if you happen to have it already committed to the master branch previously, you can still pull out the one from 2 weeks ago, re-apply the bug-fix branch and again: there you go. This is the way you should use GIT.

In addition this idea above is actually the result of a 2 years brain-storming and prototyping of several teams in a major company and I can tell you: it does work great if done correctly.

Quote

Github has a built in issue tracker.

Might work, as long as people accept it. The main issue with bug-trackers is that most people just can't figure out how to use it in the first 5 seconds and then just don't. As I expect that many bug-fixes will come from non-technical community members, so people who have no experience in proper bug-handling and reporting, the tool used should take that into account as one of the major points.

Some ideas I had during lunch on how to define the development process in an open source community version:

- Use GIT differently from how you're using it right now (~Alb). It has the wonderful option to create as many branches as you want and merge them together usually flawlessly. This allows people to submit minor changes on a one-per-branch base, without affecting development on other branches. People should do baby-steps here in the beginning as one branch/commit per bug, as I expect the code-base to be volatile once this is really open until the major things have been done.

- In general everyone can pull the code at any time from any branch. This allows devs, wannabe-devs and testers to have a look and maybe give their feedback and input.
- To get commit rights, one must first send in a patch file that is reviewed and if considered accepted, the person is granted commit rights. This is the base hurdle so only those who really want to contribute (and know how to use their tools) are able to request permission. More on the commit rights later.
- For all Alblaka as the Mod-Owner has the last word. Only he may accept feature changes and he reserves the right to reject everything he doesn't like.

There are 3 main branches:
- Experimental: This is where Alblaka (and maybe others) pur in their ideas/major code changes, the "What if?" branch. Only requirement: game must still be playable, as in "doesn't crash too often". Bug-fixes may happen but are not required.
- Development: One a feature or set of features has been accepted, it is put into the development branch. Here all bug-fixes happen and ideas/code might get improved or slightly modified (under the control of Alblaka) with the target to have a fully releasable version in the end. Requirement for all commits is to be compilable and fix bugs/improve code without introducing new bugs.
- Release: Once a development branch has been stabilized enough, it is branched out to a specific release version branch. Once this is done that version is considered released and only bug-fixes that address stability issues may happen to this branch. New features or improvements of existing features do not belong here. There is a minimum delay of 1 month per release, so not every minor change caused server admins the trouble to update.

To sort out those who contribute to the mod and those who rather don't contribute, the Jenkins build system uses a Karma-System (there are several existing plugins for that), that in general gives points to good contributes and decreases those points for bad commits. As an idea:
- Everyone starts with 0.
- Every commit that works fine and fixes bugs gives +1.
- Every commit that works but introduces more bugs that it fixes gives -1.
- Every commit that does not compile or has other very obvious bugs as in "You never tested this even once!" gives -5.
- If someone gets too low on score, his commit rights are revoked.

While the "not compiling" thins is pretty easy to measure (compile fails), the big question is how to detect the amount of bugs added/removed. Tools like FindBugs might be helpful here. On the other hand those only detect coding bugs and not logic bugs. so some kind of human interaction seems to be inevitable.

Other things:
- For every branch there is a thread/mailing list so people can give feedback to the right code and version.
- There should be a standardized way of submitting bugs/requests. The primary focus here is ease of use as I expect more non-technical feedback than actual coders to use it. This doesn't have to be a highly sophisticated tracking tool, even the forum could be a solution, just something that works fine for the task.

I am wondering where all these bad vibes against open source are coming from and especially that idea that every coder out there on this forum is a crappy coder. Beside that being a bit insulting and far from the truth, I'd like to give another idea to this:

Imagine you are the best coder in this world and you go to a forum for a game played by all kinds of ages. Usually in those forums about a hand full of people are very active, post comments on everything and especially insult everyone trying to "harm" their beloved game. Happens here, happens in basically every other game forum as well. Now you see people posting "crappy" code. You could go and post to point out the mistakes and how to make everything better in just a few minutes, but the best chance for an answer is that above hand-full of people rampart your answer and shit-storm about it for the next few days. And now imagine you are old and experienced enough to know that this will happen.

This doesn't only apply to good programmers, but probably to everyone else who is especially good at something and has many other worries than to argue with random people over the Internet. And now please think about it why all of a sudden people you never heard of before post in this thread. And why those hand-full of shit-stormers (love that word) harm their beloved game more than they are doing good by doing that.

Quote from Monoxide

If you overflow a buffer then you'll be writing into memory that contains whatever the operating system put there. One run it could be unused memory, the next run the OS might allocate that space for another variable in your program. Hence, different results from the same code. I didn't say anything about changing the buffer size.

Don't want to ruin your discussion, but we are talking about Java here, buffer overflows cannot happen in Java.

If he choses the right words... I don't want to debate that, he however has one big point that I'd like to point out: there are people playing and enjoying the mod a lot (including myself), and the recent update wasn't really in a state where could call it done from just the technical/stability point of view. Now you can just say "Well it's beta" or "I don't have the time/motivation right now to fix that", everyone would accept that, but you didn't say anything at all, and that actually is an issue.

I think we can agree that writing a one-line explaining what will happen or not is within your available time, so the question is why didn't you do that? Now you already explained that this is a hobby for you and I can very well understand your situation, and although it is all your choice to decide to "abandon" the project at any time, doing that at a time where an update is definitely needed, is kind of spitting into the face of the users. I understand that IC is your baby and you don't want to give it into other peoples hands, but on the other hand please understand that there are a lot of people having fun playing it, and "taking it away" from them is about the same as taking it away from you.

Now to be constructive, what are you options that do not "spit in someones face" ?
Beside the obvious to give that project to someone else - which I understand you don't want to - there are lesser methods of opening the project. I think what fits your situation best would be to open the code for bug-fixes only. In short that means everyone can fix bugs/optimize the code, the community has to manage that on its own (and that usually works well), but no one but you implements new features unless you agree on them or define them on your own. All other changes need to be put into the mod section.

The steps are rather easy: just open the GIT to everyone and define the rules. People will eventually setup a build server, arrange the development in the forum and control each other's commits through a community driven process. Work for you: almost zero, benefit for the mod: you will receive a well tested, well written and properly working version of the code. And you don't have to worry about controlling that, as usually whenever there is a position to fill, someone accepted by the community will stand up and do that. That is about the way Linux development works, and that one works fine for ages already.

Will someone steal the code?
As I already mentioned in another thread: if someone wants to, it takes minimal effort already to do so, and so far no one did that.

Will someone take over the project from you?
I think no one will every deny that you are the one and only "father" of IC, therefore as long as you decide to stay that, people will in the end follow your decisions regarding the development. And if tomorrow someone decides to pretend he is the inventor, community will usually shit-storm these people till they are quiet.

While Alblaka has a point one might ask why it is not possible to at least release a bug-fixed version for at least the major things (mostly crashes) within some reasonable time, especially the trivial ones. Or at least attach a message that due to RL issues (or whatever else) an update might be delayed so people at least know what to expect.

If time is short or at used in a better way, there is still the option to make this mod open source with a controlled development. That means the IC² team controls the direction but everyone can fix bugs, similar to how Forge does it. Releasing a very buggy version but then doing nothing to solve that is a big downer.

Quote from FenixR

Closed source to me means "You can't have access to the ORIGINAL source we have, period", yes you can decompile IC2 and Minecraft but how many errors that gives you (And in the case of ic2 how many things you lose), you say it only takes you 5-15min to decompile but thats because of MCP and the really helpful tools they provide. Ever tried to decompile minecraft or ic2 without MCP?

Not every "Closed Source" code in this world have their own useful "MCP".

Closed Source just means that you are not allowed to modify, distribute or publish the source code in any form unless permitted by the author. This is a pure license question and not whether or not you actually have the source code. Even though I was able to decompile the source-code, which is by the way thanks to Java almost exactly the same as the IC team has (so no errors or lost stuff), I still cannot just distribute/publish/release it. There are several projects which work under a closed source license even though the source code can be just downloaded for various purposes.

Yes of course I am using MCP, why wouldn't I? If I had to do it without it might take another 15 minutes to setup the decompiler first. I think you are a little mistaken here on the complexity of doing that with Java code.

Nevertheless it would be still very helpful if the IC team would release a non-obfuscated JAR for the modders out there.

Quote from RawCode

I suggest you to perform two stage decompilation for better results:

This was about what I did except for the update names part, which left me with field23423 parts all over the IC code for vanilla functions. Thanks! Going to try that once I am back home.

Quote from RawCode

suggest to run code inside your head, this allow to debug ever without running game, this really helps and allow to write code in single run.

This only works as long as said compiler knows how functions work, but if you don't know Minecraft code literally out of your head, the simulation might come up with different results.

Quote from FenixR

Yeah but that would beat the purpose of being a "Closed Source" project. You just gotta deal with it or pile up your coding and test when you absolutely must do it, not after every little change.

Closed Source is a relative term, it took me 15 minutes to decompile the IC² jar to get the complete source-code. Now if I would spend some more time to get it to work with Forge that should do it, however having a downloadable version would make things a lot less painful. Decompiling the "Closed Source" Minecraft by the way only takes about 3 minutes thanks to MCP. What defines closed source is just the license on top of it.

The big question is whether or not the IC team wants modders or just acknowledge the fact that they exist. Since there is an API I guess that they do want them, a logical next step then would be to give out a development version for the sole purpose of being able to use it together with the Eclipse-Forge version. The work here for the team is minimal, as they just need to zip the stuff they have on their hard-disk anyways, and the IMS license still holds true the same way as before.

Thinking about it for a while made things clear: if IC² jar references classes by their obfuscated names, but the src obviously de-obfuscates, so the jar cannot access the Eclipse-compiled code as of the different names of the functions.

That is kind of a downer for IC development, as compiling/re-obfuscating then copying the stuff into the original jar is not only tedious but even if automated takes several seconds to complete and then it is still not debuggable. However to solve this you would need the source code of IC² or at least a non-obfuscated jar to work with.