Unification

[WaterKnight]

Hello there.

I will not be actively participating in wc3 mapmaking in the near feature but would still like to give my 2 cents and addressing those who are upholding the modding scene

The topic is about wc3 mapmaking and modding in general. We see that there are slowly more and more technologies popping up to solve a range of wc3 related issues and I got the expression that we are losing the overview a bit and stuff is outdated or broken. Often enough, one invests a lot of time in his/her tool, research or whatever it is but cannot properly expose the achievements or it gets forgotten in time because of a lack of visibility or he/she does not have the network of peers that supports the matter.

For example, I got wind about Ralle's WTG discoverings and usages, DrSuperGood's BLP achievements or the advancements of WEX that run in parallel to WurstWE and there are lots of tools in the Editing Tools section or on the download page, many of which are ancient. The wc3 file format specs, which should be the foundation for the development of tools, are outdated respectively incomplete or scattered and could be extended by comments on how to use them.

Thus I would like to preach communication, people talking to each other. This is the scene for having fun creating maps or modding the game, so I see little point in privacy or company secrets -> no problem with open source. You only have to enforce a minimal validity check that people indeed get what they sign up for. Luckily, the wc3 communities are already very centralized. As far as I know, besides russians and asians, most of the wc3 dev people settled on Hive. It holds organizational power. So employing Hive as a Unimatrix is not farfetched and so I would like to suggest that Hive sets up some kind of mindmap or ontology that makes it easy to identify existing (and upcoming) solutions, both of information on the Hive and outside and hands a signpost to all developers in order to raise awareness of each other (or at least update the sticky).

Instead of having everyone work on their own, creating solutions from scratch and writing the same half-complete algorithms over and over again, there should be middleware approaches and clear referencing of used libraries. Use some version control and collaboration system like Git, add dependencies. I am not saying there should only be one standard for everything, that is not realistic anyway and would impede dynamics but it would expose everyone and see their work in relation to others, thereby thriving interaction.

Please contribute your own opinions, suggestions and how you see the streamlining of tooling.

 

[Cokemonkey11]

In general I agree. One way that other orgs address this is by having someone curate not only the state of the union (what's broken and outdated, what's new and looking for more users), but also curate and communicate the goals of some of the core engineers, in the context of direction.

Rust does a really good job of this with impl periods and yearly roadmaps that aim to "promise" things like "it will be easy to get started doing X by end of 2017".

@WaterKnight, how do you feel about this?

Luckily, many of us are being carried by the tireless efforts of a few individuals who are doing the work of many, but fragmentation and misinformation are definitely issues that we need to be aware of and actively prevent.

 

[GhostWolf]

This is not always possible. For example, you can't directly use my code outside of a web environment.

Regardless, we wrote some updated (relatively speaking) specs in the programming forum.
Like I said previously, if you have specs to add because they are clearer / updated, you are fully encouraged to do so.

I agree that adding notes in some form or another about how to use the data is a very nice addition.
For my posts, I only did it to M3, but always thought about adding it to MDX.

At the same time, I am not too sure what code and programs you're talking about.

 

[WaterKnight]

@Cokemonkey11: Yeah, some foreshadowing would be nice, too. It could foster collaboration, understanding and one could bring up points "there is already a solution for that, what is the added value", "could you need help?", "lets build an interface", "ETA?", "If you do this, please include feature XYZ". Some for example want to retreat from the WE completely, maybe only for painting the terrain, others are trying to modify the WE, adding functionality via plugins or write their own hacks.

This is not always possible. For example, you can't directly use my code outside of a web environment.

That's fine. It only needs to be marked as that. Of course this raises the whole language issue like Barade has written C/C++ libraries, I did Java. It's improbable for people to agree on one language or platform in your case but the concepts are often similar, so we can learn from one another or even talk about interfaces.

Regardless, we wrote some updated (relatively speaking) specs in the programming forum.

