The Spells section needs work! Here are my ideas.

[Antares]

Hello,

the old topic again. In this thread, I want to give my suggestions on how several sections on hive, not just the Spell section, should be improved, and my reasons for why I think these changes are necessary.

But first:




Why you bully Lua?


Anyway, here is the tl;dr of my suggestions:

• Deprecate the Code forum and make it into the Code Archive.
• Split the Spells section into the Systems and Spells sections.
• Make the Code Archive a subsection of the Systems section.
• Increase the scope of the Spells section and rename it to something like Concepts.

Why I think the Code Forum should be deprecated

Recently, I was looking for a system to interpolate mouse movement. The natives only fire every .1 seconds and if you move a special effect based on the mouse, it looks really choppy. So, I'm looking on hive to see if someone has already done something similar. I have to search through both the Code and the Spells sections. The differentiation between the two sections isn't really enforced and any resource could be in either.

I only find this resource for anything mouse-related. It has no test map and only a minimal description, so I have to look through the code to find out if it's doing what I'm looking for.

This is the second problem with the Code forum. There is no requirement to upload a test map, while in the Spells section there is. Often, figuring out what a resource does or how to make it work is quite frustrating. The forum reads more like a chat room between the high-skill coders on hive, and if you don't know about the "rotate a doodad three times counter-clockwise to get access to the Warcraft III internal C++ code"-trick, tough luck.

So, because I didn't find anything, I decide to write it myself. Now that I have written it, I consider uploading it to hive. It probably fits more in the Code than the Spells section, but I'm going to make a GUI, a vJASS, and a Lua version, and I would have to upload three different resources to the Code section. In addition, I'm going to provide a test map anyway, because every resource should have one, so despite it fitting more with the Code forum, I'm probably going to upload it to Spells.

With that said, there's not really any point in uploading anything to the Code forum. However, the forum is still valuable to have as a repository for all those old code resources, which were specifically written to solve problems with the individual languages you can use in Warcraft III.

But most of those problems have been solved by now. Therefore, I think the Code forum should be turned into an archive. In order to make the resources easier to find, the Code Archive should be a subsection of the new Systems section. Everyone who has uploaded in the Code forum and thinks their resource makes more sense in its parent, can reupload it there, pm a moderator, who can then approve it immediately. I don't know if you can get the search function to search in both sections simultaneously; that would be awesome.

Why the Spells section should be split

The easiest solution to the Spells section problem would be to rename it to Spells & Systems. Having a Damage Engine or a Hero Selection System in a section called Spells is really indefensible and the only argument against renaming it I could find was "it's always been that way." I don't think anyone who is only semi-familiar with hive would think to look for those systems in that section.

But I don't think a simple name change goes far enough. I think the spells that, for example, @Daffa is uploading, or the systems that I'm uploading, have very different audiences. As mentioned earlier, systems have much more overlap with code than with spells. Splitting the section would also give the opportunity to expand the scope of the Spells section.

Expanding the Spells section

Ok, I'm not the target audience for Spell resources, so this is something that @Daffa or @KitsuneTailsPrower might have better insight on, but here are my thoughts anyway.

If I wanna create a new hero/unit etc. and I'm looking for ideas, there are a lot of different things I might be looking for. I might search the models section for a cool model or I might see a spell in the Spell section that I really like. Maybe I find some voice lines (AI generated?) that I really like and try to make a hero that uses those.

I don't really see why there is a section only dedicated to spells. I could see a section where I can just browse different concepts that I can use in my map or which I can get inspiration from. And they could be anything. Just a spell, a hero without spells, a hero with spells, a model for a Pirate Uther along with AI generated voice lines etc.

This new "Concepts" section could then be merged with the sounds section. Sounds is another one of those "I didn't even know it existed" sections. I could reupload the Thisalee Crow as a full hero concept, where it has a much higher chance to be seen by someone who might want to use it.


Sections should have a big enough scope so that you only need to search in one place to find what you're looking for, but not too big of a scope so that you find lots of things that you're not looking for. And I think these changes achieve that.

Anyway, lots of suggestions. I understand that some of them might not be feasible, but I'll take anything as long as systems are no longer in a section called Spells.

Thanks for reading!

 

[Archian]

Thank you for taking the time to suggest some new ideas for our spell section. We will discuss this on our next meeting (this Wednesday)

 

[Daffa]

Thank you for raising this concern, Antares A. I personally agree with most of the suggestions here. I think I'll share my views here as well, as a frequent of Spell section and one of the more active spellmakers as of recent.

TLDR:

• I support the whole Code section turned into archive under System section
• I support the splitting of Spells and Systems into 2 separate sections
• I have to disagree with Concept section as the expansion direction for the new Spell section after the split

[Code Section]
Code forum, if anything, feels very difficult to navigate unless you are a frequent and as Antares stated here, seems to be a discussion between high-end coders, which in my opinion is rather bad since it should be something accessible for the general public. This is, in my opinion, somewhat terrible and create a gap of accessibility. Want to find that obscure code for your map? Good luck navigating the Code forum!

I can barely recall anything in the Code forum ever leave that section unless there's also a "Spell" duplicate of that resources (Damage Engine, PDDS, GUI Autofly comes to mind here). I mean resources like Autofly which would have saved tons of people from headache of handling land unit flying or the like can be very very obscure if I didn't find one in Spell section first. Most of those codes are 'snippet' if not outright 'system' and as far as memory serves, none of them are spells. If anything, I think Code section is a prototype of a System section, though far from sufficient in terms of accessibility.

In short, Code section needs a huge rework if it wants to be accessible, might as well archive it for a proper System section, which I am in favor of Antares suggestion for Code section.

[Spell and System Split]
Instead of Rename Spells Section suggestion, I find myself in agreement with Antares A of splitting into two sections. It is weird looking for Kamehameha and seeing Damage Engine in one section, if anything.

