| 12-30-2007, 03:29 AM | #1 |
I will just quickly introduce myself, seeing as you will most likely be a very busy man. I am a JASS programmer and am currently developing an AMHS (anti map hack system) which is going to be implemented in many popular maps, including DotA. In the latest release ( v4.40) there has only been a few issues which I cannot get around with JASS being as limited as it is. What I basically require is a corrupted model, I have one already on my hands however it was obviously made in a hurry and I don't have the modelling skills required to edit the model to my specifications (even using your fantastic model editor). The corrupted model is attached as modelcrash.mdx.The model crashes at the specific interval at 350 which is played with the death animation. Although i was able to easily swith the animations around, I cannot make the crashing happen instantly without more issues (I can have the crash happen instantly however another even weirder problem arises where if you drag select an area where the effect is played, and that area cannot be seen it will crash the player) What I need the corrupted model to do is to crash instantly after an animation is played, not 0.233 seconds as it is now. Basically this is what the corrupted model needs to do - Have a death animation that when played will corrupted wc3 instantly NOTE: Whatever you do, DO NOT play the Death animation of the attached model in wc3modeleditor, it will cause it to hang and on some computers require force restart. I am not sure who created the corrupted model nor how it crashes wc3, but so far again hackers its doing its job. I am also attaching a test map which you can tell if the corrupted model works properly. Basically the corrupted model is spawned at the tree (green spot on the minimap). If the corrupted model works correctly, it should never crash when you play normally however when you do the iseedeadpeople cheat (or use a MH) it will crash assuming your current screen view is on the tree and it is not revealed by the bloodmage. Your help will be very much appreciated, and you will be added into the credits for AMHS if you manage to produce the model that I recquire (and you will be given rep )Attached Files - modelcrash.mdx (the model that crashes at interval 350 with the death animation) - modelcrash2.mdx (an edited version of modelcrash.mdx, the crash happens instantly at the birth animation HOWEVER it has the problem where if you drag select a not visisble area where the special effect is created it crashes the player) - test.w3x (this is my test map to see if the corrupted model works as intended, just import the corrupted model with the path war3mapImported\modelcrash.mdx) AMHS download http://www.wc3campaigns.net/showthread.php?t=97922 |
| 12-30-2007, 06:29 AM | #2 |
ok, Let me see if I get you. You want the model to crash instantly when playing Birth animation, right? and you want that for the death animation it takes some time, renove the model but does not cause a crash? ok, Yet I still don't get how's the crash being caused. until now it looks like it has some relation to the global sequence. But i still ask myself the blizz's parts purpose. Edit: the particle emitters looks to be the crashing element, until now. Obs 1: no matter what you change, it's impossible to avoid the crash. Hypothesis 1: If we make the same effect on a particle emitter 1 or we link both models using it then we will cause an error that avoids this problem. |
| 12-30-2007, 06:59 AM | #3 |
Any help would be greatly appreciated, like you I also have no idea how the crashing occurs Remember modelcrash2.mdx works perfectly as intended except for that fact that now it crashes when you select an area where the model has been spawned (even if you do not see the area). The changes made from the original to v2 are changed death animation to birth animation changes stand animation to death animation changed global sequence duration to 1 changed sequence of the "new" death animation (the one that crashes) from 333-1000 to 350-350 (animation occurs at 350) If you can fix the mentioned problem then everything is perfect as intended |
| 12-30-2007, 07:13 AM | #4 |
I'll try using ribbon emitters and particle emitters 1. I think global sequences may also cause an error, but you may have 1 frame as a dead time. also, as i mentioned in my edit, that's unfixable. BTW, why is it needed that the model crash instantly? |
| 12-30-2007, 07:50 AM | #5 |
Look at the test map and you will find out why |
| 12-30-2007, 07:56 AM | #6 |
the timer takes 0.01 seconds, if you get 1 frame dead, only 1/960 = 0.00104 seconds. guess that with 1 frame is enough, just make the model crash 1 frame after the animation starts. |
| 12-30-2007, 08:04 AM | #7 | |
yep 1 frame is more then enough to be considered instant, also consider this from wc3modeleditor Quote:
|
| 12-30-2007, 08:06 AM | #8 |
hmm, it won't work, I tested it alrdy. the only thing left is to make a ribbon emitter crash. |
| 12-30-2007, 08:15 AM | #9 | |
What is the exact reason that you cant change modelcrash2.mdx to get rid of that drag-select bug. It obviously happened when i changed the frame duration of the sequence from 233 to 1 and the birth animation from 333-1000 to 350-350, but why is that creating the problem? EDIT: I actually remember hearing somewhere that its a particle causing the crash, im not 100% sure though EDIT2: From this thread http://www.wc3campaigns.net/showthread.php?t=84979 Quote:
|
| 12-30-2007, 09:01 AM | #10 |
he got no team colored particles, the model crashes because he uses dontinterp in emession rate, which isn't wc3 legal. But we can't use that one anymore because particle emession takes more than the require time to start. I tried using geosetAnims error, but it looks like it crashes the game when the model is created. the second common bug, looks like it has been fixed, because the min & max extents r as it's said there. And the third one may be possible, if the model starts emulating particles from the start. EDIT: the third one also crashed the game when created. |
| 12-30-2007, 09:56 AM | #11 | |
Quote:
They do? Like I said, the 2nd version works fully as intended except for that bug (selecting the model when spawned as a special effect causes it to crash). In the test map, put in modelcrash2.mdx and test it out. You will find, as long as you dont do select + drag the corrupted model works perfectly as intended which means that the emission rate does start fast enough. Its only when you do the select + drag in the area where the tree is that it crashes |
| 12-30-2007, 05:10 PM | #12 |
As I said before, that bug is impossible to fix. The only thing that you could do is to create another model over it that blocks selection of the first one, but I doubt that it may work. |
| 12-30-2007, 10:57 PM | #13 |
Cant you just recreate the corrupted model with the emmision rate as the method of corrupting and have it go over a few frames. If one frame is 0.00104 seconds then it can even take 9 frames to load up in order to be considered fast enough EDIT2: I finally understand what your saying now, and I fixed that bug. When you have a look at the emmisions for the particle, its not the dontinterp that causes the crash, its this line that makes the crash 350: 1e+018 i.e. Code:
0: 0 333: 0 350: 1e+018 1000: 0 It seems that value is causing the model to crash. When doing some adjustments however, like changing it to this and changing the sequence as well Code:
0: 0 349: 0 350: 1e+018 351: 0 The crash never happened, it seems that the emissions must take (as you mentioned) must take 667 frames for the crash (which is around 0.7 and not 0.2-0.3 seconds). It seems we have to come up with some other crashing method (there are plenty out there) EDIT 3: The only other slightly succesful animation I have come up with is removing a geoset however leaving the geoset animation behind and creating a bone for the particle emmitor that points to that geoset animation. The problem is that this causes wc3 to crash even if you do not see the model (obviously it happens when wc3 is trying to render the model). Are you sure there is no way to speed up emmissions for particles? |
| 12-31-2007, 06:25 AM | #14 |
I tried that one already as I said before. There's no way to accelerate particle emession, yet we could try causing a different bug by animating texture ids. Let me try it out. |
| 12-31-2007, 09:06 AM | #15 |
SetUnitTimeScale(Corrupted_Unit, 20.00) wouldn't speed up the particle emission any? |
