Merging of core and scripts

[Atomic]

I'm thinking about making an executable that compiles the scripts subfolder and a core one(with the core code) into an executable only. The compiler would be removed from the core code, which would only load the world, making starting the server up faster and recompiles optional. Other advantages:
-Being able to remove some extra interface code (like IAccount) that makes some casts mandatory to integrate core and scripts
-Being able to use code defined in scripts in the core (for example, using a check in the item packet to see if the PlayerMobile has IsHallucinating true..)
-Being able to change stuff in the core easily (like accesslevels), recompiling with just a double click
-Making it easier to send just a Server.exe file and the Data/Saves to your host, instead of sending the entire scripts folder

So, what do you guys think about it?



EDIT:
Did it! With only one method modified in the core It isn't half as optimized as it could be, and definately not well tested but it does the job :P

With this mod the server still verifies scripts on startup, dunno if I should move that to the compiler to make it even faster...

WARNING: Do not try this out on a real shard, this is test only, only try it if you know what you're doing..

On ScriptCompiler.cs, use this Compile method instead of the original one:

		public static bool Compile( bool debug )
		{
			int a = 0;
			m_Assemblies = new Assembly[] { Core.Assembly };

			Console.Write( "Scripts: Verifying..." );
			Core.VerifySerialization();
			Console.WriteLine( "done ({0} items, {1} mobiles)", Core.ScriptItems, Core.ScriptMobiles );

			ArrayList invoke = new ArrayList();

			for (a=0;a<m_Assemblies.Length;++a)
			{
				Type[] types = m_Assemblies[a].GetTypes();

				for ( int i = 0; i < types.Length; ++i )
				{
					MethodInfo m = types[i].GetMethod( "Configure", BindingFlags.Static | BindingFlags.Public );

					if ( m != null )
						invoke.Add( m );
						//m.Invoke( null, null );
				}
			}

			invoke.Sort( new CallPriorityComparer() );

			for ( int i = 0; i < invoke.Count; ++i )
					((MethodInfo)invoke[i]).Invoke( null, null );

			invoke.Clear();

			World.Load();

			for (a=0;a<m_Assemblies.Length;++a)
			{
				Type[] types = m_Assemblies[a].GetTypes();

				for ( int i = 0; i < types.Length; ++i )
				{
					if ( !types[i].Equals( typeof( Server.Network.NetState ) ) )
					{
						MethodInfo m = types[i].GetMethod( "Initialize", BindingFlags.Static | BindingFlags.Public );

						if ( m != null )
							invoke.Add( m );
							//m.Invoke( null, null );
					}
				}
			}

			invoke.Sort( new CallPriorityComparer() );

			for ( int i = 0; i < invoke.Count; ++i )
				((MethodInfo)invoke[i]).Invoke( null, null );

			return true;
		}

And you can get the Source/Project for VS2003 of the compiler (most of it was straight from the core and could use some useless-method-deletion to leave only the needed parts):
http://www.nogard.net/Compiler.zip

[Phantom]

I think your going to go to alot of trouble for little to no gain.

[Atomic]

Not much trouble at all, basically just taking scriptcompiler and putting it out of the core
And I dont have anything better to do anyways

[Serp]

Originally Posted by Atomic

Not much trouble at all, basically just taking scriptcompiler and putting it out of the core
And I dont have anything better to do anyways

As long as you learn something it's a successful project! Good luck! :-)

[Alis]

Originally Posted by Phantom

I think your going to go to alot of trouble for little to no gain.

gee phantom your allways approaching such ideas and projects in -negative way as to remember to my disscusiion about Save system you said it wouldnt be good to modify the core damn if you dont modify the core who will ? the dev ? is all the work done by the dev ? i dont think so no one is superb exchanging ideas and methods makes all the people superb this why Runuo site is online so that people exchange their suggestions.

And you you also support maybe with everything but don allways start your posts with negative way dont act like a robot just say no or yes say something else will you im not flaming you but im telling my suggestion just to remember on the hack topic what ever.

[Phantom]

Originally Posted by Alis

gee phantom your allways approaching such ideas and projects in -negative way as to remember to my disscusiion about Save system you said it wouldnt be good to modify the core damn if you dont modify the core who will ? the dev ? is all the work done by the dev ? i dont think so no one is superb exchanging ideas and methods makes all the people superb this why Runuo site is online so that people exchange their suggestions.

And you you also support maybe with everything but don allways start your posts with negative way dont act like a robot just say no or yes say something else will you im not flaming you but im telling my suggestion just to remember on the hack topic what ever.

He asked for what we thought, I told him what I thought, nothing I said was negative.

Some advice, if you have to say your not attacking me, gues what you think there is a chance I will take it that way thus the reason it was said.