I know there's an argument back in 2012 regarding this exact issue as discussed on Split Spells / Systems where the situation was extremely different. Back then, the System subcategory was not as large as currently is, and the Spell section was purged on 2009 or so due to 1.24 Return Bug patch.

With the current situation, the split would be a valid decision due to the high amount of System in Spell section, approved (including Simple/Useful) and pending combined, yielding a 47 pages of result as shown in Custom Warcraft 3 Spells / Systems / vJASS / JASS which is larger than the entire new Sound section. Even if we cut the Pending and Simple/Useful, we still get 23 pages, 2.3x larger than Sound section.

As for Spell section itself, Approved at Recommended or above rating results in Custom Warcraft 3 Spells / Systems / vJASS / JASS with 47 pages, which is, in my opinion, still warrant an entire section by itself.

If anything, I agree with this line in full entirety:

I'll take anything as long as systems are no longer in a section called Spells.

[Spell Section Expansion]
I disagree with the Spell section becoming a general Concept section with the current state since it means a whole slew of new issues regarding rules for the section and Spell moderators need to readjust to those rulings. The issue lies in this point:

Just a spell, a hero without spells, a hero with spells, a model for a Pirate Uther along with AI generated voice lines etc.

The Sound section and Spell section merging can be chaotic since Sound section represent a more general view of Sound, including ambience and such, which has no relevance with Spell section and it feels like another clutter that will become a ton of issue down the line.

A full hero concept that has spells is already part of the current Spell section, where works such as ones by @chopinski or @Kazeon already exists there. I think a good compromise for this particular need is an additional tag for hero concepts (hero with spells), until we have sufficient for a proper section (I recall we supposedly have 'Spell Pack' tag, or did I misremember?). I personally don't approve the whole hero without spells concept since that deviates the purpose of 'Spell' section itself. Yes, it fits a Concept section, but then it become another cluster of mess down the line in my view.

[EXTRA]
Regarding moderation, I think we can have both Spell and Code moderators as part of System section moderators for a jump start. This is not 2009 or 2012 where pending section just doubles in a week, unless someone like me in December last year unleash a barrage, and I am sure the System section should be sane enough that there won't be an overload since it is not something easily pop into mind everyday, at least not as easy as Spells.

(EDIT)
Forgot to mention, I think one of the lines in Spell Section Rules should be revisited to give better options for Hero Concept and Spell Packs. I am referring to a line regarding imports, that is outside scope of this topic for now.

Best regards,

Daffa

 

[Kyrbi0]

I don't really use, frequent, or even look at these sections, but I just wanna say you've done a great job of organizing your thoughts & positing some solid solutions. I think you may be right.

 

[Daffa]

I don't really use, frequent, or even look at these sections, but I just wanna say you've done a great job of organizing your thoughts & positing some solid solutions. I think you may be right.

I would say this is probably the most extensive suggestion ever given to handle the Spell/System duality issue and all issues that correlates with it as a whole.

 

[Antares]

The Sound section and Spell section merging can be chaotic since Sound section represent a more general view of Sound, including ambience and such, which has no relevance with Spell section and it feels like another clutter that will become a ton of issue down the line.

I agree that my suggestion bears some problems and would require additional reorganizations in the various sections. These are probably a different topic and we should focus on the two changes that you second. But just a quick outline of my thinking:

I think it's a problem that the Model section is basically as big as every other section combined.


I think breaking it apart could make sense, because it's often hard to find what you're looking for. The sections could be:

Models (only unit models)
Effects (missiles, everything Vinzy, as well as sound effects)
Environment (doodads, ambience, and music)

This way, let's say I'm making a sci-fi map and I want to make a railgun shot, I can find a good missile model as well as fitting sounds for it in the same section.

Again, this is something that could have some problems and needs to be fleshed out.

I don't really use, frequent, or even look at these sections, but I just wanna say you've done a great job of organizing your thoughts & positing some solid solutions. I think you may be right.

Maybe you will after this change . Thank you!

 

[Ralle]

Let's not talk about models in this thread .

I agree with you.

Before changing anything, I would like to hear these guys out:

@Bannar
@Bribe
@Cokemonkey11
@Jampion
@Wrda
@Dr Super Good


Anyway. To do this, I would need to do the following:
1. Make Code section an archive.
2. Rename Spells to Spells and Systems.
3. Update description of Spells section.
4. Merge rules? Or just ignore the code rules? Please read them through if you have time and give feedback

Here are code rules:

JASS Submission Rules

JASS Submissions Forum The Submissions forum is a great place to share your custom script for WarCraft III. Any submitted script must be written in either plain JASS, vJass, Zinc, Lua or Wurst resources that you would like to share with the community. Spells or systems which require a demo map...

www.hiveworkshop.com

Here are spell rules:

Resource Submission Rules (Models, skins, icons, spells & systems)

Resource Submission Rules (Models, skins, icons, spells & systems) Users can upload resources to Hive's resource sections. Resources are marked as pending until a resource moderator or reviewer checks it out. The resource is fully visible and downloadable by everyone until that happens...

www.hiveworkshop.com

 

[Bribe]

I have provided a lot of feedback about this in the past, I have included some UI advice on how to implement "copy to clipboard" functionality to things styled in code tags. I have provided information on embedding GitHub code on Hive. I think the Code section is currently just not good, and the Spells section is certainly better, but we'd need to consider not making uploading a map/screenshot as part of the process for that type of resource.

 

[Ralle]

I have provided a lot of feedback about this in the past, I have included some UI advice on how to implement "copy to clipboard" functionality to things styled in code tags. I have provided information on embedding GitHub code on Hive. I think the Code section is currently just not good, and the Spells section is certainly better, but we'd need to consider not making uploading a map/screenshot as part of the process for that type of resource.

I know, and I am sorry I haven't acted on the things we've talked about yet .

 

[Wrda]

