SRL Archive - General

I blame myself for this, but there are a lot of "custom" methods in MSI that probably don't need to be there. While doing most of the writing myself, if there was something in SRL that I needed, but didn't work properly, I'd simply rewrite it for MSI rather than fixing it in SRL (which was a huge mistake, obviously).

So where does that leave us? Well, that's more shit to take care of, that could (probably should) be handled in SRL. I didn't really think about how much some custom functions would have to be maintained, or updated if RS updated. It doesn't really make sense to have a method for MSI and a method for SRL when only one is needed.

Obviously, there are some things that need to be customized, like object finding, but the other things should be converted to the SRL versions. I'm going to make a list of what I think should be changed, and we can begin to make some of them slowly over the coming months (hopefully). I'll also include some other changes that may be a good idea.

• A bug reporting form so bugs are reported properly. Can be viewed here.
• Magic.simba
• Should definitely use SRL's, no doubt. SRL's has been maintained beautifully, and there's no reason not to use it. It works with EVERY spell setup combination.
• Means for alching we'd have to find the ideal slot during runtime, but that's not a big deal.
• Banking.simba
• We don't need a custom banking function. If we have a bank that isn't supported to SRL, I'll add it to SRL.
• We should be able to utilize SRL's Deposit() and Withdraw() methods (may get rid of some withdrawing errors).
• Using CTS3 instead of CTS2.
• It's more accurate and we don't need to use modifiers.
• Should help some accuracy issues.
• Walking
• I'm working on an SPS2.0 branch, and it will include SPS_WindWalk. As far as I know, there's not a huge difference between that method and what we're currently using. I propose we strip MSI's walking down and use SPS's native methods.
• If SPS2.0 fixes all walking issues, it may be better just to leave it as is.
• Removing depreciated code/features.
• If there's less needless shit in the include, there's less to maintain. Simple.
• Remove extras system. It clearly didn't take off like intended, and only one working extra as been made. Bobzilla's stat's could be implemented right into MSI if we wanted.
• Remove tracking system (just Track.simba, not MSI_TrackObject). It's only used for objects, and hasn't proven to be particularly useful. Again, just Track.simba, not MSI_TrackObject (clearly very important).
• Optimizing code/combining some methods
• Combine MSI_WaitWhileFishing, WaitWhileWoodcutting and WaitWhileMining
• Combine MSI_CookAll and MSI_SoftenAll (exact same thing)
• Remove global arrays (not really that important, just here for reference)

Please, post anything you feel should be added to the list or any thoughts on what's already there.

Cheers,
Cohen

Finally. :smile: <jk>
Well, at least you already know how I felt about this. This is a wise thing to do. I really really know that feeling when you want to accomplish something but the tools are inadequate. (thats why SRL was made in the first place). I too have always used custom pieces of code; stuff I find very useful but never made it into SRL.

I am 100% with you on this.

Aww, I thought it was about something else lol. I totally agree though, and it should help with the amount of bugs that pop up.

Any good tutorials on CTS3? I need to learn how to use it :p

There aren't any real tutorials on CTS3, it's just one tolerance parameter. Mess around a bit with FindColorsTolerance and DebugTPA and see what works best for you :)

Ahh awesome, so no Hue/Sat? I actually just found Niels WIP thread about the ACA extension. Will look over the source :)

Thanks Markus!

Yeah, I changed the Pinball solver to use CTS3 for the new system, and all it does is this:

tmpCTS := getColorToleranceSpeed();
setColorToleranceSpeed(3);

findColorsTolerance();

setColorToleranceSpeed(tmpCTS);

No modifiers. I haven't debugged a lot, though, but debugging the pinball colors it seemed to be a little more accurate than CTS2, but from what I did, I couldn't notice THAT much.

@Kyle: What did you think it would be about?

I thought it would be something along the lines of streamlining bugs/issues from users, or making it where they have to post in a correct format lol. That would make our lives easier.

From: Kyle Undefined
I thought it would be something along the lines of streamlining bugs/issues from users, or making it where they have to post in a correct format lol. That would make our lives easier.

Something like mantis?

From: Coh3n

• Magic.simba
• Should definitely use SRL's, no doubt. SRL's has been maintained beautifully, and there's no reason not to use it. It works with EVERY spell setup combination.
• Means for alching we'd have to find the ideal slot during runtime, but that's not a big deal.

Do you remember when you came to me about changing from using SRL's magic.simba to having our own? :p

