| Author |
Message |
| Tow dragon |
Posted: 2013-04-13, 23:19 Post subject: |
|
Well, I expected circular dependencies to be checked inside CModHandler::resolveDependencies because there it's both fast and simple. When for ( mods in input ) resolves no mods, then we have a cycle. But you don't have to do it this way.
The important thing is that CModHandler::hasCircularDependency seems to have no recursion termination conditions. Making it a proper DFS won't hurt. |
|
 |
| Ivan |
Posted: 2013-04-13, 22:39 Post subject: |
|
Good part is that right now we don't need to care much about load order - most of mod system will work just as well without it.
What can be affected by it is:
- order in which files are overridden by mods (if same file present in two mods)
- order in which patches* are applied to mods (only if patch affects same config entries)
And both of these situations are already a conflict between mods that must be solved by author(s)
* by patches I mean accessing namespace of another mod
| Quote: | | BTW, you seem to have forgotten to check if the dependency graph is actually acyclic. |
No I didn't. Check CModHandler::hasCircularDependency
Straightforward approach as well so this is not the fastest way but at least it simple.
I just don't want to spend too much extra time here to write faster algorithms properly - it is unlikely that this place can become a bottleneck in our loading code. |
|
 |
| Tow dragon |
Posted: 2013-04-13, 22:06 Post subject: |
|
Bellman-Ford is faster and produces different order. Your algorithm is fast enough anyway. And order... I don't know which one is better -- if there is such thing as better or worse order here.
BTW, you seem to have forgotten to check if the dependency graph is actually acyclic. But it's simple. |
|
 |
| Ivan |
Posted: 2013-04-13, 15:45 Post subject: |
|
| Quote: | | Which topological sort? |
CModHandler::resolveDependencies
It was present even before 0.92 and this discussion.
| Quote: | | And what does point (1) actually do? |
Right now initial list of mods used as input to topological sort is not ordered alphabetically - it uses order in which these mods were found during scan of Mods directory.
Along with my changes final algorithm should be like this:
| Code: | sort( input )
while (input is not empty)
resolved mods = output
for ( mods in input )
if ( all dependencies are in list of resolved )
add mod to output |
Do we need anything more complex than that? Results should be the same as with your algorithm. |
|
 |
| Tow dragon |
Posted: 2013-04-13, 14:59 Post subject: |
|
| Ivan wrote: | 4) mod load order will be determined strictly based on dependencies:
1. Sort all mods by name (to avoid hash map having any effect on this)
2. Use topological sort to load dependencies first |
Which topological sort? And what does point (1) actually do? Keep in mind I've already suggested a solution for this: http://forum.vcmi.eu/viewtopic.php?p=8810#8810 (the proper way to calculate sequence numbers is in edit). This is basically topological sort but with all the details specified. |
|
 |
| Ivan |
Posted: 2013-04-13, 12:24 Post subject: |
|
Trying to finish editing H3 objects via mods feature.
1) It seems that "full ID" must have different separator between mod name and object name, e.g. colon:
"modName:creature.someName"
Othervice it is not always clear whether first section is mod name or type of object.
2) Scope resolution (see page 14). I'll take metadata approach - JsonNode will have metadata field which will be used (in this case) to store name of source mod.
EDIT:
3) Original objects (for now - including wog) will be in namespace "core" to differentiate from objects local to mod
4) mod load order will be determined strictly based on dependencies:
1. Sort all mods by name (to avoid hash map having any effect on this)
2. Use topological sort to load dependencies first |
|
 |
| Macron1 |
Posted: 2013-04-12, 08:42 Post subject: |
|
| Warmonger wrote: | In H4 and H5 it is simply possible to have multiple types of creatures in wandering stack. It is displayed as the strongets creature on adventure map. In H5 it also has some additional banner to indicate there are more creatures.
And monsters can give artifacts on deafeat already, it's all possible in OH3. |
So will wait for this feature |
|
 |
| Warmonger |
Posted: 2013-04-11, 19:14 Post subject: |
|
In H4 and H5 it is simply possible to have multiple types of creatures in wandering stack. It is displayed as the strongets creature on adventure map. In H5 it also has some additional banner to indicate there are more creatures.
And monsters can give artifacts on deafeat already, it's all possible in OH3. |
|
 |
| Macron1 |
Posted: 2013-04-11, 18:09 Post subject: |
|
I got one idea.
In WOG there was script, so when you attack neutral monsters, some other creatures were on their side. It's very treacherous, that other creatures were not shown on adventure map (cause they were generated by script on time of battle).
My idea - on map gathered bands will display as some tent, right-clicking on it will bring down the list of creatures in it. So there could be neutral hero also.
When they are defeated, tent disappears, and hero may pass.
Also on defeat some artifact may be passed.
Creatures and artefacts may be random (from one fraction, generated on start-up). Or they also may be written in external mod. |
|
 |