I agree with a lot of what Antares A and Daffa said. "Code" in the name scares of most casual users when searching for more complex ideas.
Another thing that has bothered me, and still bothers is...why is UI Interface category in "Skins" section, while the rest of it is non-code? Although it isn't my business, I am curious who reviews the UI category.
Whether you decide to rename the Spells section to "Spells and System" or "Triggers/Code" or whatever suits best, I'd imagine this section to be:
1. Spells
• Single Spell
• Spell Pack
2. Systems
• A typical system
• Code Archive
• UI Design/Interface
I don't really understand the idea of a Concept section, sounds like some Spell Pack could be a "Hero Concept", but not necessarily. I think the creator's resource name would be clear if the spells are thematically linked or it's simply a bunch of spells blundled together.

I think breaking it apart could make sense, because it's often hard to find what you're looking for. The sections could be:

Models (only unit models)
Effects (missiles, everything Vinzy, as well as sound effects)
Environment (doodads, ambience, and music)

This way, let's say I'm making a sci-fi map and I want to make a railgun shot, I can find a good missile model as well as fitting sounds for it in the same section.

Again, this is something that could have some problems and needs to be fleshed out.

In my opinion, if the spel or spell pack are using these models/effects/skins/sounds then I think it might be a good idea to provide some sort of "links" to the respective resources, as in: "This spell is using the following resources: x
y, w, z".
In resource submission rules:

• Submissions must be made using vanilla GUI (aka triggers), JASS, vJASS, Zinc, or Wurst. Using other third party languages, including UMSWE GUI, or similar, is prohibited.
• GUI resources must strive to follow common GUI convention set by GPAG.
• JASS resources must strive to follow common JASS convention set by JPAG.

Spoiler: Lua?

Somehow in JASS submission rules (code) Lua is included. However, code Lua submission rules on code section exists, so there should be somewhat of a merge. For example, the code section, or the "Code Archive" should have a test map and changelog. In fact Lua submission rules looks the equivalent of GPAG and JPAG. Total Initialization and SyncedTable (if one has the intenion of looping with pairs gameplay wise) should be enforced, it saves a pain the in the butt for everyone. Debug Utils and sumneko extension is encouraged

 

[Antares]

I think the Code section is currently just not good, and the Spells section is certainly better, but we'd need to consider not making uploading a map/screenshot as part of the process for that type of resource.

I think that's a non-issue. In the Sound section, you're also required to upload an image for your resource and it's no issue. The preview image doesn't have to be an in-game screenshot. Are you making a mouse utility library? Upload an image of a mouse. Making a matrix math library? Here is your preview image (30 sec google search). Regarding the map, you presumably have a test map where you tested if your resource is doing what it's supposed to do. Just upload that one.

If the Spell/System section would now include resources which would have traditionally been put into the Code section, the rules regarding test maps will of course have to change a bit. I think it's best to just say that the amount of documentation and educational examples in the test map must be appropriate for the complexity of the resource, but, in general, I would welcome it if standards regarding those would be a bit stricter. I also think that, in the era of ChatGPT and friends, there's not really an excuse to have a resource description written in broken english.

Like Wrda stated, the rules regarding programming languages are outdated in many sections. Lua is getting bullied as always. In the Code forum, there's a Typescript section for years now without a single thread yet. What's going on there? Also, does it still make sense to support Wurst? Seems to me like the language was made mostly obsolete by Lua.

2. Systems
• A typical system
• Code Archive
• UI Design/Interface

Are you refering to UI textures or code/systems for custom UI?

 

[Wrda]

Are you refering to UI textures or code for custom UI?

Code for custom UI.

 

[Bribe]

Wurst is type-safe during development time, has its own build process, and can output to Lua (so I am told). TypeScript doesn't have any resources because people who use TypeScript2Lua are sharing their project files on GitHub, where it actually makes sense to do so, because you can't npm install a Hiveworkshop code resource.

 

[Antares]

So, the languages are well, just not on hive? What do you think about the Advanced Scripting forum? Also not particularly active, from what I can tell.

Code for custom UI.

I've never noticed before that the UI section under Skins purports to have UI code. I've never seen anything there while looking for UI Skins.

 

[Bribe]

I think "Advanced Scripting" and code resources in general could be united as one. The best part of HiveWorkshop is getting feedback on stuff. That's why websites like epicwar aren't good for developers, even if they are more popular in terms of downloads. In my mind, development is a community effort, and I owe the success of Damage Engine and others to the people who wanted specific things featured in the resource, and did a lot of bug testing for me over the years. Yes, it's nice to be able to link to one thing and say "go here to get this", and the Resource section - rather than a simple Code forum - is certainly more conducive for it. But I don't think we should outright retire the Code section so much as find a way to migrate them to the Resource section without losing them (thus allowing people who already left the Hive to still have findable resources, as well as not breaking Google results by still archiving the older forums). I think Advanced Scripting and Submissions are pretty much the same thing, and the "approved resources" section is more or less a bias of whatever the moderator felt was good enough at the time.

 

[Antares]

I think we both more or less agree on what the problems are, but have slightly different solutions in mind. You've touched on something in your last sentence. I think that, in general, there are too many sections, subsections, and sub-sub-sections on hive. You have the discussions between coders split between different forums and none of them get a lot of traffic as a result. Even this forum here, the Site Discussion forum, has a subsection for Suggestions, which I think is superfluous and could just be merged. We are a small community and we don't need that many sections to avoid the "scrolling twitch chat" problem. Currently, many forums have the opposite problem: The "why should I post there, no one is reading it" <-> "why should I visit there, no one is posting in it" death spiral.

The Code section is basically trying to do two things at the same time: It's a chat room for advanced coders as well as a resource repository. As a chat room, there's substantial overlap with the Advanced Scripting forum and as a resource repository there is substantial overlap with the Spells section.