I think that is a nice beginning, as a forum post, everyone can still make comments and the first post receives updates or maybe a Wiki. But yeah, I meant to summon all Wc3 formats in one place in an elaborated fashion. First off, the link I posted above is a bit buried in the WEZ sticky, I bet few people notice it. Secondly, since this is the Warcraft Editing Tools forum and the Programming forum is described as "Here you can talk freely about programming languages outside of the Blizzard universe. Talk about languages, ask for help or just show off. This is the right place for you." I would have not expected to see specific Warcraft III information therein. Well I know some formats might not be strictly restricted to Wc3 but Wc3 is the core topic of this web page and it has enough of its own quirks that deserve special reflection. The formats are one of the fixed (and well definable) groundings for the development of libraries and applications, so to me it seems reasonable to grant them spotlight and explain their uses. To name an extreme case, do you know the syntax for .FDF files or what they allow for? It is not really only about .fdf vs .slk vs .j vs ... either, more about the specific paths Wc3 uses. I guess lots of people do not know that the Units\UnitAbilities.slk causes crashes with a specific attribute non-existing which the game tries to access or that the same happens when the Burrow Detection ability is missing from Units\AbilityData.slk or something like that. Remembering, there have always been a few threads that got frequently consulted because they had been some kind of knowledge base like the Ability Guide from W3C but you had to know them beforehand and select them. As a forum, of course most of the posts here are daily assistance, conversation, marketplace etc. My idea is to condense the acquired knowledge in designated places for reference. Then maybe there is a hierarchy, you click on the BLP tab and see there is a number of tools that somehow relate to BLP (in the context of Wc3) and these pages are always editable. Yet I think there must still be some community commute to draw more people in and relevance rule, so you do not see the ancient or most-broken stuff first. We know this from stickies anyways: "Complete List of Modding Tools: Last edited by a moderator: Jul 21, 2013". I doubt that the site has the manpower to relay everything to moderators and it would be more vivid and immersive if everyone could somehow contribute a bit.

Actually, this reminds me a lot of the Knowledge-based systems I heard about in my studies. These always required particular knowledge engineering but I am not referring to an automatic system here, merely a human-readable collection with maybe some kind of categorization, just so the reader sees the greater picture.

At the same time, I am not too sure what code and programs you're talking about.

Anything that is in relation to Wc3.

 

[GhostWolf]

I doubt you could condense all of the community's knowledge in any nice readable format.
There is way too much information spread over way too many sites and people.

It seems to me like nowadays there are about 10 people working on different tools, and they are all willing to share their knowledge whenever asked to.

At the same time, many things are unknown, due to people never needing them. For instance, not much is known about maps, due to no one ever doing much with them, which is now making my effort x1000, but what are you going to do about it? the knowledge just doesn't exist.
For example, did you know that the internal one-letter MPQs in the game MPQs contain per-tileset textures that the game overrides at map load?

I am still unsure about what actual actions you mean to make though. Do you mean opening a wiki about everything Warcraft modding? A github repository with the code of everyone? deprecating old programs? (albeit not much changed since most of them were made)

 

[WaterKnight]

I doubt you could condense all of the community's knowledge in any nice readable format.
There is way too much information spread over way too many sites and people.

At least the main information. And I do think those 10 people could actually recite a lot.

For instance, not much is known about maps, due to no one ever doing much with them, which is now making my effort x1000, but what are you going to do about it? the knowledge just doesn't exist.

What are you referring to? But I think there is also a range of trivia that has not been written down or only found its place in specific help threads. Actually, there were some occasions where I thought in hindsight I should have written it down because then I stumbled about the same problem later again, wasting time and nerves. Just casting it in code instantly is not implicitly commemorative because it's mixed in with a lot of other things, tends to get refactored, someone else may not know the language etc.

For example, did you know that the internal one-letter MPQs in the game MPQs contain per-tileset textures that the game overrides at map load?

Yes, the Beastmaster summons are most prominent for that.

I am still unsure about what actual actions you mean to make though. Do you mean opening a wiki about everything Warcraft modding? A github repository with the code of everyone? deprecating old programs? (albeit not much changed since most of them were made)