| Tow dragon |
Posted: 2013-03-16, 14:55 Post subject: |
|
| Ivan wrote: | | I won't surprise if downloads of vcmi itself will require more bandwidth than mods. |
Actually updates could be distributed via P2P too. Anyway, P2P can be added at any time so we can just wait as long as Tow's server is enough. |
|
 |
| Ivan |
Posted: 2013-03-16, 14:42 Post subject: |
|
| Quote: | | What do you mean by lost after install? |
I'm talking about TES modding. By itself mod file may contain only a small (up to 512 bytes) description and no version information at all. This is how mod file header looks like: http://uesp.net/wiki/Tes5Mod:Mod_File_Format/TES4
Mod hosting sites provide much more information (large description, version, download URL, etc) but most of tools don't have access to it because it is not part of mod file.
So it is hard to say what's the problem here - modders who don't use versioning correctly or badly designed mod format. Second one certainly can be avoided in vcmi.
| Quote: | | I think 10 - 50 MB/month per at least casual player is reasonable guess |
I'd rather avoid such calculations until we get some real statistics. Certain amount of players will want to play good old Heroes 3 (with or without WoG) and won't be interested in mods. This is especially true for those who can't play original game (e.g. Android users).
I won't surprise if downloads of vcmi itself will require more bandwidth than mods. |
|
 |
| Tow dragon |
Posted: 2013-03-16, 13:57 Post subject: |
|
| Ivan wrote: | | Mod hosting sites usually handle versioning quite well but this information is lost after install. |
What do you mean by lost after install?
| Ivan wrote: | | P2P? Certainly an interesting feature but is it really worth it? With large number of users it would be great but othervice it may not be reliable - too slow or not functioning at all. |
Our server could be a P2P peer too, then I see no reason for it to be slower and it would function all the time. I'm sure a few VCMI enthusiast could seed the content significantly lowering server bandwidths (which is primary motivation for this feature). Look at our download statistics, then at Android version statistics, then estimate monthly bandwidth per player (I think 10 - 50 MB/month per at least casual player is reasonable guess). Then 10 GB per month is minimum in mid-term and may reach 1 TB per month should VCMI become popular. |
|
 |
| Ivan |
Posted: 2013-03-16, 12:59 Post subject: |
|
| Quote: | | Problems are many. For instance, did you wonder that mlox is using [SIZE BYTES] + name to identify mods? Yeah... TES has the same problem, of modders thinking that versions are optional stuff. |
Main problem here is not modders but Bethesda. From what I see they still don't have field "version" in their mod files (.esp). So versioning can be done only by renaming mod file each time (and break all mods that depend on it).
Mod hosting sites usually handle versioning quite well but this information is lost after install.
| Quote: | | If we had a server for mods (possibly distributed via p2p) this would reduce this problem. |
P2P? Certainly an interesting feature but is it really worth it? With large number of users it would be great but othervice it may not be reliable - too slow or not functioning at all. |
|
 |
| Tow dragon |
Posted: 2013-03-16, 12:23 Post subject: |
|
| Quote: | | Problems are many. For instance, did you wonder that mlox is using [SIZE BYTES] + name to identify mods? Yeah... TES has the same problem, of modders thinking that versions are optional stuff. You can detect something is different in the rules... but can't detect if it is newer (without storing the old ones at least ) |
I think a hash would be better for telling the difference actually. But the problem is real. If we had a server for mods (possibly distributed via p2p) this would reduce this problem. |
|
 |
| i30817 |
Posted: 2013-03-16, 00:06 Post subject: |
|
My idea for my 'hypothetical' IDE for baldur's gate trilogy (literally, since it would use the netbeans platform), was much the same. First sort by a deterministic order all mods that are in the mod database; database would include locations to the download of mods, the folder structure to use inside of them , shortcuts for the thread relating to the mod on the appropriate forums with a preprocessor replace. And some 'runtime code units' that would essentially use groovy before installing the mod (programming is sometimes needed by BGT - this project would essentially replace BGT, which is a bat file script that mucks around with a single defined order for installs).
The actual order rules and conflicts would be on a separate file like that mlox_base there and wouldn't imply any base order.
Then it would (hopefully), check for new versions download all that into a cache, check for the rules and rebuild the graph and install or reinstall (Weidu is neat for that, it allows 'rollback'), from the first change onwards.
Problems are many. For instance, did you wonder that mlox is using [SIZE BYTES] + name to identify mods? Yeah... TES has the same problem, of modders thinking that versions are optional stuff. You can detect something is different in the rules... but can't detect if it is newer (without storing the old ones at least )
If it ever gets to a functional stage however, it's likely to be much much faster than install on the bat file, for various boring reasons, relating to weidu invocation merging (the rules are checked _before_ creating the install list, so there aren't any 'if' dividing in two a perfectly good weidu invocation - weidu 'mods' are more like a collection of 'submods' that can often be installed separately or not installed) |
|
 |