You strive for your resources to be useful to the majority of mappers, that's why your systems have extensive GUI support etc. Don't you think that a lot of the resources in the Code forum would benefit from being exposed to the general public just like your Damage Engine? If resources like this MouseUtils library were in the Spells section with better, less jargony documentations, would it not be an overall plus? People could then ask for a GUI translation, which would be easy to do.

And on the flip-side, if we don't split the coding discussion into so many subforums, there could be more active discussions in the one forum dedicated to it. I'm looking for feedback on my engine, but the Spell section is not the right place to get it because that's not where people like yourself hang out. But it doesn't really fit in the Code section, because it's clearly a system, not a Code snippet.

 

[Cokemonkey11]

Wurst has a dependency manager, so in my experience hive submissions are pretty limited to just casual systems and a place for code review

I think you should do what's best for the other languages (but keep wurst around because we do like being here )

 

[Daffa]

1. Spells
• Single Spell
• Spell Pack
2. Systems
• A typical system
• Code Archive
• UI Design/Interface

I think this is the path that I can agree on. UI Design/Interface is one slew of an issue of their own due to it being a combination of either codes (@Tasyen works for example) or art (the ones usually replacing the default UI which has been around for years before 1.31 dropped). I think it can be a separate discussion for whether it fits better under Systems or Skins after the Spells/Systems are split apart.

Anyway. To do this, I would need to do the following:
1. Make Code section an archive.
2. Rename Spells to Spells and Systems.
3. Update description of Spells section.
4. Merge rules? Or just ignore the code rules? Please read them through if you have time and give feedback

I think there's one missing step here, but maybe it's me misunderstanding but I'll try to be clear on how the changes aimed from my perspective.
It is not renaming, but rather split the Spells section into two sections, probably following the scheme @Wrda recommends. So, the final result of the resources section will consist of the following:

[MAPS]
[MODELS]
[ICONS]
[SKINS]
[SPELLS]
[SYSTEMS] ==> Subsection: Code Archive, (to be discussed: UI Design/Interface)
[PACKS]
[SOUNDS]
[TOOLS]

Regarding the rules of both Spells section and the new Systems section, I am inclined with the following proposals based on the existing rules we have:

• A changelog must be present in either the bundle description or the Trigger Editor.
• The description must at least contain a listing of the API, external library requirements and importing instructions.
• Spells must provide an in-game screenshot. Systems do not need an in-game screenshot, but their preview image should be related to the resource.
• Submissions must be useful. Concepts that do not have a clear purpose, or are extremely simple might be rejected (e.g. a "remove unit on death" system is too simple).
• Submissions must be leakless. To find out more about leaks, click here.
• Spells must mimic in-game mechanics (e.g. damaging spells must give bounty when they kill enemies).
• Submissions must be MUI, meaning that they can be casted by multiple units and players without bugs.
• Submissions must have decent performance. Unnecessarily repeating function calls, repetitive group enumerations, overuse of special effects, or other useless overhead, should be avoided to prevent a performance drop.
• Under no circumstances can a resource modify unit user data (custom value) with the exception of unit indexing systems.
• No overloading the test map with bulky, unneeded custom models and icons. If you really do need to use a lot of imported content, link to it in your description.
• Submissions must be easy to import. Strive to require as few changes as possible when importing (e.g. use variables to store object editor data such as abilities and unit-types).
• Submissions must be made using vanilla GUI (aka triggers), JASS, vJASS, Zinc, or Wurst. Using other third party languages, including UMSWE GUI, or similar, is prohibited.
• GUI resources must strive to follow common GUI convention set by GPAG.
• JASS resources must strive to follow common JASS convention set by JPAG.

The only changes to existing spell section rules lies in that I removed MPI since that's usually a system thing rather than a spell thing. Everything else stays the exact same. If that raises an issue due to it being 'a rule change', then keep all the current lines from the current Spells and Systems rules except the one line about systems (since that one will be used on System section and has no purpose for Spell section).

A changelog must be present in either the bundle description or the Trigger Editor.
The description must at least contain a listing of the API, external library requirements and importing instructions. Instructions on how to import the script into a map should it not be simply copy and paste. --> Scripts that are not properly documented will not be approved until such documentation is added. Spend a few minutes listing the API and what each function/variable can do for the user. An undocumented script has no potential if no one is able to take advantage of your hard work.
Spells must provide an in-game screenshot. Systems do not need an in-game screenshot, but their preview image should be related to the resource.
Submissions must be useful. Concepts that do not have a clear purpose, or are extremely simple might be rejected (e.g. a "remove unit on death" system is too simple).
Submissions must be leakless. To find out more about leaks, click here.
Systems must be as instance-able as possible (instance-ability will often depend on the type of system).
Submissions must have decent performance. Unnecessarily repeating function calls, repetitive group enumerations, overuse of special effects, or other useless overhead, should be avoided to prevent a performance drop.
Under no circumstances can a resource modify unit user data (custom value) with the exception of unit indexing systems.
No overloading the test map with bulky, unneeded custom models and icons. If you really do need to use a lot of imported content, link to it in your description.
Submissions must be easy to import. Strive to require as few changes as possible when importing (e.g. use variables to store object editor data such as abilities and unit-types).
Submissions must be made using vanilla GUI (aka triggers), JASS, vJASS, Zinc, or Wurst. Using other third party languages, including UMSWE GUI, or similar, is prohibited.
GUI resources must strive to follow common GUI convention set by GPAG.
JASS resources must strive to follow common JASS convention set by JPAG. Resources’ public API should strive to follow the JASS convention set by JPAG. If you would like to do something different if you think your change improves readability or clarity, feel free to inquire about it with a moderator or collaborate with other users. The important thing is that we are all on the same page, so we know what to expect when we are working with public API.
---
All threads should contain the script's code in the original post itself, unless more text space is needed and each script-inclusive reply is linked to in the original post.
An already approved resource may be deprecated if a replacement is obviously superior in many aspects.
JassHelper resources must adhere to the correct encapsulation syntax introduced by JassHelper.