The actions I have only speculated about I mostly think of it as a Wiki but I guess that would not gain much attention from the normal community as it would be apart from the daily routines. On inwarcraft.de, we did start a Wiki back then but few people participated and it was mostly shallow and well, in german. A shared GitHub group would be an idea, actually we already have one for inwc. You can grant people access to collaborate. But yeah, not necessarily binding them in the same group yet keeping track of all the repositories would be nice The old programs were compiled and not open source for the most part. There should be more emphasis on expandability by now. There are also projects that are open-end like my wc3libs there that are too vast or JMPQ that was initially written by Crigges but got a lot of refinement by Frotty recently. I had been using your mdx specs at some point before but for a very specialized task iirc, I am not sure if you were also the one that wrote a couple of Java libs for it? That would be easier to know with such a Wiki.

Old programs should only be deprecated when you have an exact replacement for it which of course would be easier with more middleware and information available. Speaking of which, I had dug into writing objMod to slk algorithms some months ago. Those were not enough yet to replace ObjectMerger but part of it and a fair start. I am content that the JNGP project finally continued as WEX, too.

 

[GhostWolf]

@Barade has a big project in Java as far as I remember.

All of my relevant code is in JavaScript.

I actually just figured the MPQs with the help of a user yesterday, so I guess that's an example of knowledge that is missing.
As far as what I am referring to...basically doing anything with the data.
It's not terribly hard to write updated specs. It's a lot harder to figure how the data you are reading is used, and this part of maps specifically is hardly known, because who ever did something with maps?

It sounds to me like you mostly want a big thread that links to many other threads / posts that link to other threads / posts, etrc., and will in the end encompass both code and data.

/edit
To be fair, people did lots of things with maps, but only with specific parts of them, e.g. object data.

 

[WaterKnight]

Barade did C/C++: Warcraft III Library

So you mean w3m/w3x, which consists of lot of other files as they are mpq archives. Yeah well, at some point we also got the idea of a map validator, i.e. it checks if the map contains all the necessary information non-faulty for wc3 to be able to read it but I admit, that is a bit complex and fails on semantics. Still don't know what you mean exactly, the header and optional footer are described at W3M and W3X Files Format. The mpq format maybe at zezula, although Wc3 maps use some special type of it. The different file formats are laid out mostly but should receive update/comments as discussed.

 

[GhostWolf]

A lot of the data is there. A lot of it is unknown. How to actually use the data? zero.
Then again, I am focusing on rendering a map, for obvious reasons, and no one ever tried doing that, so it makes sense basically everything I try to do is unknown and based on my guesses.

Anyway, it really does sound like all you are asking for is a thread linking other resources

 

[Cokemonkey11]

@GhostWolf

> This is not always possible. For example, you can't directly use my code outside of a web environment.

In general nothing is always possible, except in mathematics, but I don't think that's interesting.

If you're offering a devil's advocate, it would be good to clarify. Are you saying you don't agree that we're lacking in any of the following?

* curation of wc3 architectural knowledge
* sharing code and interfaces
* sharing design goals and tooling ideas

> if you have specs to add because they are clearer / updated, you are fully encouraged to do so

I don't think we have the capabilities to do that, apart from writing forum posts. They don't get enough exposure, except from the most dedicated forum users. Personally, I don't have time to read here every day.


@WaterKnight

> Actually, this reminds me a lot of the Knowledge-based systems I heard about in my studies. These always required particular knowledge engineering but I am not referring to an automatic system here, merely a human-readable collection with maybe some kind of categorization, just so the reader sees the greater picture.

I would tend to agree that forum posts aren't really suitable for the long term curation we need. I think a thw wiki would be very valuable, personally.


@GhostWolf

> I doubt you could condense all of the community's knowledge in any nice readable format.

That's why having one curator (which forum posts encourage) is inherently bad. If the wc3 weird ability guide were on a thw wiki, it would certainly be in a better state than it is now.

> There is way too much information spread over way too many sites and people.

Isn't that in general the problem space that encyclopediae try to solve?

> It seems to me like nowadays there are about 10 people working on different tools, and they are all willing to share their knowledge whenever asked to.

On THW*. But lots of people do stuff out of that scope. For example, do you know what @Frotty or @Ruke have worked on in the last 12 months?

> At the same time, many things are unknown, due to people never needing them. For instance, not much is known about maps, due to no one ever doing much with them, which is now making my effort x1000, but what are you going to do about it? the knowledge just doesn't exist.

