Schmoozerd
Members-
Posts
1078 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Everything posted by Schmoozerd
-
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
nice, I will create an initial converter, to also see how the different db-projects look in this converted form. The core changes should be relatively simple, and I will look into them "soon" (except someone else was faster) -
Heroic dungeons of NR can be entered before level 80
Schmoozerd replied to a topic in OldBug reports
http://paste2.org/p/1969411 might fix it. But i am totally unfamiliar with this area of code. Please feedback test results -
[11941][Patch] Spells - Summon Bone Mages / Minions
Schmoozerd replied to Xfurry's topic in ... acceptedOld
With targeting from classic spells in [11941]. Thank you. -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
"(my approach sacrifices space for simplicity):" infact the basic conditions (has-aura) will be less in your version -- which is kind of a good thing, because this might be the place where we can keep things easier between the different projects. But you might require more "link-conditions" (with which I mean the conditions of type -1, -2) With this system, you need to check the numbers of your conditions, and then how they are used within the "link-conditions" -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
The converting tool for initial fill is now quite powerfull, even if it still won't give an optimal result. Version: http://paste2.org/p/1967856 I compared the different databases (zero-db, tbc-db, udb, ytdb). The results you can see below. So depending on order of processing, and how they are processed the size of the initial fill can become very small. On a large scale it will be impossible to use the udb or ytdb condtitions for tbc-db or zero-db, because some conditions will throw errors (like for non existing items) So it will become very difficult to create a merged version of the conditions, but there is no big disadvantage to at least built tbcdb's conditions table on the table of zero, and the ones for udb and ytdb on the on tbcdb. But - actually this is mostly up to the db-guys to decide how they want to approach this, and how they want to work with it. (For contributors the best clearly would be a conditions table shared between the projects! - but this is much more effort to maintain!) Up to you guys to decide how to proceed -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
Updated the helper tool for conversion. Seems to be fully working. http://paste2.org/p/1965468 A whole dump for all conditions (for both udb and ytdb) here: http://paste2.org/p/1965470 @Vladimir yes indeed, it can be expected that over time this table will be filled with bad data - but I don't expect this to happen very fast. But only if there will be a neat tool for optimized inserting.. Edit: Well, simple conditions are easy to insert, so there should be for most case no real requirement. But I think that it is well worth the additional effort when changing/ inserting new conditions because of more power and more flexibility. -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
pushed the stuff in a rebased version to my github repo: https://github.com/Schmoozerd/mangos/commits/condition_system Should be easy to ie add other tables, clean a bit stuff, etc For the initial fill I have already started to write a python script, see http://paste2.org/p/1964566 But I have never used python before, so this is not running yet, and only very basic. But the initial fill is not as complicated as the later check for already existing condition-lists. see: if you want to know if (A && B) || C is included in the conditions system, you must check for (A && B) || C or (B && A) || C or C || (A && B) or C || (B && A) rougly the number of required possible chains is m! (faculty of m, where m is the length of the conditions list) Even more complicated it gets if you want to insert a new conditions list, because you might want to check, if already parts of this list are inside the system (and optimize for this) -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
About Your Edit: No, you are right, but this would be relatively inefficient, because many conditions would be in `conditions` table multiple-times. The goal was to do it efficient, and this is the difficulty -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
ATM, conditions are stored in columns of the style (condtion-type, value-1, value-2) for *loot_template this is one such 3-column, for gossip_menu it two such 3-column, and for gossip_menu_option it is three such 3-column. They all will be replaced by one column named "condition_id" This new condition_id points to an condition-entry of the (new) `conditions` table. The conditions table has the format (condition-entry, condition-type, value-1, value-2, link-entry) And it is possible to link multiple lines of `conditions` together by using the link-entry (depending on sign AND or OR link) From now on I will write big letters (A, B, C) instead of (condition-type, value-1, value-2). then a logical line in conditions would be entry, A, link-entry. So for example, assume you had (1, A, 0) (2, B, 1) (3, C, -2) (4, D, 3) as entry in conditions. Then if gossip_menu_option.condition_id was 4, this menu would point to conditions 4, which evaluates as (D && C) || (B && A) Btw - if you want to do some work related to this patch (which would be very welcome). In the code I only added actual support for the gossip_menu_option table. You could add for other tables as well (should be relatively straight forward to do so) I can push the stuff with some logical commits to my repo over the day, so it should be easier to understand which part of what is required for what. Edit: https://github.com/Schmoozerd/mangos/commits/condition_system -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
Sure, but you might require a finite amount of them, whereas the number is determined by the input data -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
Yes - I need somebody to write a GUI tool for this system Atm I estime that the time for checking if a conditions-list is already in the conditions table, will be n^(m!), where n=lenght of conditions, and m=length of list. And this is nearly impossible to do manually for longer conditions-lists. Very complex matter, but most likely also interesting for ppl interested in computer science -
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
" The actual list of conditions and its links is treated in the form of a http://en.wikipedia.org/wiki/Disjunctive_normal_form " so your example 1=1 || 2=2 && 3=3 would be treated as (1=1) || (2=2 && 3=3) Edit: After some thinking, he use (adding new conditions) of this system for people is really difficult. A program interface (probably best GUI) would be really helpfull. I would help with the required algorithms to check if a "conditon-list" is already in the conditions table, and also with optimezed ways to insert a new "conditon-list" -
why do you say broken link?
-
[Discussion] Changes to db-scripts and condition system
Schmoozerd replied to Auntie Mangos's topic in OldCore modifications
And some more Updates: Condition system http://paste2.org/p/1963271 This system allows to add conditions to a `conditions` table. These conditions can link to each other. Negative link-entry is interpreted as "OR", positive link-entry is interpreted as "AND" The actual list of conditions and its links is treated in the form of a http://en.wikipedia.org/wiki/Disjunctive_normal_form Currently added support for gossip_menu_option - the rest is rather time consuming. Troublesome Good ideas for converting current conditions to the new condition system. If possible MySQL only solutions, but it might be that this is impossible. Edit: Might be an idea to create a small GUI tool for this system (display/ modify/ create conditions) for DB guys -
Little bump Fresh version: http://paste2.org/p/1963058 (need to add #include "GridNotifiers.h" #include "Cell.h" into ScriptMgr.cpp for non-pch compile, thx to neatelves for testing) Features: * Except outdated flag commands, all commands support the buddy concept * Unified and improved a lot of debug and error output * Engine moved to ScriptMgr.cpp, in Map only the code calling is still located Please test Especially, but not only the old-script to new system conversion!
-
yes, look at the at_login flags, description is in the wiki
-
yes sure, but there is no problem.
-
Repacks are not supported here. You can look at the guides and set up your own server locally (not too difficult), and with proper configuration it must be possible for you to play with your friend on it.
-
Sorry for closing, but SD2 problems should be discussed and asked about at SD2 forums. But to not waste space: The TBC branch (located at github/mangos-one/scriptdev2 ) should work alright, and SD2 does not support all bosses (yet). ICC is missing entirely
-
Just to clarify: I think that the core changes itself are ok (though ofc can have still issues). BUT I most likely (still) destroy some old scripts because of missing/ bad sql UPDATE statements. So I would appreciate feedback and serious review of actual changes that happen with the statements, and which commands have problems.
-
well, the problem is, that many GOs had bad dataz in the rotation fields before (however they were unused) a good solution was an UPDATE statement, that took the old angle and converted this to (proper) quaternion rotation. this statement can be found on github, in the comments related to one of the quaternion commit. (by zergtmn) However the big databases udb and ytdb have updated their values in large since quite some time, so in an updated database there shouldn't be problems remaining.
-
In [11935], thank you!
-
Agreed with stfx - as the spells are initialized with 0, there is no need for a default case, and we don't need an additional check, because we know that the code is correct In [11934]. Thank you!
-
In [11933], Thank you
-
In [11932], Thank you!
Contact Us
You can also email us at [email protected]
Privacy Policy | Terms & Conditions
This website is in no way associated with or endorsed by Blizzard Entertainment®