grimreaper1357
Member
Why did this thing get invented anyway?
What's the point of the SDK?
- Thread starter grimreaper1357
- Start date
The SDK is a top secret weapon; used by us terrorist. We are trying to take down the Government aka 'Cogwheels RTAB'
SDK stands for 'Super-Duper-Kittens'. Which is the code name.
Beware; The SDK can make your life happy.
Seriously; I think its a scripting tools. And its improve compabilities with others script. Some people said it doesn't increase compabilities, and it made it worse. Well, that's because they do not know how to use it correctly.
SDK made my coding a lot simpler, and I learned how to use it from Trickster, and I believe that SDK is a lot better than the defaults.
'Un-SDK this, Un-SDK that' is quite annoying among us scripters, but they cannot accept that SDK is best thing that happened to RMXP.
Just post in the SDK topic if you are keen to find out more about it's features and how to use it. Not to judge it.
If you disregard this message. Drop dead.
SDK stands for 'Super-Duper-Kittens'. Which is the code name.
Beware; The SDK can make your life happy.
Seriously; I think its a scripting tools. And its improve compabilities with others script. Some people said it doesn't increase compabilities, and it made it worse. Well, that's because they do not know how to use it correctly.
SDK made my coding a lot simpler, and I learned how to use it from Trickster, and I believe that SDK is a lot better than the defaults.
'Un-SDK this, Un-SDK that' is quite annoying among us scripters, but they cannot accept that SDK is best thing that happened to RMXP.
Just post in the SDK topic if you are keen to find out more about it's features and how to use it. Not to judge it.
If you disregard this message. Drop dead.
grimreaper1357
Member
Kuri$u;208773 said:The SDK is a top secret weapon; used by us terrorist. We are trying to take down the Government aka 'Cogwheels RTAB'
SDK stands for 'Super-Duper-Kittens'. Which is the code name.
Beware; The SDK can make your life happy.
Seriously; I think its a scripting tools. And its improve compabilities with others script. Some people said it doesn't increase compabilities, and it made it worse. Well, that's because they do not know how to use it correctly.
SDK made my coding a lot simpler, and I learned how to use it from Trickster, and I believe that SDK is a lot better than the defaults.
'Un-SDK this, Un-SDK that' is quite annoying among us scripters, but they cannot accept that SDK is best thing that happened to RMXP.
Just post in the SDK topic if you are keen to find out more about it's features and how to use it. Not to judge it.
If you disregard this message. Drop dead.
I don't like the way you make it sound that anything non-SDK is crap.
Feels like the SDK is trying to be forced on everyone.
I doubt that SDK must be used.
Its a choice for people to use SDK or not. For example, you can't use Trickster's RTAB system (TRTAB) without SDK, which leave people no choice. Get my drift? SDK are commonly used with scripters now-a-days than the past where people used to edit the defaults.
SDK is no where better than the default, (Like the SDK topic say) but personally, I think its better, many opinions varies.
Its a choice for people to use SDK or not. For example, you can't use Trickster's RTAB system (TRTAB) without SDK, which leave people no choice. Get my drift? SDK are commonly used with scripters now-a-days than the past where people used to edit the defaults.
SDK is no where better than the default, (Like the SDK topic say) but personally, I think its better, many opinions varies.
Yeah no one is forcing anything on anyone
If you need some reading
SDK Topic
SDK Tutorial Mr. Mo (Possibly Outdated)
But all the SDK is is a set of scripting conventions (limit the use of globals, indent your code, commenting and class names, aliasing > overwriting), A scripting tools module (shows a list of aliased methods, shows a list of all scripts added (provided it the script calls SDK.log), an event_comment_input method)), and finally it splits up the default classes methods which is pretty controversial.
You don't have to use the SDK if you don't want to.
If you need some reading
SDK Topic
SDK Tutorial Mr. Mo (Possibly Outdated)
But all the SDK is is a set of scripting conventions (limit the use of globals, indent your code, commenting and class names, aliasing > overwriting), A scripting tools module (shows a list of aliased methods, shows a list of all scripts added (provided it the script calls SDK.log), an event_comment_input method)), and finally it splits up the default classes methods which is pretty controversial.
You don't have to use the SDK if you don't want to.
grimreaper1357
Member
Let me see if I understand:
All SDK script are compatible with each other but non-SDK scripts can't be used with the SDK? So all proyects will be SDK or Non-SDK?
So the point of the SDK is that all scripts are compatible? :/
All SDK script are compatible with each other but non-SDK scripts can't be used with the SDK? So all proyects will be SDK or Non-SDK?
So the point of the SDK is that all scripts are compatible? :/
Not really :
The deepest SDK modification is splitting the default classes.
Were you to paste an aggressive in its modifications script below the SDK, it would work. However, it would mess with the delicate separation the SDK provide, rendering SDK scripts which would normally cohabitate peacefully useless.
The SDK allows you to partially guarantee the compatibility of the scripts by letting them screw less with the system.
As I said, a big, destructive script will mess with that, and render the whole thing useless.
Basically, you get :
- Better compatibility if your scripts are well-coded
- Quasi-total incompatibility if your scripts aren't.
For example, my recent released scripts don't use any sdk functions but should fit perfectly with SDK/SDK scripts, as they don't erase anything. However, this is not a perfect world, so you have to make a choice.
NB : To be fair, some script might not work due to other sdk aspects, but this is not the main point here.
The deepest SDK modification is splitting the default classes.
Were you to paste an aggressive in its modifications script below the SDK, it would work. However, it would mess with the delicate separation the SDK provide, rendering SDK scripts which would normally cohabitate peacefully useless.
The SDK allows you to partially guarantee the compatibility of the scripts by letting them screw less with the system.
As I said, a big, destructive script will mess with that, and render the whole thing useless.
Basically, you get :
- Better compatibility if your scripts are well-coded
- Quasi-total incompatibility if your scripts aren't.
For example, my recent released scripts don't use any sdk functions but should fit perfectly with SDK/SDK scripts, as they don't erase anything. However, this is not a perfect world, so you have to make a choice.
NB : To be fair, some script might not work due to other sdk aspects, but this is not the main point here.
Yeah Rataime is correct, code your script correctly and it won't make me cry (as rataime said once :p)
in addition to what rataime stated if one script overwrites a method SDK splits up there may be no breaks in compatibility as long as you don't have an SDK script using one of the methods that was in the split up that was overwritten
Also there could be a chance that two SDK scripts will not work, if you have two SDK scripts overwriting one of the split up methods for example you will have some problems, but the newer versions of SDK keeps track of overwritten methods (as long as the scripter calls SDK.log_overwrite) and it will disable the script and give a message to the user stating that script A and script B are not compatible.
in addition to what rataime stated if one script overwrites a method SDK splits up there may be no breaks in compatibility as long as you don't have an SDK script using one of the methods that was in the split up that was overwritten
Also there could be a chance that two SDK scripts will not work, if you have two SDK scripts overwriting one of the split up methods for example you will have some problems, but the newer versions of SDK keeps track of overwritten methods (as long as the scripter calls SDK.log_overwrite) and it will disable the script and give a message to the user stating that script A and script B are not compatible.
http://www.jessett.com/portfolio/illust ... /hippy.gif[/IMG]
Sweeeeet dude!!! *smokes a joint*
But yeah, Trickster/Rataime is correct.
"Better coded > Crappy coded"
And yeeeah dude... If you don't like SDK, don't use it,
THE FAMILES MUST NOT USE SDK! They must stick with the default!!
Dude!
Sweeeeet dude!!! *smokes a joint*
But yeah, Trickster/Rataime is correct.
"Better coded > Crappy coded"
And yeeeah dude... If you don't like SDK, don't use it,
THE FAMILES MUST NOT USE SDK! They must stick with the default!!
Dude!
Personally, I don't use the SDK in my projects because I make custom scripts, but I use the SDK in my public scripts because I usually aliase alot and edit default scripts, so I need to increase the compability with other scripts(that use the SDK format).
For example:
SDK 2.0 has a new class called "Scene_Base" aka god. Why? It does the following automatically.
- Updates
- Disposes
What else? It breaks up scripts into little organized parts. Just imagine if your room did that...(anyone can hope.)
Another example:
Lets say I have to edit a default script but 'oh no!' I can't edit the method in the script because its together and I need to edit the middle of the method but SDK comes to the rescue because it does this to:
def method1
[code..1]
[code..2]
end
this:
def method1_1
[code..1]
end
def method1_2
[code..2]
end
Now I can just aliase.
For example:
SDK 2.0 has a new class called "Scene_Base" aka god. Why? It does the following automatically.
- Updates
- Disposes
What else? It breaks up scripts into little organized parts. Just imagine if your room did that...(anyone can hope.)
Another example:
Lets say I have to edit a default script but 'oh no!' I can't edit the method in the script because its together and I need to edit the middle of the method but SDK comes to the rescue because it does this to:
def method1
[code..1]
[code..2]
end
this:
def method1_1
[code..1]
end
def method1_2
[code..2]
end
Now I can just aliase.
DerVVulfman
Sponsor
Older scripts (before... March 2006?) didn't have the 'luxury' of the SDK, and a number of scripters prior to its creation coded scripts in their own manner.
The key is to ALIAS whatever you can when you code your script/system. If done properly, you can achieve a great range of compatability with or without the SDK.
During tests, even 'I' use an SDK temp project... as well as other temp projects utilizing whatever systems I'm coding for. I make it a point that the systems that I'm coding could be used with whatever system that I am familiar with.
Or just dangerous with...
The key is to ALIAS whatever you can when you code your script/system. If done properly, you can achieve a great range of compatability with or without the SDK.
During tests, even 'I' use an SDK temp project... as well as other temp projects utilizing whatever systems I'm coding for. I make it a point that the systems that I'm coding could be used with whatever system that I am familiar with.
Or just dangerous with...
SephirothSpawn
Sponsor
The SDK was created simply for people like us (people who like to spend hundreds of hours hearing the communities thoughts and trying to make everything run smooth) hear hundreds of member whine, moan, complain, and mis-intrepret everything rather than reading the hundreds of lines of explanation in the SDK, the paragraphcs upon paragraphs of of description in the SDK topic, etc. We want everyone to hate it, because we are forcing you to use it.
In all seriousness, the SDK was created to make scripters lives more helpful. Before the SDK, I was making scripts about every 3 days. Unfortunately, once my name was noticed, I started spending more time fixing my scripts and trying to make them work for everyones individual game. I had no time to script, just support.
Then Near and Rataime put out the idea of the SDK. At first, I was confused, lost, and didn't think I would script for it. Once I got the idea behind it, I loved it and now, I won't script any other way. It makes everything much easier for me personally, because I don't have to hear "Make it work in my project."
Now, chances are it will work because it requires the SDK. I still hear "make it non-SDK", which isn't ever going to happen. I might point people in the right direction, but I would (and am) rather write a tutorial on converting SDK scripts to non-SDK and vice versa.
There is a lot of debate over SDK 1.5 and the new SDK 2.0+. This is really BS! The SDK 2.0+ is probably 200% if not more better than the 1.5. A, we fixed dozens of bugs that went undetected in the 1.5 version ; B) we divided up the SDK into multiple parts, so people don't have to use certain parts if their scripts don't require them ; C) we have included a error detection system that will now even record aliased and over-wrote methods to help find and detect scripts that conflict with eachother, which just rules ; D) We have added things like the Scene_Base class, which was developed to make Scene management in RMXP a hole lot easier. Many complained about the early 2.0 release, because we removed some methods, renamed some methods, etc., but the SDK 2.0+ patch fixes all of these concerns. There is no difference really. Most scripts (99%) of the SDK 1.5 scripts will still work if you have all 4 parts of the SDK 2.0+, its just now, more methods have been split, so scripts that over-wrote these methods have less a chance working, not that they have been over-writing these methods in the first place.
I think the SDK team and supporters have given more than enough time, patience, and reached out to help people who don't understand, don't support, etc., and get treated rather poorly in return.
Even if you don't code for the SDK, if you code properly, your script will probably work with the SDK, possibly only needing minor adjustment. No one is saying non-SDK < SDK or anything like that. All we are saying, is that for public copy-and-pasters, the SDK is the best thing for you in all truth. If you can script, you don't need the SDK and may only use things like the Scene_Base class.
In all seriousness, the SDK was created to make scripters lives more helpful. Before the SDK, I was making scripts about every 3 days. Unfortunately, once my name was noticed, I started spending more time fixing my scripts and trying to make them work for everyones individual game. I had no time to script, just support.
Then Near and Rataime put out the idea of the SDK. At first, I was confused, lost, and didn't think I would script for it. Once I got the idea behind it, I loved it and now, I won't script any other way. It makes everything much easier for me personally, because I don't have to hear "Make it work in my project."
Now, chances are it will work because it requires the SDK. I still hear "make it non-SDK", which isn't ever going to happen. I might point people in the right direction, but I would (and am) rather write a tutorial on converting SDK scripts to non-SDK and vice versa.
There is a lot of debate over SDK 1.5 and the new SDK 2.0+. This is really BS! The SDK 2.0+ is probably 200% if not more better than the 1.5. A, we fixed dozens of bugs that went undetected in the 1.5 version ; B) we divided up the SDK into multiple parts, so people don't have to use certain parts if their scripts don't require them ; C) we have included a error detection system that will now even record aliased and over-wrote methods to help find and detect scripts that conflict with eachother, which just rules ; D) We have added things like the Scene_Base class, which was developed to make Scene management in RMXP a hole lot easier. Many complained about the early 2.0 release, because we removed some methods, renamed some methods, etc., but the SDK 2.0+ patch fixes all of these concerns. There is no difference really. Most scripts (99%) of the SDK 1.5 scripts will still work if you have all 4 parts of the SDK 2.0+, its just now, more methods have been split, so scripts that over-wrote these methods have less a chance working, not that they have been over-writing these methods in the first place.
I think the SDK team and supporters have given more than enough time, patience, and reached out to help people who don't understand, don't support, etc., and get treated rather poorly in return.
Even if you don't code for the SDK, if you code properly, your script will probably work with the SDK, possibly only needing minor adjustment. No one is saying non-SDK < SDK or anything like that. All we are saying, is that for public copy-and-pasters, the SDK is the best thing for you in all truth. If you can script, you don't need the SDK and may only use things like the Scene_Base class.
blueparukia
Member
really? A guide on converting scripts is coming..yay!!
The only reason I don't use SDK is because the battle system I use was made before SDK (I think).
I've always wanted to implement your SDK mini games in with my scripts, but I need to convert. If you understand more programming languages, maybe you should make a program where you just paste the Non-SDK script and convert it - though, (I don't understand the finer applications of RGSS), but if you have to change a lot of things, then that would be near impossibel.
Anyway, thanks,
BP
The only reason I don't use SDK is because the battle system I use was made before SDK (I think).
I've always wanted to implement your SDK mini games in with my scripts, but I need to convert. If you understand more programming languages, maybe you should make a program where you just paste the Non-SDK script and convert it - though, (I don't understand the finer applications of RGSS), but if you have to change a lot of things, then that would be near impossibel.
Anyway, thanks,
BP