Yes, and there can't be an expectation either that [you] *must* summarize and curate the content you derive from your learnings - but we can at least do better than forum posts.

> I am still unsure about what actual actions you mean to make though.

Because this is meant to be an open-ended discussion, and there are a few orthogonal problems that need addressing.

FWIW I do think that one action ought to be "open a wiki".

> Do you mean opening a wiki about everything Warcraft modding?

I would say yes.

> A github repository with the code of everyone?

Certainly we've done work in this area, and indeed using git is something every tool developer should be doing, but I don't think this is necessarily always appropriate. The jass encyclopedia that @LeP maintains, for example, is in github, but it's quite complete. If starting from scratch, a wiki would be more collaborative.

> deprecating old programs? (albeit not much changed since most of them were made)

Refer to WK's post, but in general this should be an eventual goal for lots of applications.

> It sounds to me like you mostly want a big thread that links to many other threads / posts that link to other threads / posts, etrc., and will in the end encompass both code and data.

Absolutely not - signpost threads inherently rot (then who updates them?), and there are problems with the actual guides being pointed to.

> Anyway, it really does sound like all you are asking for is a thread linking other resources

It sounds like you're trying to simplify the problem because you don't want to curate data, but I think part of this goal has to explicitly be that there isn't obligation to do curating.

That part will come naturally

 

[GhostWolf]

I don't agree with the idea that people aren't able to read for instance specs from a thread, but will be able to read them in a wiki page.
Overall, every time something becomes external, it wanes and dies over time.
That being said, I have nothing against contributing to such a wiki.

Github would probably not fit for any non-developer information.

 

[Frotty]

@GhostWolf your bluntness and may I call it ignorance is sort of a sad display. If after all of water's and coke's explanation you think we want a "big thread" - which we just elbaroated on why we don't, what can I even say?

> Then again, I am focusing on rendering a map, for obvious reasons, and no one ever tried doing that

I know at least 3 persons, including me, who have looked into that. Oger even started a custom editor based on jmonkey and stuff. Guess you didn't know this. Oh guess why?
Because Hive sucks at providing this information to users(espeically high lvl devs) right now, which you just confirmed, and we want this to change.

 

[GhostWolf]

I don't know who's "we", but that in addition to personal attacks won't exactly make anything better.

It's genuinely good to know about maps, got any links to share?

 

[Cokemonkey11]

@GhostWolf

Sharing links related to your personal interest in this thread is the antithesis of the topic under discussion

 

[GhostWolf]

Not sharing information really seems like the correct solution to the lack of information sharing, just because you think this method of information sharing is not ideal...?

 

[LordDz]

We already have a wiki about the Hiveworkshop, just expand upon it?
Maps

 

[Dr Super Good]

The mpq format maybe at zezula, although Wc3 maps use some special type of it.

The problem is a lot of file format specifications are quite cryptic. I remember having to combine 3 different MPQ file format specifications before I was finally able to read any data. They often miss out a lot of potential error cases and how they should be correctly handled.

The main problem with file format specifications is writing them in the first place. I could sprout the intricacies of the BLP format and the end result would be nothing but a massive series of paragraphs that becomes extremely cryptic to read, so much so that everyone who uses it ends up having to ask me personally what any of it means. This kind of happened already...

 

[Cokemonkey11]

@GhostWolf

> Not sharing information really seems like the correct solution to the lack of information sharing, just because you think this method of information sharing is not ideal...?

As discussed, instead of polluting this thread with unrelated content, may I suggest directly messaging someone who knows about the subject you're after? @Frotty is probably your best bet.

Yes, I agree we need to share information more effectively. That's what this thread is about.

@LordDz

> We already have a wiki about the Hiveworkshop, just expand upon it?

I wasn't aware of this wiki, but it looks better than I expected. I think we'll have trouble taking a wikia seriously as the go-to source of information though.

* loads of advertisements
* no story for getting backups of content
* why is this a "hive workshop" wiki? What we really want is a wc3 modding wiki.

Very good suggestion though.

@Dr Super Good

> The problem is a lot of file format specifications are quite cryptic

Yes, that is a problem. Wouldn't a single *editable* specification source have been better than three different ones, none of which are complete? This same issue applies all over.