Guess what, you did attack me, and for what exactly? Because I don't agree with making this modification, the comment the author asked for?

So, what do you guys think about it?

I do not think anything will be gained from it, infact I feel RunUO would become slower considering its using untested code to load dlls

-Being able to use code defined in scripts in the core (for example, using a check in the item packet to see if the PlayerMobile has IsHallucinating true..)
-Being able to change stuff in the core easily (like accesslevels), recompiling with just a double click

The first one, can be done without any effort, and doesn't need a new core.

The second one, would require a small modification, to allow for the enum to be outside of the core. Then the same result will happen.

If you don't want everyones views on a particualar subject do not ask for it.

[ASayre]

(or just compile the core with all of the script fles except for one into an EXE, no modification to RunUO code required)

[Arahil]

i also thought about such a modification, and i think i will do it in the near future. but my idea went a little further, i thought about a "core" executable, that just compiles the scripts and calls the mainloop, which is also in the scripts, via reflection. i do know, that this is not really a clean way and may cause a lot of trouble, but i'm sure it will work if you use it correctly.
it's pretty annoying for me to have 2 different projects to work on with some changes, 2 different versions, 2 different svn-repositories to maintain etc. another reason for me was, that i do not really think the core and the scripts are divided in the best way, especially concerning the playermobile. every mobile carries some properties it does not need (like the netstate, for example), which wastes some memory. and since i don't want to give the mobile even more properties it does not need anyway and using an interface for playermobiles causes annoying casts (like IAccount) i will do this merge.

if i'm successful, i will post my solution on these forums.

[Atomic]

Originally Posted by Phantom

He asked for what we thought, I told him what I thought, nothing I said was negative.

Some advice, if you have to say your not attacking me, gues what you think there is a chance I will take it that way thus the reason it was said.

Guess what, you did attack me, and for what exactly? Because I don't agree with making this modification, the comment the author asked for?



I do not think anything will be gained from it, infact I feel RunUO would become slower considering its using untested code to load dlls

---There is no way at all that RunUO wwould become slower.. Actually it would be faster, but only on startup

The first one, can be done without any effort, and doesn't need a new core.

---If i'm going to change one of the packets, it obviously is a core mod..

The second one, would require a small modification, to allow for the enum to be outside of the core. Then the same result will happen.

---With the modification I'm planning you won't even need that, which is exactly the point

If you don't want everyones views on a particualar subject do not ask for it.

Commented on the quote^

(or just compile the core with all of the script fles except for one into an EXE, no modification to RunUO code required)

Sure, but that would take all the fun out of it :P

i also thought about such a modification, and i think i will do it in the near future. but my idea went a little further, i thought about a "core" executable, that just compiles the scripts and calls the mainloop, which is also in the scripts, via reflection. i do know, that this is not really a clean way and may cause a lot of trouble, but i'm sure it will work if you use it correctly.
it's pretty annoying for me to have 2 different projects to work on with some changes, 2 different versions, 2 different svn-repositories to maintain etc. another reason for me was, that i do not really think the core and the scripts are divided in the best way, especially concerning the playermobile. every mobile carries some properties it does not need (like the netstate, for example), which wastes some memory. and since i don't want to give the mobile even more properties it does not need anyway and using an interface for playermobiles causes annoying casts (like IAccount) i will do this merge.

if i'm successful, i will post my solution on these forums.

Nice, good to see someone thinks like me

[Ohms_Law]

Originally Posted by ASayre8

(or just compile the core with all of the script fles except for one into an EXE, no modification to RunUO code required)

Andre (or anyone else for that matter),
I think I know why (being that the 'core' wasn't released originally), but I'm curious as to any other thinking behind why this wasn't done to begin with? Well, not really why it wasn't done to begin with, but maybe why it wasn't done since the core was released?

[ASayre]

Originally Posted by Ohms_Law

Andre (or anyone else for that matter),
I think I know why (being that the 'core' wasn't released originally), but I'm curious as to any other thinking behind why this wasn't done to begin with? Well, not really why it wasn't done to begin with, but maybe why it wasn't done since the core was released?

Most people don't even know howto compile the core, and, the Core contains all the 'givens', things that would be standard between different people (assuming they don't change it themselves)

Fact of the matter is, 98% of the people don't need to recompile the core anyways.

[Ohms_Law]

Originally Posted by ASayre8

Most people don't even know howto compile the core, and, the Core contains all the 'givens', things that would be standard between different people (assuming they don't change it themselves)

Fact of the matter is, 98% of the people don't need to recompile the core anyways.

oh, you'll get no argument from me their. 90% of people shouldn't be recompiling their scripts either though.


The unfortunate side effect of that though is that most folks consider the core to be 'untouchable', event if they do know what their doing. It makes it rather difficult to contribute to the project as a whole in certain (albeit limited) cases.

