SRL Archive - Devs' Corner

Commit log


Naike

2010-10-18 05:31:41

This is getting messy again, there needs to be a standard set up. I initiated a good system before I stopped developing. Place *all* constants into a constants.simba for each folder used (module). This way, they are central.

Everything should be included itself. The point of reflection was that people only needed to include one file if they wanted it. I never got around to doing this, but it involves using {.include_once X} for all files that each one needs. That way, one can just include one file at a time if they need it. For example, MSI could just include walking for tiles.

There needs to be a better walking system. The current TileToMM is not random enough. It creates the same point of the tile each time, this could easily be modified with some maths, I just do not have time to do that.

Well, all in all though, I am glad for these changes. Good job, and keep it up. I will keep checking in and modifying some things. Please read this and follow the standards. It helps us all.


Some things with the new commit log..

  • The include was a mess way before I laid my hands on it.
  • The include_once theory is great, but having a messy include doesn't really help anything along from the start.
  • Constant.simba ? We can't have all the consts in one file. As if someone new comes along and wants to look at them he needs to scroll through 300 lines of a total mess to get where he wants. Function Consts, such as objects even confused me when I was looking for them. I really don't see the benefit in this?
  • TileToMM is suppose to do that.
  • I want the include to head where you're thinking, but updating the log switching var names and telling me what I should do, not what we could do nor doing a poll, seems like a punch in the face.

In other words, it seems like you're trying to boss around with us.
Also remember, picking up this include after not developing on it for a year I find it being very little support. Most talking on what should be done, from all parts. As I've stated in few other threads, I'm at least trying.

Nava2

2010-10-18 12:39:23

First of all, its been two months.

What I changed is arbitrary, thus I believed there would be no issue with changing it. variable names are not a big deal, IMO. If it is, I apologize, and we can move back a revision, followed by a poll to see what people think.

I actually do not think the Include is a mess.. I was unclear. I meant standards wise, I would rather see the include follow one set of standards and move that way. Inconsistency is annoying, I do not care which standards are used, but I believe that they should be consistent.

Drags and I had agreed on the Constants.simba for global variables as well as constants. It makes it much more focused and obvious where everything is. For example, you would put the random constants into the constants.simba in Core/AntiRandoms/. Again, if you don't like it, lets have a poll.

Nothing wrong with TileToMM doing that, but when people use TileToMM then just walk using it, its not exactly the best option. I bring it up because the old system was very obvious. If JaGeX merely checked the position of clicks correlating with tiles on the minimap, it would be an instant obvious flag/ban. Yes, they have better ways of detection, but why give them another?

To sum up, I believe you took the log as a lot more agressive than the intent was. Yes, I am a little annoyed that you and others got access without my knowledge. I have been working on this project in and out for a very long time. I would have given it to you, but you did not ask. Nor did pyro, etc. etc.. If you wanted to play a team sport, you should have actually informed the team.

Lastly, I am in no position to be a completely active developer. I can be here for support and small things, but I have too much work with school and my job to spend the time needed to tweak a lot of this. I also have other projects on the go that I would rather spend my small amount of free time on. (Its just prioritizing, no other reasoning here)

More lastly (fail..), I have no intention of bossing people around, but I also do not want to let things crumble and revert to the way it was before. I took a lot of time in fixing the include multiple times, this time its in the best shape I've seen it and I want to keep it that way.

Naike

2010-10-18 14:47:12

I'm playing a team sport.

But you didn't want to give me access before, why would you give me owners so I can promote people that are doing a good job? Nobody developed this include, and when I do, I'll have my own ideas, opinions and reasons of doing things. If nobody is here to discuss with then it's fairly easy to pitch in a week later. I'm not trying to start a war, I want the opposite. However, if the very few developers and the people that knows how it works want something I'm forced to change it no matter of my opinion(and this goes by you as well, team sport, remember?).

I see two solutions, which there was from the very beginning..
  1. We play as a team, and talk with each other. We poll code which is going to be added(if it's not obvious, such as fixes ect..) and we continue to drive this include forward with all of our shared knowledge. There's a handful of reflection developers now, let them vote, lets use them for once.
  2. We don't play the team sport, and everything just goes back to back to being broken..

Leave pyroryan out of this, as I was the one giving him access.

Nava2

2010-10-18 15:06:08

From: Naike
I'm playing a team sport.

But you didn't want to give me access before, why would you give me owners so I can promote people that are doing a good job? Nobody developed this include, and when I do, I'll have my own ideas, opinions and reasons of doing things. If nobody is here to discuss with then it's fairly easy to pitch in a week later. I'm not trying to start a war, I want the opposite. However, if the very few developers and the people that knows how it works want something I'm forced to change it no matter of my opinion(and this goes by you as well, team sport, remember?).

I see two solutions, which there was from the very beginning..
  1. We play as a team, and talk with each other. We poll code which is going to be added(if it's not obvious, such as fixes ect..) and we continue to drive this include forward with all of our shared knowledge. There's a handful of reflection developers now, let them vote, lets use them for once.
  2. We don't play the team sport, and everything just goes back to back to being broken..

Leave pyroryan out of this, as I was the one giving him access.


Firstly, there was neither reason nor insinuation that pyroryan did anything wrong here, he was only used as an example of people moving behind my back. I sincerely dislike the concept of progression as individuals. We are a team here. I really don't know why you think otherwise.

Actually, I was willing to give you access. That is where I get confused. You have a grudge against me for something, yet I do not fully understand why yet. I do not appreciate the attitude of ``It's all shit'', but frankly, I do not think anyone would. While it may be slower and harder to develop and work as a larger team, in the grand scheme the ideas of many is far superior to that of one. Hence the open source philosophies.

Communication here has been limited, and in the big picture I think that the issue is as such. We need to communicate more and do more. But not have one without the other. The movement without communication has made myself personally feel ``out-of-the-loop'', among others.

This include is great, will be greater. I do think that some things need to be changed. As well there needs to be some form of standards put into place to maintain order.

Wizzup?

2010-10-18 15:09:55

From: Nava2
Actually, I was willing to give you access. That is where I get confused. You have a grudge against me for something, yet I do not fully understand why yet. I do not appreciate the attitude of ``It's all shit'', but frankly, I do not think anyone would. While it may be slower and harder to develop and work as a larger team, in the grand scheme the ideas of many is far superior to that of one. Hence the open source philosophies.


It definitely took _way_ too long before he got access though. It took me to convince Benland to add him.

Naike

2010-10-18 15:17:15

If you're not around, not developing, of course you'll miss out?

We are a team, but if you're busy, as everyone else is, I can't go ahead and look up every single one of you.. I tried to in the beginning, posted stuff, asked people ect..
But I can't do that every single time, I could, but it would take 3x the time.

I do agree on the standards, what's your msn again?

Narcle

2010-10-19 15:19:16

First off I'll say this, the Reflection include has about as much "global standardization" as SRL include does atm, which really isn't much.

Second due to the inactivity/activity of the include right now I think first come first serve is in the right. As long as it gets done and works well is fine by me. I don't think anyone has the right to criticize about having standardization when they don't have time to do it themselves, this includes myself.

Some standards can be fixed later, right now there is a good basis that either of you can use.

If you want to make a major standard change check with the other 'current' reflection devs if its okay first, maybe even make a poll.

I rather have a working included then to have it delayed by those that "don't have time." Just my $0.02.