--

I've created wc3modding.reddit.com as a way of hopefully getting many eyes on projects in a community-curated fashion. There's also a wiki, although I'm not sure how well reddit wiki works. PM me if you're interested in being a moderator or wiki contributor.

 

[PurgeandFire]

I'd be a fan of a github group. The wikia link that LordDz posted isn't official, so I'd be a bit hesitant towards using it.

Someone (@LeP ?) set up a sql db a while back to get community documentation on natives. Not sure if it gained traction or not, but I loved the idea. Same could be done here but for specs, projects, etc.

 

[LeP]

Yes i created the jass.db to have one place to document all the natives. Atleast for this type of documentation i'm not a fan of wikis since you normally can't programatically work with them. jass.db is just a sqlite file.
I know that you (@PurgeandFire ) did a lot of work on thehelper wiki from which i took quite some.

@Cokemonkey11 added some issues to it but otherwise i did most of the work on it, even if it was just copying from others.

Maybe a wiki inside a git would help. This way it would be way harder to lose stuff which happend to often in the last years (another reason i started jass.db).


I implemented the mpq format a while ago and had/have a good grasp on it. Then @Crigges and @Frotty came along with their needs for wurst so i could help them a bit with it. I bring this up because the reason i could help them was because we shared the same irc-channel. I would like to have a chatroom for the wc3 mapping community but here is where i will lose most of you: this chat channel cannot be a closed one. Not the hive chat. Not discord. Not slack. If these cease to exist, we would have to reorganize and find a new way to communicate. With IRC, XMPP or Matrix, if the server goes away, we could simply switch to another one without changing anything else (still use the same client, the same accounts, etc.).



I guess with the technical specs of the wc3 formats we have the same problem as everybody else. What i find helpful is to have a spec and one or more (better) implementations in different languages. This way there is more of a chance for someone to understand it.

 

[Dr Super Good]

I guess with the technical specs of the wc3 formats we have the same problem as everybody else. What i find helpful is to have a spec and one or more (better) implementations in different languages. This way there is more of a chance for someone to understand it.

In the case of MPQ I ended up having to reverse engineer/port from the underlying library of MPQEdit.

For MPQ this is fine enough already. The problem is with formats like BLP where the specification and all known non-official implementations were wrong.

 

[Lizreu]

Github would probably not fit for any non-developer information.

But we are talking precisely about developer information.

In this regard, GitHub as an aggregate of information would be an excellent option - preferably with a big, obvious button somewhere on Hive itself, not just a sticky in a forum. Maybe even a whole page on Hive linking to GitHub and other development resources?

 

[GhostWolf]

So, beside calling people names, did anyone whatsoever do anything whatsoever, or was it just a thread to complain?

 

[LeP]

So, beside calling people names, did anyone whatsoever do anything whatsoever, or was it just a thread to complain?

jass.db is slowly but steadily growing. although more contributers are always welcome. need someone to document the SyncStored*-natives.

 

[Ralle]

I think everyone is just sharing their experiences. I don't see much name calling.

I propose setting up a wiki and have us all collaborate on making up to date specifications of file formats in particular. It can be used for lots of other interesting things too, but to solve our issue of collaborating on the same text a Wiki is very nice.

I see a few software options:

• MediaWiki - Used everywhere and most commonly known for Wikipedia. It would be a separate site at e.g. wiki.hiveworkshop.com requiring a separate login, completely separate from the forum. I kinda find that to be clean although the extra login is sort of a nuisance. However, very few people would need a login anyway. It would of course be linked prominently in the top of the site to make sure people don't miss it.
• VaultWiki - A XenForo addon that integrates nicely with the forum, however not as popular, probably maintained by one guy. I am tempted to call it sort of a gamble long term to depend on it.

I vote for MediaWiki and those of us needing access would need to register for that.

 

[LeP]

I propose setting up a wiki and have us all collaborate on making up to date specifications of file formats in particular. It can be used for lots of other interesting things too, but to solve our issue of collaborating on the same text a Wiki is very nice.

I see a few software options:

