Welcome to the community where modding your favorite game can be possible, and supported by a nice and warm community. Here you will find resources which will help you to develop your projects faster. Additionally you can show your projects and share with a growing community, even be part of the Blizzard Modding Network, which aims to gather all the projects and clans around this game.
JNGP 2.0.9 is live!!!! Fellow WC3 modders & mappers:
It's an honor to announce the release of the new version of JNGP: 2.0.9. With this new pack, I've added the most recent mods for WE and other features that will help you in the mapping process.
Among the main features added in this version, we can find the new WC3 patcher, which allows to set your WC3 installation in any version different from 1.27, this is needed to allow multiplayer emulation to work properly.
Some tools has been updated to the latest version:
One of my favorite string scripts from Python. I can't live without it.
StringStrip will strip the leading or trailing characters from a particular string. This is very, very useful for parsing. Just to show an example, you have a command: "-gold 500" Normally, you would read it as SubString(text, 6, StringLength(text)), and convert it to an integer. But what if someone types it like this? " -gold 600 " That should be perfectly acceptable, but the system will interpret it as "d 600 ". If you try to convert that, it will return 0. There are many ways to approach that problem, but one way is using StringStrip(). Simply:
function StringStrip takesstring text, string chars returnsstring
set text = StringStripLeft(text, chars)
return StringStripRight(text, chars)
It is mostly useful for spaces, but you can use other characters too--even multiple ones: "xxxtestxxx" -> StringStripLeft("xxx") -> "testxxx" "testing" -> StringStripRight("ing") -> "test" As far as complexity goes, this is a very lightweight function, despite how large it looks. It can be implemented recursively, but recursiveness is generally a bad idea in wc3 speed-wise. It doesn't generate any more strings than it needs, as well.
This library will allow you to simulate a 3D sound. It will have most of the features of a 3D sound, except for cones and velocity. Most of these are guesstimates, but when I compared it to the regular 3D sounds, they were very similar.
I don't have a 100% concrete grasp on what each field does, so if you have more insight on it, feel free to share. I interpreted it from a lot of testing, but even then there are still a few things I can't account for.
Anyway, why have this system? (1) 3D sounds are incredibly annoying. As far as I can tell, mp3's and 2-channel sounds don't work as them. This will allow you to use it as a regular sound, so you won't have to worry about any of that. (2) If you have a 3D sound, you cannot use SetSoundPlayPosition(...). If your sound is not 3D, you cannot have 3D features (obviously). This system will serve as a compromise, having the sound as non-3D and emulating the features of 3D sounds to get the best aspects of both sides.
Introduction Before I start, I would just like to credit Moyack for patience with testing and pointing out certain flaws, especially with how the code is presented.
Description I have created a function, that can group units in line with; a distance-value that is unchanged no matter where the end-point may be, a radius-value, a optional spread-value (determined in radians, easiest way to get the spread-angle you want is to create a constant with the spreadangle * bj_DEGTORAD) and an optional boolean exp-filter.
privateconstantgroup GR = CreateGroup() //a constant unitgroup to avoid all CreateGroup, DestroyGroup and gr=null stuff
constantreal RV_pi2 = Acos(0) //A half-pi, should not be changed
privateconstantreal UNITEXTRASIZE = 16 //This number could be played with to fit your needs, it is basically just a number to make the radius-value more linear. Otherwise, only units with their centers in the cone passes the check.
privatefunction LineGroupFunc takesgroup g, real startx, real starty, real endx, real endy, real distance, real radius, real spread, boolexpr bex returnsnothing
What it does: it takes a group to fill (a group already existing), 4 coordinates (startx, starty, endx, endy), a real value distance (how far will this line go from the start-coordinates. It could reach and go further than the end-point or it could not get that far at all), a real angle expressed in radians that tells if and how much the line should change as it goes further (0.262 would give a 15~deg spread in angle, 0 will give a straight line) and a boolexpr "bex", this to actually lessen the cpu-usage in some cases, as the more units getting filtered away with the boolexpr, the less units it has to calculate for (just set this for null if you want it to take all units in the line)
How to import: Easiest way; download the testmap, open it with the NGJP-world editor, find the trigger named LineGroup and copy it, and paste it in your map. Alt. copy all text inside the LineGroup-trig and paste it in an empty text-trigger.
How to use: Create a group with locals or use a group from an global variable, then call LineGroup with the group as the first value, and the rest with the values in the order told at a number of places in this text.
And a little extra, the code won't empty the group itself, so you could make some special stuff, like fan-shapes and stuff (this might require some further math, if someone is interested, I could show how.)
If you find any trouble with this, know a way to improve it or just have a question, just ask in this thread or PM me. (the map have a non-other-than-me-user-friendly version of the TickTack, or ChainTimer as I have comed to call it. Dont mind that.. )
This library will allow you to disable/enable the feature that allows you to skip cinematic transmissions by pressing ESC. Some RPG's are ruined when other players press ESC during a cinematic because it skips the transmission for everyone. This neat script can prevent that.
This solves the ever-so-annoying problem of unit orientation--determining how one unit is facing, or oriented, in relation to another. This snippet provides the functionality to: - Determine if a unit is behind a unit - Determine if a unit is facing the behind of a unit - Determine if a unit is facing a unit
All with an angle margin (margin of error, sort of) to determine what is considered "true" or "false" for those functions. View the image and the documentation to get a better understanding of how the angle margin works. Here is the code:
Let me know if there are any functions you want me to add. If you still don't understand the purpose of this, think about the conditions for a backstab spell. You have to be (A) behind the target, (B) facing the target. This snippet will allow you to check those easily.