Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
For my upcoming MOBA map, I thought about using SharpCraft to retrieve mouselocation.
The difference between using sharpcraft and no sharpcraft is that I will have proper targeting UI for all abilities instead of the standard AoE and TargetPoint.
The problem is that if you want to play it, you need sharpcraft too.
I want your help with this decision, so please reply to this post and answer the following questions:
Do you have SharpCraft?
Do you think that I have to use it or not and why?
Personally, I think SharpCraft (Or some kind of equivalent) should become standard. It extends a lot of WarCraft 3's functionality and allows for a lot more things, which can allow for a lot more funner maps...
There are still people that go 'wtf?!' when told to enable local files in order to play a map, so id doubt that would be of any success unless forced en-masse by the game's developer in the form of an mandatory update.
just my 2 cents
Why? Because it improve a lot the game itself, allowing so much possibilities.
The only problem I see with it is one: The instruction to use it is so poor, like, noone want to teach exactly step-by-step how to use it.
Want to use it? Ok, go ahead, but make sure to make a guide doing so, pictures, video, anything, but make sure everyone understand how use it, or you'll have troubles.
In my opinion you should base your decision on your opinion, not the opinion of potential players.
You are making a wc3 map, so you won't get big attention anyways. It might be that player numbers are decreased by a large percentage if you require Sharpcraft but who cares if the number will not be large anyways. Saying if you want to make a bit more ambitous project, use Sharpcraft for your own fun of creating it.
And if you somehow manage to create a brilliant DotA-like map with Sharpcraft, you might get attention for that. (As it has happened with other elaborate mods for old games)
edit: there is info I was not aware of. If this is right, it changes things:
The development is dead.
Also TH's mouse&keyboard native is for single player map only. So be careful.
Personally, I think SharpCraft (Or some kind of equivalent) should become standard. It extends a lot of WarCraft 3's functionality and allows for a lot more things, which can allow for a lot more funner maps...
I guess that settles it... It was only a small part of the game but wouldve been nice if it would work.
Anyway, thanks for the replies...
(((For those who have noticed that I have had a lot of questions and are curious about my map, it is almost finished and you will probably be able to see the results next week.)))
The mouse/keyboard natives shouldn't be single player only. They work in a similar fashion to GetCameraTargetPositionX(). While that data is indeed local, they can be read within a local block and then broadcasted to become nonlocal. But this requires syncing, which is generally slow across battle.net (expect similar delays as the keyboard natives). So that may limit the use a little bit--but it is still perfectly usable. (for the technique, see this. The same technique would be applied, but for mouse natives)
But overall, whether to use SharpCraft is based on your expected audience. SharpCraft multiplayer is good for friends (since they can all download SharpCraft [or a bundled exe if you plan to release it in a more portable form]), but bad for random players since it will be painful to arrange matches.
SharpCraft is great for single player maps since you know the person playing will have downloaded it from your source.
For maps in general, SharpCraft is great for additional features. (1) Your map should be playable without SharpCraft (2) if you have SharpCraft, you can have access to additional features. One example could be managing a database online. Normally users are expected to write down save/load codes, but you could detect a SharpCraft installation and allow them to use commands to send/receive data to/from a server (which means the person wouldn't have to write down the codes at all! He could just remember a username/password). But this method requires a bit more knowledge--you must be familiar with creating SharpCraft natives (which is easy if you know the C# form of what you want to do). Then you would rewrite natives to act as special signals in your code. e.g. If you wanted to be able to detect if a user has SharpCraft via code, you could write a SharpCraft script to overwrite the LoadInteger native when given particular input:
JASS:
local integer a = LoadInteger(null, 434395, 345894)
The input you choose is trivial. It just has to be something that is unlikely to be used in your regular code. In your SharpCraft script, you would check for that input, and return a nonzero integer to indicate that SharpCraft is installed. If the user doesn't have it, then it would return 0. This may seem complicated, but it really isn't. Just see MindWorX's "Cheat" example that is in the SharpCraft thread--it showcases this technique.
It seems like I've gone off on a tangent--but my general ideal for SharpCraft is that you should use it for conveniences/features in your map. I don't think it is wise to have your map rely on it though, unless it is perhaps single-player. If you want to use it, make sure you have the knowledge use well! If you have a multiplayer map, this means that you should have knowledge on "local" data and what could potentially desync players. But it is an awesome tool if used wisely.
The mouse/keyboard natives shouldn't be single player only. They work in a similar fashion to GetCameraTargetPositionX(). While that data is indeed local, they can be read within a local block and then broadcasted to become nonlocal. But this requires syncing, which is generally slow across battle.net (expect similar delays as the keyboard natives). So that may limit the use a little bit--but it is still perfectly usable. (for the technique, see this. The same technique would be applied, but for mouse natives)
They are apparently different. I was talking about the event, not returned value. TH's mouse&keyboard events are fired locally. There is no GetTriggerPlayer(), you can only use GetLocalPlayer() to get the clicking/pressing/triggering player. Perhaps you can use Nest's Network system but now it's too slow. I've also heard that you can use Game Cache to sync them but how on earth Game Cache is working for multiplayer?
You should be able to broadcast his player ID. Think of it this way:
(1) Register mouse click event
(2) Upon event fire, the trigger calls actions for the player who clicked it (locally).
(3) Get the local player player ID within "actions", and broadcast it through gamecache.
(4) Have a trigger on the side that periodically queries the value of that "playerID" gamecache entry (e.g. every 0.03125 seconds). If it changes value, then that means an event has fired. Then you can reset it to 0 so that future events can be queried.
That is a model for registering 1 event. For multiple mouse clicks and keyboard events, you would likely need to maintain a stack. I haven't extensively tested synching and its order, so there might be some other considerations, but I think it should work.
Still, I didn't test any of this. It is all just theoretical, so I could be wrong. Maybe I'll whip up a test/sample next weekend if I get my old lenovo running.
Perhaps you can use Nest's Network system but now it's too slow. I've also heard that you can use Game Cache to sync them but how on earth Game Cache is working for multiplayer?
Gamecaches work in multiplayer, they just don't save to your disk. Instead, they just save to a temporary cache. In multiplayer maps, you can use the gamecache natives to synchonize data between players. So if you have some "local" data, you just need to store it in a gamecache, use its sync function, and then wait for it to synchronize and read it back. This is great for us, but the only issue is that sync times can vary, and can be pretty long across BNet (depends on latency). With LAN, it is usually decent (0.1-0.3 seconds). Part of it is just because BNet is an old system. Blizz has far more servers now and an overall better system (BNet 2.0), which is why I wish they would change wc3 to use it. :3
What happen if you have different value in one variable saved into game cache? E.g mouse click event is fired. Then we get the player id and save it into cache, just pretend the triggering player is player 2 so played id is 1. Won't it be 1 is saved to player 2's game cache but 0 or even null is saved into other players' game cache? How can we sync those values?
Oh, and I forgot to mention, you can't play multiplayer using sharpcraft Once I tried to test my FSI through LAN but the room couldn't be detected. Then I tested using normal Wc3 and the LAN works perfectly and the room was detected.
What happen if you have different value in one variable saved into game cache? E.g mouse click event is fired. Then we get the player id and save it into cache, just pretend the triggering player is player 2 so played id is 1. Won't it be 1 is saved to player 2's game cache but 0 or even null is saved into other players' game cache? How can we sync those values?
That is what syncing is for. It takes a local packet of data in the gamecache and broadcasts it to everyone else. The engine keeps track of the local player, so it will retrieve the cache value for that player and then send it to all the other players. For a more in-depth explanation, you can read this: http://www.hiveworkshop.com/forums/...asy-way-sync-data-new-gethost-command-114475/
Oh, and I forgot to mention, you can't play multiplayer using sharpcraft Once I tried to test my FSI through LAN but the room couldn't be detected. Then I tested using normal Wc3 and the LAN works perfectly and the room was detected.
That is because it introduces new natives to the map's script. When you try to load a map within wc3/LAN/BNet, it will perform a quick syntax check before allowing you to edit the player slots. Since it doesn't have those natives listed in the common.j, the check will fail. You can circumvent this issue by importing a custom common.j (that includes your new natives) under Scripts\common.j (in your map).
You can also make your natives modify existing natives (or have them react to particular input), as I described above. With that method, you can have special features for those without SharpCraft, but it will still run fine for those who don't have it (as long as you code everything properly).
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