All submissions here should be included in a library, not a scope.
Contents of a library should be prefixed with “private” when not intended to be used by the user. For structs, there is also the “readonly” keyword which allows a variable to be read publicly but not written to publicly. Use that at your own discretion.
To make something “internal” (can be accessed anywhere in the library, but would otherwise need to be listed as “public” in order to compile), use “keyword” (documented in the JassHelper manual).

Vanilla JASS resources are not able to apply any of those keywords. They must, however, include unique prefixes for “private” variables/functions and, optionally (for readability), be "quarantined” with documentation stating that such code block is only for use with the system and not by the user.
New threads represent new submissions. Do not make a post here unless it is a submission. 1 thread must contain 1 submission. No more, no less. 2 submissions can only be in the same thread if the purpose of one is to add an extra field to the other without making any radical changes to the core. (Add-ons)
Proper documentation must be included with all scripts. This includes, but is not limited to:

A listing of the public API. (This includes functions, structs, modules, globals, struct members, function interfaces, and so on.)
A clear description on how the script should be used and, if possible, explain why the resource is useful.
Any submitted script must be written in either plain JASS, vJass, Zinc, LUA or Wurst. cJass is invalid as it has too many bugs to be acceptable.
A good resource is a resource that has a clear purpose, performs it efficiently and does not require an extensive learning curve. The less it does, the easier it is to debug, improve, learn and implement.

System pretty much uses the current Spell and System rules except that one part regarding mimic in-game behavior and MUI/MPI since it is, as one of the line states in the current rules, 'as instance-able as possible'. Most of the rules from Jass rules can be merged with the System rules from the current list, though in my view the way Jass rules works is that it actually expands upon the core system rules, as shown by comparing above the --- line and below the --- line. I'm in favor of Ignore the Code rules as a whole.

I think, to solve the main issue with Code section and the planned System section to align better is to make it like this. I personally think it adds more work, but probably can alleviate the gap between Code and Spell section users.
1. When a user wants to upload code/system to the new System section, they will get a page similar to the current Spell section upload
2. However, two major changes are done to the upload page for the new System section:
2. a. Image is not a requirement --> if image is not upload, a 'No Image' is shown when the resources is submitted
2. b. Map file is not a requirement --> if map file is not uploaded, no download button is provided
3. This way, the user fills the data as if it is a System resources, but does not receive a mandatory need to upload maps or images, which resolves issue from this point:

we'd need to consider not making uploading a map/screenshot as part of the process for that type of resource.

Also, regarding the whole Concept section shenanigans (point 3 of the initial post), I feel it should be dropped for now. It is another pile of large discussion that can be handled once Spells and Systems stop existing in one section like the current state. The main goal here, as stated by Antares, is this:

[...] I'll take anything as long as systems are no longer in a section called Spells.

Regarding languages, I think it is fine to keep support for the existing languages and add Lua to the list of supported languages.

Whew, a long one. If anything is unclear from my post, feel free to ask for clarification

 

[Antares]

2. b. Map file is not a requirement --> if map file is not uploaded, no download button is provided
3. This way, the user fills the data as if it is a System resources, but does not receive a mandatory need to upload maps or images, which resolves issue from this point:

Or rather you can provide a .j, .lua etc. file for the download instead of a map.

 

[Daffa]

Or rather you can provide a .j, .lua etc. file for the download instead of a map.

Also a good alternative, agreed

 

[Chaosy]

I have less strong opinions than I used to have since I am pretty much retired for the foreseeable future but one thing I think is pretty objectively true is that Spells is indeed misleading.

However there is a legacy aspect to it. If you're renaming it you're ruining all the old threads and replies that talk about or mention the spell section that no longer exist which might be confusing.

I'll also say that the biggest problem of the section in my eyes, specifically for spells.. is bloat and the subjective nature of the uploads. If I want a human ranger model it's pretty easy to find, either by human or by archer/ranger you'll most likely get all the relevant results in relatively few searches.

Now, what if I want a lightning DoT, what do I search by? lighting? electric? static? energy? thunder? storm? maybe arcane is close enough visual wise. The things people name their spells is so varied and spread out there is no good way to find what you might be open to use. My solution would probably be to force more tags for spell submissions but wouldn't work for old uploads so who knows.

 

[Ralle]

I can follow locking the code forum and making the spells section more open to systems. I am not super keen on creating another section. I'd rather just rename it to Spells and Systems and ensure all systems have the System tag and so on.

I think requiring uploading a file is fine, but we should double check what is said about the file, to make sure people know a test map is a good use of the field.

And the rules would need a bit of a tweak to allow for linking to NPM or Github while keeping a test map and a bit of documentation in the description.

Does this sound agreeable or is it two sections or nothing?

 

[Daffa]

I can follow locking the code forum and making the spells section more open to systems. I am not super keen on creating another section. I'd rather just rename it to Spells and Systems and ensure all systems have the System tag and so on.

I think requiring uploading a file is fine, but we should double check what is said about the file, to make sure people know a test map is a good use of the field.

And the rules would need a bit of a tweak to allow for linking to NPM or Github while keeping a test map and a bit of documentation in the description.

Does this sound agreeable or is it two sections or nothing?

I personally still can't really align with the Spell and System still in one section, since it is still technically what is already existent, but better detailed. However, I can see the considerations and it might be not best to enforce separating this section as of the current state of things. My line of thought, after some consideration, is that there's potential for the separated sections ended up being dead sections, and we already have a number of dead sections and adding to that number is far from a wise move.

I can agree to such arrangements given the current conditions, given that both Spells and Systems can be distinct enough to identify in the new arrangement despite being in one section (probably split subsections, or even something around the proposal here), though I still personally hoped those two sections can be separated completely in the future if the situation improves as I have pointed my arguments in previous posts. The way I see it, the arrangement can help determine the actual level of activity from all these sections, giving a groundwork for future decisions whether a separate section is truly warranted or not.