That being said, it would be alot of work to change it now. Like I said at the beginning, I was really just curious anyway.

[Phantom]

Originally Posted by Ohms_Law

oh, you'll get no argument from me their. 90% of people shouldn't be recompiling their scripts either though.


The unfortunate side effect of that though is that most folks consider the core to be 'untouchable', event if they do know what their doing. It makes it rather difficult to contribute to the project as a whole in certain (albeit limited) cases.

That being said, it would be alot of work to change it now. Like I said at the beginning, I was really just curious anyway.

Its a matter of the fact, there is nothing any of us, can change thats really worth it.

Now if you change the core to support a custom client, and make basicly a new game, find its a great reason.

But making minor changes just because you can, shows you don't know a better way to do stuff, if of course there is another way.

[Bmzx007]

Originally Posted by Phantom

Its a matter of the fact, there is nothing any of us, can change thats really worth it.

Now if you change the core to support a custom client, and make basicly a new game, find its a great reason.

But making minor changes just because you can, shows you don't know a better way to do stuff, if of course there is another way.

Well for one, I disagree with the first line, there are things that can be changed in the core to make it worth it. Just because you dont think there is, doesnt mean there isnt.

And your last statement, Doesnt show they dont know a better way to do something, it shows they decided to put it in the core, rather than override it, Which in my opinion, is a better way of doing things.

If something in the core, was bugged (As an example purely) or something didnt function how you wanted it (Say, the Gender Packet reading as bool rather than byte for ML stuff) would you override and change it? or would you write directly into the core.

I'd change it in the core, because its cleaner, and more efficient. Im quite sick of your negative attitude towards core changes, The core was GPL'ed, and thats it. If people want to do it, they will, Everyone knows your against it, so you dont need to post in every small core modification post, and voice it again.

[Arahil]

Originally Posted by Phantom

Its a matter of the fact, there is nothing any of us, can change thats really worth it.

Now if you change the core to support a custom client, and make basicly a new game, find its a great reason.

But making minor changes just because you can, shows you don't know a better way to do stuff, if of course there is another way.

phantom, the fact that you do not know any reasons to change to core (or are not able to do it) does not mean that no one else does. i changed my core quite a lot, and if you really want to i can give you some examples of changes that are not even possible to do in the scripts. please stop fucking around in every single core mod thread - i think that prevents a lot of people from posting their stuff here and talk about pretty interesting things...
in this point you cannot even say you go with the devs - like this quote of zippy shows:

Why does everyone think it's somehow frowned upon to talk about the core.

I am daily disappointed by lack of activity in the Core Mods forums. Really, I am.

Just because a person with a large post count says it, doesn't make it true.

http://www.runuo.com/forum/showthrea...176#post416176

and before you troll around in the next core mod thread i just want to remind you that some factions code was also in the core... does that mean that these changes were not "really worth it" or does that show that "you don't know a better way to do stuff"?

[Atomic]

Phantom, please stay out of my posts.

[Marak]

i could have sworn i posted this before?!? go figure. neway:

Any luck with this yet? id love to get a copy of it just for when im working on new scripts i dont have to keep an eye on it(go for a coffee instead) so i can stop it from completly loading.

[Arahil]

well, as i said i will release my version here, too.
it's just a first try, so there might be bugs in it. i absolutely do not recommend it to use for somebody who is not experienced with using runuo and a custom core...

i went a step further than atomic did and wrote a program that precompiles both the scripts and the core, and start the runuo-server afterwards. i removed some of the mechanisms in scriptcompiler.cs, like directory checks and stuff, since i do not need them (actually i do not know if anyone does ). i used relative paths instead wherever i could.
i also removed compiling of *.vb scripts. don't use that, too, but should be no problem to insert for someone who knows the original scriptscompiler.cs.
since the server does not compile the code itself, i had to install a routine to load the compiled assemblies via filepath, which works fine, too. script verification and initialization are still in the server scripts - all the additional exe does is creating some assemblies (actually, just one ) and starts a given class.

starting the class works via reflection, you have to give the precompiler.exe the name of a class, in most cases "Core", as a parameter. the precompiler then loads the main-method out of this class if it exists - otherwise it shows an error pointing out what is wrong. of course the precompiler is passing on the other parameters given to it, like -debug or -service.

to use the precompiler you have to move the whole core directory in a subfolder of the scripts directory and change scriptcompiler.cs to the version i attached in this post.


well, i think that's all... but again, i do not recommend anyone to use this piece of code, especially since it is quite untested yet. seems to work fine, but who knows what bugs might come...

[Marak]

Thnx this will be usefull for when im testing

[Arahil]

i did some tests, and it seems to work pretty well
so if you want to, feel free to use it...