• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[Concept Tool] WC3 Project Manager

Status
Not open for further replies.

Deleted member 219079

D

Deleted member 219079

WC3 Project Manager

It's not that seamless to work between text editor, say Sublime Text, and WE. Namely because you have to use //! import, which you don't have to use when working inside WE.


projectman.jpg
We have map MyMap.w3m which is resided in its own folder along with script - folder (could be "src" as well).
This tool adds MyScript.j and MySecondScript.j in vJASS syntax and MyZincScript.zn in Zinc syntax into the map.
projectmanstdlib.jpg
Here we have added stdlib to the same folder where the tool is, and 3 folders are generated automatically.
You can add libraries to the bin folder which you want to get imported into every map of yours.
Folder obj will contain ObjectMerger commands in future versions, meta contains info on which map already has which objects.

VersionWindows (32-bit)Windows (64-bit)
0.21DownloadDownload
0.20DownloadDownload
GitHub - ShittyJASS/projectman: WC3 Project Manager


0.21
  • Primitive standard library (bin)
  • Files are now sought from "src" and "script" - project folders
  • Files are appended to the dest file instead of being referenced in //! import
0.20
  • Initial release


REPORT BUGS AND UNWANTED BEHAVIOR, THANKS
 

Attachments

  • WC3 Project Manager (x64).rar
    12.5 KB · Views: 69
  • WC3 Project Manager (x86).rar
    11.6 KB · Views: 64
  • WC3 Project Manager (x64).rar
    13.7 KB · Views: 78
  • WC3 Project Manager (x86).rar
    12.5 KB · Views: 70
Last edited by a moderator:
Level 13
Joined
Nov 7, 2014
Messages
571
It's not that seamless to work between text editor, say Sublime Text, and WE. Namely because you have to use //! import, which you don't have to use when working inside WE.

One can simply reduce the //! import "directives" to just one?:

asd.j:
JASS:
library Asd
    function asd takes nothing returns nothing
        call BJDebugMsg("asd")
    endfunction
endlibrary

lol.zn:
JASS:
 //! zinc
library Lol {
    function lol() {
        BJDebugMsg("lol");
    }
}
//! endzinc

init.j | map-script.j | main.j | imports.j |whatever-you-want-to-call-it.j:
JASS:
//! import "asd.j"
//! import "lol.zn"
// etc.

Now make a single trigger, convert it to text and write just 1 import in WE //! import "map-script.j".
 

Deleted member 219079

D

Deleted member 219079

This is meant to make the environment more seamless, not directly add new functionality. Besides, that procedure is a burden you just posted. Also, what if you want to relocate a mass of scripts when you have hundreds of them? Then this tool is the only way.
Also in that very example you already have 3 import commands...

Edit: You'd have to spam those zinc commands all over the place later on in your example, this tool deprecates that.
 
Last edited by a moderator:
Level 13
Joined
Nov 7, 2014
Messages
571
Besides, that procedure is a burden you just posted.
I think it takes ~1 minute or so, but if someone is so eager of testing/trying something, they could create a directory with the necesery *.j files and a dummy map with the trigger already created and having that //! import "eager-main.j" already written, then copy that directory type some vJass, open WE, compile [, fix errors] and not be so "burdened" with it...

Also in that very example you already have 3 import commands...
If the idea was to make it "seamless to work" in some editor program (Sublime Text, or whatever), I think the above setup qualifies because one has to use the Trigger Editor once (creating that trigger with the import directive; maybe opening it again for some jass reference, I suppose),
after that they can write their whole map script with the editor program.

Also, what if you want to relocate a mass of scripts when you have hundreds of them?
I don't quite understand the question, but I guess using only relative imports and not making that many files in the first place would help...

You'd have to spam those zinc commands all over the place later on in your example, this tool deprecates that.
One has to write them once per zinc file...
 

Deleted member 219079

D

Deleted member 219079

I think it takes ~1 minute or so
It accumulates to lot more than that... Especially if you refactor the code structure during the development.

above setup qualifies because one has to use the Trigger Editor once
My point is this:
you have to use //! import, which you don't have to use when working inside WE.
You'll end up with a load of import commands as your project becomes bigger. I'm
coming heavily from this post (reason why I made this tool), namely the "Remove the need of //! import".

not making that many files in the first place would help
...I think you haven't worked in a team, have you now? Keeping files short, separating them as much as possible is a necessity to retain some sense in any project.

One has to write them once per zinc file...
Which, again, accumulates to a lot of //! zinc and //! endzinc commands as the project grows.

You aren't forced to use this tool and this only makes things easier, so I believe you're arguing for the sake of arguing, which is not what I want, I want bug reports on the current version of the tool so I can advance in the development and eventually make a thread in tools section. Just tell if you e.g. got it working on Windows XP / Vista (I have 7), there's unexpected behavior, unexplainable error messages, or give suggestions on new features.
 

Deleted member 219079