In short, I consider the arrangement agreeable with several reasons (which I am not in favor of, but I can see those reasoning as valid). I don't speak on behalf of others who are in favor of separate sections for Spells and Systems in regard to my agreement to the proposed arrangement.

EDIT:
Yes, I know this sorts of not fulfilling this specific goal:

I'll take anything as long as systems are no longer in a section called Spells.

But I can see the counter argument as of why splitting is not of the best interest for the general community at the moment. A compromise to fulfill this is actually to rename Spell section into Trigger/Code like @Wrda suggested. However, as @Chaosy pointed out:

However there is a legacy aspect to it. If you're renaming it you're ruining all the old threads and replies that talk about or mention the spell section that no longer exist which might be confusing.

It is, in the end, a large dilemma regarding the naming. I personally dislike the proposal since it is not a 'two section', but any improvement to what we currently have, I am willing to give it a shot and see how it goes.

 

[Antares]

I am warming up more to the argument that having too many separate sections might not be a good idea. In general, I think there should be some thought to consider further consolidating various sections on hive, not splitting them apart. While I still feel that Spells and Systems are strange bedfellows, I'm not sure if that's enough of a reason to split them apart.

For code, I think the Spells and Systems section should be promoted for uploading and the Advanced Scripting forum should be promoted for discussions.

 

[Ralle]

I have now done the things I mentioned. Do we need some more tags? I feel like the tag "Spell" might be a bit... superfluous. Keep in mind you can tag both include and exclude for Systems if that's what you want when finding things.

 

[Daffa]

I have now done the things I mentioned. Do we need some more tags? I feel like the tag "Spell" might be a bit... superfluous. Keep in mind you can tag both include and exclude for Systems if that's what you want when finding things.

I think Spell tag is ridiculous as well. Oh yeah, before we forget: Lua

(At this point, Lua is going to be a meme, which is sad)

Edit:
While still on it, probably consider adding tags for Lua? I don't know about Typescript, though it was part of the now Code Archive despite lacking any submission.

