- Thread starter Dan
- Start date
There are 3 ways to go at it,
1. You readd the static method that was for removed for whatever reason
2. Readd the static method and let it call the new one
3. change the vitanex code yourself to use the new method
1. You readd the static method that was for removed for whatever reason
Code:
public static bool CheckAccessible(Item tool, Mobile m)
{
return (tool.IsChildOf(m) || tool.Parent == m);
}2. Readd the static method and let it call the new one
Code:
public static bool CheckAccessible(BaseTool tool, Mobile m)
{
int t = 0;
return tool.CheckAccessible(m, ref t); //untested but should be like that
}3. change the vitanex code yourself to use the new method
Starting to get very tired of these repo mods that don't take into account all the potential scripts that are already coded to use these methods.
Changing method names and arguments should always be in the format of overloads in the best interest of compatibility.
Not every craft system should use a BaseTool as the tool, that's creating even more restrictions.
Changing method names and arguments should always be in the format of overloads in the best interest of compatibility.
Not every craft system should use a BaseTool as the tool, that's creating even more restrictions.
In its current state, ServUO is only really usable by new shards starting out.
The publish that introduced the damageable items completely segregated many established shards due to the amount of edits it requires to update.
In the past few months, ServUO has taken a turn with the influx of contributions, which haven't really conformed to compatibility standards.
There was a time where VNc would be compatible for up to a year before it was broken by an edit, now it's every other week.
There needs to be some standards and thought put into backward compatibility when going forward...
The publish that introduced the damageable items completely segregated many established shards due to the amount of edits it requires to update.
In the past few months, ServUO has taken a turn with the influx of contributions, which haven't really conformed to compatibility standards.
There was a time where VNc would be compatible for up to a year before it was broken by an edit, now it's every other week.
There needs to be some standards and thought put into backward compatibility when going forward...
Kamras
Member
That is where i'm currently at, at some point drag and drop wasn't possible and the damageable item was the last straw for me keeping up with the edits. Now I just manually code in the new features i do want, which isn't ideal because its basically re creating the wheel every time but its what i deal with.. and not because i want to, it's because i've done too much work to repeat all the edits on a new distro download.
[doublepost=1487884706][/doublepost]what really cheesed me off is when the whole file structure was redone... that creates all kinds of annoyance for me .
[doublepost=1487884706][/doublepost]what really cheesed me off is when the whole file structure was redone... that creates all kinds of annoyance for me .
Crome969
Member
The restructure of Files, the dozen of core changes without backward compability also affected me a lot of times. You are (as always) correct on all your statements about. I personaly think whats required is a higher base flexibility, a higher rate of reviews and changes onto the code should be always designed to work with running systems. I guess iam not the only one that hates to pull on a daily or weekly base and pray to god not to rechange a few thousand files of code. But this is not a thing, servuo alone must work on, but also the developers of the individual shards.
I for myself started with a few simple steps :
1) Adding a custom function on serialize\deserialize that independent allow to store data (in my Case : CustomSerialize\Deserialize) those are virtual on Item.cs\Mobile.cs and getting called on load\save of world seperate.
2) Storing custom data into seperate files, making the core class partial and only inject 1 line calls on original file and do the handles on my custom file. On that way every bigger update can be merged and i only need to add a few lines (playermobile has 3 lines changed by that way to store dozen of new properties)
3) never store any non servuo related data via serialze\deserialize always use my custom stuff.
4) I not add files to servuo repo itself but design them independent or as module (vnc helps a lot) and store them seperate. I try to reduce any file modification to a minimum.
In case something changes i only need to handle it on main file, my custom edits will still working without changes. When i want to move a previous code from custom to serialize i can remove on custom side and add on origin pretty easy.