Anyways, SRL's had a couple bugs back then, that afaik have been fixed. I support this.

From: Coh3n

• Using CTS3 instead of CTS2.
• It's more accurate and we don't need to use modifiers.
• Should help some accuracy issues.

I haven't really messed with cts3 at all; is there any noticeable time difference? Even so, I still support using it where feasible.

From: Coh3n

• Removing depreciated code/features.
• If there's less needless shit in the include, there's less to maintain. Simple.
• Remove extras system. It clearly didn't take off like intended, and only one working extra as been made. Bobzilla's stat's could be implemented right into MSI if we wanted.
• Remove tracking system (just Track.simba, not MSI_TrackObject). It's only used for objects, and hasn't proven to be particularly useful. Again, just Track.simba, not MSI_TrackObject (clearly very important).

• It's just going to take time sitting down and comparing/ combining. As we've clearly noticed over time, most *skill* functions can be generalized and interchangeable with the other skills.
• definitely.
• Fine with me. I've never made much use of it either.

From: Kyle Undefined
I thought it would be something along the lines of streamlining bugs/issues from users, or making it where they have to post in a correct format lol. That would make our lives easier.

From: Zyt3x
Something like mantis?

I like mantis, but I can guarantee that 99% of people won't use it to report bugs. Plus, I don't like that you need to register to use it.

The members application has a form, right? I wonder if I can make one for reporting bugs. I'm definitely going to look into that.

From: NCDS
Do you remember when you came to me about changing from using SRL's magic.simba to having our own? :p

Yes, I remember. I don't know what I was thinking. >.<

From: NCDS

I haven't really messed with cts3 at all; is there any noticeable time difference? Even so, I still support using it where feasible.

There may be with MSI's object routines, but I may go through them and speed them up where I can.

From: NCDS
It's just going to take time sitting down and comparing/ combining. As we've clearly noticed over time, most *skill* functions can be generalized and interchangeable with the other skills.

That's something I'm hoping we can all contribute towards. Even if it's looking over half a file in 10 minutes of spare time. Hopefully we can get a good list going.

I'm going to add a few more things from the TO-DO thread, plus I'll add banking.

From: Coh3n
The members application has a form, right? I wonder if I can make one for reporting bugs. I'm definitely going to look into that.

That would be perfect. Combining the best of the forums and mantis into one… I like it!

From: Zyt3x
That would be perfect. Combining the best of the forums and mantis into one… I like it!

I may try the same thing for suggestions as well. Since people don't know how/are incapable of suggesting and filing bugs properly, we may as well do most of it for them.

Updated the first post

Having a form they need to fill out will help out, a lot!

Added Deposit() and Withdraw() to the Banking.simba part.

Going to implement this soon, just need to figure out forum permissions. Check it over, see what you think.

http://villavu.com/forum/misc.php?do=form&fid=4

Double poster! :p

Anyway, I love the form, that should help with the threads that get posted with little to no information.

Very nice!!

Done, check it out here. Zyt3x, you should still be able to make a thread there, but everyone else can't (except Admins and Mods).

Added:

• Walking
• I'm working on an SPS2.0 branch, and it will include SPS_WindWalk. As far as I know, there's not a huge difference between that method and what we're currently using. I propose we strip MSI's walking down and use SPS's native methods.

Thoughts?

That sounds good to me, so basically that means taking out the MSI wrappers out of the walking?

From: Kyle Undefined
That sounds good to me, so basically that means taking out the MSI wrappers out of the walking?

What wrappers?

It's a completely different system that accomplished (basically) the same thing as WindWalk with a few extra features (which I think I can keep).

E: If SPS2.0 fixes all walking issues, it may be better just to leave it as is.

Ahh ok, I haven't really looked into the walking. I just figured the MSI walking was wrappers just like some other functions/procedures. Sorry :p

From: Coh3n
Added:

Thoughts?

I don't see why we couldn't do that. I'm assuming the main function you're talking about is MSI_WalkPath, but even so, it wouldn't take too much.

From: NCDS
I don't see why we couldn't do that. I'm assuming the main function you're talking about is MSI_WalkPath, but even so, it wouldn't take too much.

Actually, it would get rid of all the functions from MSI_PointOnPath to MSI_EnterPath. MSI_WalkTPA would be edited to loop through each "control point", calling SPS_WindWalk for each, and MSI_WalkPath is what handles the obstacles.

But that being said, I'm crossing my fingers for SPS2 to solve any walking issues. :p