• MediaWiki - Used everywhere and most commonly known for Wikipedia. It would be a separate site at e.g. wiki.hiveworkshop.com requiring a separate login, completely separate from the forum. I kinda find that to be clean although the extra login is sort of a nuisance. However, very few people would need a login anyway. It would of course be linked prominently in the top of the site to make sure people don't miss it.
• VaultWiki - A XenForo addon that integrates nicely with the forum, however not as popular, probably maintained by one guy. I am tempted to call it sort of a gamble long term to depend on it.

I vote for MediaWiki and those of us needing access would need to register for that.

I don't think that technology is holding us back. thehelper also had a wiki and mostly @PurgeandFire commited stuff to it.

What would push jass.db a bit would be public webinterface which people could link against. I wrote a simple sinatra script, but it's so small you could re-implement it in php in a matter of minutes.
If you want you could host it on the hive.[/URL]

 

[Cokemonkey11]

Afaik jass.db is the most complete source of info for jass natives, but this is insufficient [at present] for wc3 ability documentation (for which I know of at least 3 useful resources), and I *think* it's missing some stuff that can be found in The Hive Workshop Wiki

So a few thoughts:

* Is there a healthy way to expand jass.db to include ability info?
* Given that PurgeandFire was almost the sole contributor to thehelper wiki, is that a sign that a wiki is too heavyweight for a system mostly contributed to by a few people? (OTOH: how many contributors does the wikia have?)
* If we agree github is the right source for this content, still would be great to have backing from @Ralle to integrate with hive proper, and still need some code to do that (which could very well be done by someone else)

IMO github is the right tool for the job and can be expanded to include object data. My second choice would be to investigate something lighter weight than mediawiki.

 

[eejin]

I am currently working a lot with GhostWolf on map rendering and loading logistics and think that a MediaWiki as Ralle mentioned would be very nice. We've got some information that's just waiting to be noted down

 

[IcemanBo]

Clean discussion about .w3e was created here.

 

[GhostWolf]

...yeah, this is where I leave. Nice discussion. Just try to be a tiny bet less needlessly authoritarian.

 

[IcemanBo]

Why is it a problem? You think I do this to show authority?

 

[Dr Super Good]

I do not think it was necessary. Although it had diverted off topic it was still keeping the idea and concept alive in peoples minds with every bump, instead of no one posting in it for months and eventually the topic dying. It also was not that off topic as it was still talking about WC3 file format specifications, and not the StarCraft II editor or driving cars.

Once again I raise that the main issue is writing a clear, concise and maintainable specification reference for the file formats. Nearly all of them I have seen are confusing, inaccurate, owned by 1 person or omit critical information that developers end up having to reverse engineer themselves for each implementation. My BLP specification findings a year ago emphasise this as for over a decade people made all manner of buggy BLP1 decoders by referencing wrong specifications, and even this day people are still making wrong implementations due to these bad references still existing. Maybe individual developers spotted the problems and fixed them locally, but the underlying references were still wrong so the next developer made the same mistakes.

 

[TheLordOfChaos201]

you guys have enough combined knowledge to just make a warcraft error checker

looking through the jass code and providing solutions just like NetBeans does

 

[IcemanBo]

I am currently working a lot with GhostWolf on map rendering and loading logistics and think that a MediaWiki as Ralle mentioned would be very nice. We've got some information that's just waiting to be noted down

From there, the latter posts were deeply specific about technical aspects for one topic. I honestly don't understand why seperating feels like an attack towards anyone. It's just that we can focus on the terrain details there, as some good discussion was initiated, and on the main topic here, about structerizing and control such information. Noone thought of stopping the discussion in general, or something alike.

 

[Retera]