Edit 2:
Umm, so, about the file upload, it looks like it is still mandatory to upload a map file or did I miss something? (Probably me being confused in early morning due to lack of sleep, I'll check again later)

Edit 3:
Remind me to not reply hastily in early morning. Just noticed the missing tags are now there. Still weird reading 'Custom Spells/Systems/Jass/vJass' which reminds me of Lua, probably the bold ones can be removed for simplicity or add Wurst/Lua/TypeScript to the text?

 

[Antares]

I have now done the things I mentioned. Do we need some more tags? I feel like the tag "Spell" might be a bit... superfluous. Keep in mind you can tag both include and exclude for Systems if that's what you want when finding things.

• The Spells & Systems description should read "Custom Warcraft 3 Spells & Systems GUI / JASS / Lua".
• The Code Archive description should read "Find archived JASS/Lua/Wurst code snippets and functions here."

One thing I think that's missing is that the Code Archive becomes a subsection of the Spells and Systems section. Is that possible? I don't think having it be its own full section as an archive makes much sense. If you could get the search engine to search in both forums at the same time when you search in Spells & Systems, that would be chef's kiss, but I see that it could be unfeasible because they have different layouts.

About tags I want to bring up one issue for which I don't yet fully know what the best solution would be. To illustrate, let's compare these three resources:

My Hero Selection System
Damage Engine by @Bribe
Relativistic Missile System by @chopinski

They all have identical GUI/JASS/Lua tags, but the versions they offer are somewhat different. I offer a pure JASS, a JASS/GUI (JUISS? Juice?), and a pure Lua version. Some GUI users are now switching to Lua and are looking for Lua resources with GUI support. My system doesn't offer that, but would still appear under both GUI and Lua.

Bribe offers GUI support for both a JASS and a Lua version, which makes it viable for any type of GUI user, but he doesn't offer a pure JASS or a pure Lua version. Therefore, I'm not really interested in the resource, because I don't want to deal with a boatload of GUI variables.

Finally, chopinski, the madlad, offers four different versions - JASS, Juice, Lua, and Gua - satisfying everyone's needs.

What I think could work:

• Consolidate vJASS and JASS tags. This isn't a meaningful differentiation these days and is unnecessary.
• Make the JASS/Lua tags indicate which World Editor language setting they support. You have to tag one of them, but you can tag both if you offer a full GUI version without any custom code (unlikely, because you'll always have CustomScript lines) or if you offer both versions.
• Make a GUI and a Pure Code tag (alternate name No GUI). You have to use at least one of the tags, but you can set both if you have multiple versions.
• Maybe consolidate Typescript, Wurst and Rust-transpiled-to-Lua or whatever people are coming up with these days into Other, but doesn't really matter.

Maybe one thing after the other, but since tags came up, I thought I might as well mention this .

Thanks for taking the time to work on all this!

 

[Antares]

A few comments and questions to tie up some loose ends:

• The Code Archive still appears in the Resources drop-down list. Is that intended?
• Are we going to allow/encourage migration of code resources to the spells and systems section?
• What's happening with the resources that are stuck in the Code Submission section? Some resources have been there in limbo for years. What's going on there?
• The Code section had the rule that resources were graveyarded when a clearly better version was submitted. I don't think that rule makes sense for the systems section in exactly that form, but something to that effect would be good to have, even before the merger. If you search for certain systems such as Inventory Systems, UI Systems etc, you find ancient resources from ~2010 that accomplished that with images on the map instead of the new frame API. I think there's no reason for anyone to use a system like those in 2024, so while I wouldn't just delete them, they should get an "Outdated" rating and not appear in searches by default.
  
  

 

[Ralle]

The Code Archive still appears in the Resources drop-down list. Is that intended?

I have updated the menu now. But for many current members, it still shows. You can customize your copy of the menu when clicking your name -> Customize menu.

Are we going to allow/encourage migration of code resources to the spells and systems section?

Sure. I don't see why not

What's happening with the resources that are stuck in the Code Submission section? Some resources have been there in limbo for years. What's going on there?

Same as above .

The Code section had the rule that resources were graveyarded when a clearly better version was submitted. I don't think that rule makes sense for the systems section in exactly that form, but something to that effect would be good to have, even before the merger. If you search for certain systems such as Inventory Systems, UI Systems etc, you find ancient resources from ~2010 that accomplished that with images on the map instead of the new frame API. I think there's no reason for anyone to use a system like those in 2024, so while I wouldn't just delete them, they should get an "Outdated" rating and not appear in searches by default.

That makes sense. Perhaps we could drop them into "Lacking" with a review mentioning why it's not the recommended one anymore.

 

[Michael Peppers]

So, I (along with other users ofc) have received a PM from Antares about migrating Code snippets into this "new" Spells & Systems section, while i applaud the idea I am looking at one roadblock on this whole deal: the submission rules.

Posting a snippet in the code section never had (roughly) any hard requirement other than posting "good code" while the resources posted into Spells & Systems are required to include a testmap (EDIT: afaik, even though it's not explicitly stated? ). Is it really feasible to migrate the approved code snippets as-is? Most of them don't include a testmap and I suspect a lot of people submitting code in there chose the section on purpose not to be bothered by that requirement.

 

[Wrda]

Most of them don't include a testmap and I suspect a lot of people submitting code in there chose the section on purpose not to be bothered by that requirement.

Because there's no rule that enforces the upload of a map. That's exactly why I suggested for code submission rules to "somewhat" merge with the resource submission ones.

I've never noticed before that the UI section under Skins purports to have UI code. I've never seen anything there while looking for UI Skins.

Yeah, which surprised me when I saw Tasyen's legendary UI resources there.

 

[Michael Peppers]

Because there's no rule that enforces the upload of a map. That's exactly why I suggested for code submission rules to "somewhat" merge with the resource submission ones.

I had to double check... and wow, you're right, now there's no bullet point explicitly stating the need of a test map, although some other rules still mention specifics about the test map. Wild stuff. Also, kind of confusing.

 

[Dr Super Good]

Why you bully Lua?

Probably using the same description texts as it did before Reforged lol. Similar to how in the depths of some sections there probably are still resources using handlevars or other gamecache with typecast exploit based systems that have not worked for at least a decade.

I agree that the sections probably need to be revised. Originally the code section was for experimental code or systems that did not really have a demonstration map associated with them, or that were expected to be included as part of another system. In more recent times it seems such scripts are being posted in the Advanced Scripting section instead (which also should have its description updated to include "Lua"). A lot of the better/more complete code submissions even come with demonstration maps, which would be sufficient for them to be a system resource.

 

[IcemanBo]

So, I (along with other users ofc) have received a PM from Antares about migrating Code snippets into this "new" Spells & Systems section, while i applaud the idea I am looking at one roadblock on this whole deal: the submission rules.

Posting a snippet in the code section never had (roughly) any hard requirement other than posting "good code" while the resources posted into Spells & Systems are required to include a testmap (EDIT: afaik, even though it's not explicitly stated? ). Is it really feasible to migrate the approved code snippets as-is? Most of them don't include a testmap and I suspect a lot of people submitting code in there chose the section on purpose not to be bothered by that requirement.

I got also PM'ed and wanted to address it would be little sad if resource discussions would be lost with the deletion of old resource, after re-submitting in new section. Maybe moving of posts is possible, or otherwise not deleting threads, but having a thread link in new section might be an option.

 

[deepstrasz]

I guess the code and spells reviewers/mods will be named Spells & Systems Reviewer/Moderator? I suppose code is too much a vague notion since it can refer to Advanced Scripting and Programming ?

 

[Eikonium]

I got also PM'ed and wanted to address it would be little sad if resource discussions would be lost with the deletion of old resource, after re-submitting in new section. Maybe moving of posts is possible, or otherwise not deleting threads, but having a thread link in new section might be an option.

I feel the same. There is lots of important discussion in the old code threads that I don't want to lose.
Also, my code submissions link to the current URLs in their documentation, so users can easily revisit the resource page later. Would be nice if that link wouldn't break after transition.

I guess keeping both the old and the re-uploaded version and linking to each other in their descriptions is a suitable workaround. At least in case the old one is not being deleted.

Alternatively and even better (as @IcemanBo suggested), moving all posts to the new resource page and also linking the old URLs to the new page would solve it.

@Ralle can you confirm which way to go?

Another thing:
Systems have been incorporated into the Spells section now, although most users in this discussion agreed on that they are completely unrelated things that have just been mixed for legacy reasons.
If that decision is going to stay (which I understand, but I'm not happy about), I suggest to at least revamp the current search filter options in a way that you can easily search for the one or the other in an intuitive way.

These search filters do already exist, but they are too hard to find.
For instance a user searching for Lua code must currently click on "Navigation", scroll down past the quality options , open the "Tags"-section, activate Lua, activate "System", deactivate all other options and click on "Apply". The System-Tag is listed below the "Other (Spells)" label, although systems are not spells. I personally wouldn't have expected any of these options under "Tags", because the phrase is too unspecific for this most important criteria the we now have.

If Spells and Systems are being kept together, I'd love to see their filter options (plus their language) becoming more dominant to see and intuitive to use.

 

[Ralle]

I will keep the threads around. Perhaps I may merge some of the forums, but definitely no deletions.

Another thing:
Systems have been incorporated into the Spells section now, although most users in this discussion agreed on that they are completely unrelated things that have just been mixed for legacy reasons.
If that decision is going to stay (which I understand, but I'm not happy about), I suggest to at least revamp the current search filter options in a way that you can easily search for the one or the other in an intuitive way.

These search filters do already exist, but they are too hard to find.
For instance a user searching for Lua code must currently click on "Navigation", scroll down past the quality options , open the "Tags"-section, activate Lua, activate "System", deactivate all other options and click on "Apply". The System-Tag is listed below the "Other (Spells)" label, although systems are not spells. I personally wouldn't have expected any of these options under "Tags", because the phrase is too unspecific for this most important criteria the we now have.

If Spells and Systems are being kept together, I'd love to see their filter options (plus their language) becoming more dominant to see and intuitive to use.

So like with all sections we have "Quick links" we should expand it for spells. Would that make sense?

So we'd add

Systems
Spells

as extra quick links? I am not sure about the languages. We have quite many.

 

[Antares]

Copying the discussion over would be the best solution, but if that's not possible, keeping the old archived thread around is probably the next-best.

I second what Eikonium is saying.

I want to bring up one more issue about the search function. It only searches for whole words. You can't find my Better Dialogs system when you search for "Dialog". This problem isn't unique to the Spells & System section, though. You can't find Vinz's Ubershield model when you search for "Shield". I get that this can be beneficial, for example when you're searching for a "Cat" model and you don't want to find all the models that have these three letters somewhere in their name, but I think this behavior is detrimental in the majority of cases and has to be either improved or removed.

Adding keywords to the description doesn't help, as far as I can tell. Vinz put "Keywords: Uber, Shield" in his description, but I still can't find it when I search for "Shield", neither in center search bar or in the Keywords filter on the left.

This will make, for example, tasyen's HoverOriginButtonV1.3 impossible to find except via his profile.

 

[Cokemonkey11]

Unsubscribing, @ me if you need something

 

[Eikonium]

I will keep the threads around. Perhaps I may merge some of the forums, but definitely no deletions.

Copying the discussion over would be the best solution, but if that's not possible, keeping the old archived thread around is probably the next-best.

Yes, copying would be best. I will make a dummy post linking to the old discussion below the new resources for the time being.

So like with all sections we have "Quick links" we should expand it for spells. Would that make sense?

Yes, that's much appreciated.
May I further suggest to move the Systems/Spells search filter above the resource quality options and keep it always expanded?
Choosing "Systems" will always be the first thing I do after visiting the forum via normal navigation - and people visiting via quick link would directly see Systems or Spells being checked, which helps to understand the structure and avoids confusion.

Is there currently even a spells filter? I only see System, Pack and Template.

Not sure about the languages. We have quite many.

I consider language options next-most-important after distinguishing Systems and Spells, because we can only use exactly one in our maps. I personally would put the languages search filter second from top (below System/Spell and above quality options), collapsed into a "Languages" group.

 

[Eikonium]

@Ralle Before anything else, could you allow .j, .lua and .ts file endings for the Map-upload-functionality? The w3*-restriction currently prevents me from moving my resources

 

[Antares]

Why not just copy your code into an empty map and upload that? Might even be more convenient for some people to import because they can simply copy the folder in the Trigger Editor. If the functionality to upload .j etc. files gets added later, you can still add those.

 

[Eikonium]

Just didn't want to use workarounds, if not necessary. I don't personally see people opening an empty map in the World Editor just to copy-paste code they could have directly copied from the resource page (maybe except for multi-script resources like Debug Utils). But yeah, I could do that just for the sake of meeting the technical requirements. Maybe I'm wrong. Will find time on Sunday.

 

[Ralle]

I think a test map would be really nice in most cases. But I did just allow the "binary" resource type which contains .zip at least. I should expand it to .lua and .ts in the coming time. But please keep uploading test maps.

 

[Eikonium]

@Ralle Sorry for bothering you again. I just tried to copy one of my code resources to the spells section, but wasn't able to access my old post source (text incl. BB-code), because the old code forum is blocked for further posting and the Edit-Button disappeared as a consequence. Recreating all my resource pages from scratch is not an option.

Would you kindly grant thread edit permissions to the respective thread owners?

This wouldn't only allow us to copy-paste our resource description, but also to add a hint to the old page, where the resource was moved to. This is particularly important for me personally, because all my code documentations link to the old resource pages, and my users otherwise would never recognize any updates when revisiting the old page. Let alone that those who have watched the old pages will not receive further update notifications, until they also watch the new page (but how would they know that they have to?)...

 

[Ralle]

Yes of course. I unlocked everything except submissions and graveyard, does that suffice?

Also, you are welcome to link to the new resource from the old thread.

 

[Eikonium]

Maybe relevant for other users moving their resources via Hive-Editor copy-pasting:

• Emoticons ( ) are copied as image and increased in size. Had to manually replace them by fresh emotes. Maybe there is a smarter option
• Pictures were copied as [ATTACH]-tagged references (which is the same as in the original post so far), but they didn't show up as such. Instead I got this at their place:
  
  
  Solution was to right-click the image in the original post, copy as link, and embed them again in the new post using the Insert-Image-by-URL function of the hive editor (Ctrl+P -> second tab).

Not big issues, just something to be aware of.

 

[loktar]

Not big issues, just something to be aware of.

Did you copy it in bb code mode? If not, click the [ ] button next to the Preview button. If you toggle BB code on and copy it from there, images and emojis should transfer correctly. I don't know about attachments though, those will probably still need to be manually added back as you said.

 

[Eikonium]

Did you copy it in bb code mode? If not, click the [ ] button next to the Preview button. If you toggle BB code on and copy it from there, images and emojis should transfer correctly. I don't know about attachments though, those will probably still need to be manually added back as you said.

Good hint, thanks. As you suggested, emoticons copy correctly in BB-code-mode, while attached Images do not. I wasn't aware of that this mode makes a difference and I reckon it's not intended by XenForo