D

Deleted member 219079

I was thinking of using this to automatically import a bunch of libs that one eventually have to use anyway.
Was this your original intention?
If you mean stuff that doesn't need configuration, such as UnitDex, TimerUtils, Table, WorldBounds, Dummy etc. then yes, but not this version yet.

For stuff that need to be configured in globals, I will not add support.
For stuff that have //! external - commands, I will have two files, A and B; A has the library itself, but with the external lines removed, which are in file B. B will get imported once only, after which map's name is added to a blacklist, to know that you don't have to add that B file anymore.

Most likely I will have graphical front end for fetching those files, in the same manner this did (just a lot less buggy lol...).

Edit: Note that this has second purpose which is already fulfilled: importing external project files into the project without the need of //! import.
 

Deleted member 219079

D

Deleted member 219079

New version: 0.21
- Naming convention changed: 0.x.y -> 0.x
- Primitive stdlib (primitive in a way that ObjMerger commands cause slowdown)
- Files are now sought from "src" or "script" folder: if not found, application aborts (so stdlib isn't applied either)
- Files are now appended to dest file without referencing with //! import
- Code is now stored on GitHub
- Updated OP with example images for both project and stdlib

Next version will handle scenario where project and stdlib have file of same name (stdlib's file is discarded). After that I get to that dirty ObjectMerger.
 
Level 6
Joined
Jul 30, 2013
Messages
282
personal exp:
i have 2 import statements in my map
one imports a file that imports all vjass resources
the other imports a file that imports all cjass resources(i know Nes' gonna hate on me but must be honest here it is useful sometimes..)

also it takes some effort to make sure different dialects don't intermingle in a bad way, perhaps a system such as this (where the order of scripts does not change in a semi random way every time you touch them) could help.

makes life a lot easier. also you don't want to commit the map file every time you fix a typo... altho if the typo is in a tooltip, no helping it :'(
 

Deleted member 219079

D

Deleted member 219079

personal exp:
i have 2 import statements in my map
one imports a file that imports all vjass resources
the other imports a file that imports all cjass resources(i know Nes' gonna hate on me but must be honest here it is useful sometimes..)
Yes, but you'll still have to use //! import in those files...

also it takes some effort to make sure different dialects don't intermingle in a bad way, perhaps a system such as this (where the order of scripts does not change in a semi random way every time you touch them) could help.
If you took a look at the source code (don't fork it at this stage, I can't merge it as my local code is so much different, rather give suggestions here), you see that I have file extension as one of the file entry's members. This is so that I know when to place //! zinc and when to end it, but yes I could pick up .cj - or whatever cJASS's extension is - files and let other compiler handle those files.

As a bit of a progress report, this is the first graphical element, coming in 0.22; progress window:
wc3projmanimportprogress.jpg

I think it's a big flaw that ObjectMerger commands always trigger so I will be focusing on that before anything. This dialog tells that slow ObjectMerger - commands are being worked on. If JassHelper phase doesn't return error, program will write in meta files that objects are now in the map.
Now, what if you don't re-open your map after object merges? Then you're fucked haha xd I don't know how the merge could be done without need for re-opening, if someone knows I'm all ears.
This externalized object data feature needs another program which extracts //! external ObjectMerger directives from maps in bin folder, it will come bundled with 0.22. Later on CLI tool will fetch libraries from web and automatically do the extraction. Then I will make it GUI, and I will consider this whole project done. Will take months, or years idk...

Edit: Another GUI component, directory prompt:
upload_2016-10-27_13-48-50.png

This one took only 3 hours to do, hehe :D
 
Last edited by a moderator:
Level 6
Joined
Jul 30, 2013
Messages
282
the more things we can take out of the monolithic map archive the better.
the more data we can have in plain(ish) text files the better.

binary blobs are a nightmare when working not-alone as there will be 0 chance to merge work done concurrently.

currently vjass imports help with that for scripts but for object data there is still no good solution that i can think of. same for map/terrain data.
 
Level 6
Joined
Jul 30, 2013
Messages
282
Well, what if object data was in text files? (I'm in the chat atm btw)

that would be spectacularly useful. that would mean 2 (or more) people can work on object data concurrently (you can git-merge text files quite pain free most of the time, and since they are text files you can merge manually if there are complications. with binary files it is either difficult.. or fragile . or impossible to merge them.)

also.. if you delete some object data it can cause issues in maps, if it was just a text file and not a magical blob it would likely be more robust.

rather than have 1 artefact that gets modified and contorted infinitely it is imo better to have the bare source files and a build process to create a brand new artefact when ever needed. this would make you immune from the issues regarded to mutation/corruption of map files over time due to editor bugs or other factors (WE crashes mid-compile? map still seems to work but sth broke that you don't notice and this will effect all future versions)

mpq editing tools can help get more of the stuff outside of the map but they are not really ergonomic, the build process will become so magical it will hinder the ability to bring new people on to the project if we use it. also a lot of the files inside mpq are themselves magic binary blobs.. that can at times be fragile also can not be git-merged even if you extract them because they themselves are magic blobs.

hmm so yeah in summary "i want better git support" or in other words:
  • need a way to store as much of resources outside of the map as possible
  • resources should be in human readable format (text file... maybe json, csv? xml is a bit stretching it but would use if rly needed)
  • it helps to have distinct entities in separate files(1 file per object for example?) (having distinct bits of data on separate lines helps with automatic tools (1 attribute per line? ))
  • will gain ability to do concurrent work on map in return.
  • will make changes to map transparrent to inspection
  • map will become friendlier to source code management (you NEED it for any project that lasts more than 15 minutes.. REALLY)
  • to compile the map from all the components to final product should be 1 action(1 click, 1 command, 1 magic hotkey combo, 1 etc..) at the moment jngp saving the map kind of does this. its kind of annoying that there is no bare command line tool to do this but i guess WE is kind of needed so i don't mind it.
  • unified syntax(almost forgot about this) it is kind of annoying if you have 5 different ways to write "copy and paste contents of that file to this location" much less more complex operations. ObjectMerger is rly inelegant imo as it is Lua inside vJASS representing a CSV.. or a KeyValue store
 

Deleted member 219079

D

Deleted member 219079

I have an experimental update on the tool. Do not use in production, I can only quarantee it doesn't work for shit.


Prerequisites
Microsoft Visual C++ Redistributable for Visual Studio 2017 for 64-bit Windows, Warcraft III 1.28.5.

Using the WC3 Project Manager (PM)
Have project files in their own folder and run the PM executable. E.g. create Hi.zn with contents: library MyLibrary { function onInit() { BJDebugMsg("Hi!"); } }
Then, in command prompt, change directory to project folder and run PM. Run PM with --debug for debug build, --run for launching map in Warcraft III.
Besides having .j and .zn files compiled into map's JASS2 code, PM can run Main.lua file that can be used to import various things to the map.

Using the Lua Variable importer
You can import numbers, strings and booleans from Lua to map as JASS2 globals.
Follow syntax: build.globals["myGlobal"] = 1 (which translates to constant integer myGlobal = 1).

Using the Lua file importer
Simply follow the syntax: inMapPath = build.import("C:\\Path To Project\\Importee.extension")
You can also give the path relative to PM's execution directory. In-map-path is the file name by default, but you can give it explicitly as a second argument.

Using the Lua object importer
First learn raw object data notation in Warcraft 3 Object Editor with View > Display Values As Raw Data (Ctrl+D).
Then in Lua, call build.create<type> with object ID and table with modifications, e.g. newObjectId = build.createunit("hfoo", {Name="OP Footman", HP=9000})
Supply any multi-level property as a number-indexed (1-based) table, e.g. newObjectId = build.createability("AHtb", {Name="OP Bolt", DataA={300, 600, 900}})

Report bugs
Report bugs with steps to reproduce via this thread, VM, PM or Discord (BlueSaint#7503).

Notes
- Editing of original object data is prohibited
- Do not open the output map in World Editor, it might be corrupt and crash WE
- Buttonpos (items), Buttonpos, Missilearc, Missileart, MissileHoming and Missilespeed (units), Buttonpos, UnButtonpos and Researchbuttonpos (abilities) and Buttonpos (upgrades)
each refer to 2 properties, modify them as a number-indexed (1-based) table, e.g. newObjectId = build.createunit("hrif", {Buttonpos={0, 0}}

Known issues
- AIlb (Item Attack Lightning Bonus) and AIpb (Item Attack Poison Bonus) have DataA twice and will not work correctly.

I'm using this with VSCode with this extension: vjass support extension for Visual Studio Code
My tasks.json is as follows:
JSON:
{
    "version": "2.0.0",
    "tasks": [
        {
            "identifier": "buildDbg",
            "label": "Build Debug",
            "type": "process",
            "command": "Path\\To\\WC3 Project Manager.exe",
            "args": ["--debug"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": []
        },
        {
            "identifier": "buildRls",
            "label": "Build Release",
            "type": "process",
            "command": "Path\\To\\WC3 Project Manager.exe",
            "args": [],
            "group": "build",
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": []
        },
        {
            "identifier": "buildRun",
            "label": "Run Last Build",
            "type": "process",
            "command": "Path\\To\\WC3 Project Manager.exe",
            "args": ["--run"],
            "group": "build",
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": []
        }
    ]
}
Then I have key bindings for each task.

Edit: Fixed bug where build.create<type> and build.idstring handled ID in reverse order.

Edit 2: Added example.
 

Attachments

  • WC3 Project Manager 0.22 rc-2.zip
    1.5 MB · Views: 43
  • Example.zip
    644 bytes · Views: 33
Last edited by a moderator:
Status
Not open for further replies.
Top