The other night I was talking to Hayate about the potential for him to make Wacraft 3 models on a Mac, and was able to throw together a very basic program with an MPQ browser, texture viewer, and MDX model viewer that had a very similar feel to using Magos's War3 Model Editor for browsing and extracting files, except that it took me maybe one or two hours to write it because I already had Java libraries I had written that could just pull in oger-lord's MDX parser, DrSuperGood's MPQ reader, and oger-lord's BLP to Java BufferedImage converter, as well as UI components like an MPQ browser and LWJGL static MDX/MDL renderer that I had already written (didn't render animations, though). Seeing that this only took an hour or two, as I get closer to a singularity of tools in that regard, it would be nice to reach a point where rewriting all of Magos could take just a few hours based on pluggable UI components and libraries. Unification is a very good idea.

 

[Dr Super Good]

and oger-lord's BLP

Use my BLP rather. My BLP ImageIO plugin is the most and only accurate BLP0/1 for Java as far as I am aware. All others made before then were based on a wrong BLP1 format specification so will not load some textures correctly that Warcraft III will and will load others that Warcraft III cannot without throwing sensible warnings. That said if it was made/updated after mine then its probably fine as maybe the inaccuracies were corrected.

 

[Retera]

Duly noted. I will investigate that.
On that note, I need to provide my MDX/MDL parser code in a presentation that isn't garbage, right now it's integrated into my JWC3 GitHub repo without any handy provided build scripts or anything, amidst a vast amount of unrelated buggy code.
It's mostly my old high school MDL code, which I believe is a near-perfect MDL read/write system, although the actual code is very ugly and badly written. And then oger-lord's MDX parser, with a few edits that I made from time to time, which after loading the MDX translates back to my high school MDL object model because all of my utilities were built to edit that.
So, the code is pretty ridiculous but the spec is decently accurate. There are some camera chunk loading issues with oger-lord's MDX parser, even in my version, though. Has he updated?

 

[GhostWolf]

Didn't we talk about the missing animation tags for cameras a looooong time ago and I gave you a fix? If it's on github, I could make a pull request.

What do you mean by your code working with MDL? you need to read the data into whatever run-time structures, why does it matter to the rest of the code how the data was loaded, or how it's going to be saved?

 

[Retera]

It's a possibility about the cameras, it's been a while. I will sit and check it out later tonight, right now I'm playing in the snow with family for holidays.

BlinkBoy closed the original thread for the matrix eater software, saying basically that if I wanted it to be professional I should rewrite the MDL parser in JFlex. I could do that, but you are correct -- for me, I have to ask myself, why does it matter how it's loaded? If it isn't broken, why fix it? So I would much sooner fix the MDX code.

 

[Frotty]

If you want ppl to use your resources a repo cleanup would still be the most useful IMHO. As for matrixeater usage, I don't see why mdl parser implementation would be a matter. Lol.

How many times has DSG now said that his blp lib is the only good one and all are bad, yet we all use them without problems? Someone should keep a history.

 

[Retera]

When an option exists that is 100% accurate, I do prefer it over one that is 90% accurate. Maybe the BLP lib I was using is half decent, but I know for a fact I have gone back to YobGul's File Converter instead of the MDLXConverter tool for converting a model from MDL to MDX because the fan made MDL->MDX converter is, in obscure cases, flawed and broken -- but that old YobGul one that barely runs outside of MS DOS uses blizzard's game.dll and does an accurate conversion between formats. If we had perfectly accurate MDL / MDX code, I would never be going back to use that program. It's the same with BLP, there's a definite benefit to a better parser.

Edit: at one point I tried running my MDX->MDL->MDX Java code on every model in wc3, and BLP->TGA->BLP on every texture, so that I could run compression mechanisms on them to build a version of the game installation that was only 100 MB. It was perhaps a somewhat meaningless project, as many argued 1 GB is still a tiny game installation, but I got it to work nonetheless. However, I couldn't tell you how many obscure corner cases caused crashes and failures in that compression process. It became very important very fast how much I understood BLP mipmaps, which I really only barely understood, and in many cases I ended up just telling my compressor scripts to ignore certain game files that I knew would either crash my Java converters, or simply become corrupted.

If DSG has actually created BLP code that could be used on every texture in the game, it is definitely an accomplishment

 

[WaterKnight]

My current idea is to have a Wiki where every article is multiply taggable, then make a main naviation via a tag cloud (which would probably include relevancy). Else we would require a rough hierarchy, maybe both. Curating of course is work, should probably start out with just uploading about everything in existence and categorizing it as said to get a basic overview and map to proceed from. A nice to have would also be a blog about recent activity as Cokemonkey11 hinted at on the first page.

 

[GhostWolf]

Let's go then.