Staredit Network

But at least allowing inputting the mpq as a parameter would be useful. This way DatEdit could be launched to open the current mpq that is open in WinMPQ by having DatEdit as one of the programs in WinMPQ's tools menu.

Ok, that's no problem.I can do drag'n'dropping for MPQs as well, 'tis but two more lines of code after I'm done with it.

I think I will abandon this option then, as drag'n'drop will do the job just fine, agreed?

At least support what I mentioned above for the reason I mentioned above.

Think we all will agree Broody
This is easier since you allow multiple instances... forcing DatEd to just one instance would mean file asoc is better than drag & drop imo.

My second suggestion, assuming drag & drop wouldn't work, would have been using command lines But it seems there won't be a need

Would it be OK if I PMed you a list with some stuff I think should be changed (I promise no newbie-friendly stuff or any crazy requests to restructure orders or whatever ) to make it sexier ?

I have a feeling that once version 2 will be out (it will eventually me thinks ), it'll have ALL unknowns fixed, all hints accurate and stuff perfectly done
ATM it is as close to perfection as ever and with the next version it will be even sweeter

... BTW, any chance you can fix the sound list ?

P.S. Unrelated to DatEd, as it's not a DatEd bug but occurs in DatEd as well, sometimes when I hover some files (not click, just hover) the respective program having the Open/Save dialog box exits (if course it's a crash, but I don't get any errors... similar to an END TASK request). I get this in DatEd mostly. The way it happens is as crazy as the bug itself. Let's say I change stuff in Units, Weapons, Images and Tech... if I load Units and Weapons, nothing happens f.e., but if I want to load a third custom dat, like Tech, it exits. If I start with Tech it doesn't crash but it will along the second or third load... If I repeat the thing but load Images as a third dat isntead of Tech it won't crash... SOMETIMES it won't that is... but it isn't filename related or anything... crazy I tell you... anyone know why or how to fix it ? It is getting annoying if I want to do any custom editing in DatEd and it keeps crashing Esepcially just by hovering...

Did it just now


Actually, this will make my job a lot easier since I wouldn't have to implement process searching and setting a mutex for the program with this option on. I can focus on the other functions instead

Command line already works and drag'n'drop will soon.


If you want,but I would rather if you post it here so that others too can opinion and discuss your propositions. DatEdit is not a fit-one-guy project, mind you


Lol...version 2.0...that's not going to happen, unless there is something really really important to put into the program, but I can't imagine any such thing, to be honest.


What's wrong with it?


Strange...anyone else have this?

ADDITION:
Got drag'n'drop working
Unless TheNomad (or someone else) comes up with something important, that'll be it for v1.4

I got two suggestions. My heart wont be broken if you dont do them. So no worries. And number 2 if anything is the one I want more.

1)Preview for grp files (no worries if you dont do this)
2)be able to play the sounds in the sounds tab, by like double clicking or something. (that would be very useful)

Ad.2) This has been proposed once before, but no other reason was raised in its favor than just the kicks of being able to play a sound file in DatEd. What use for it do you find, Kooks?

Ad.1)You mean, in the Images Editor, right? Again, what for?

I suggested it so that I know how, for example, each explosion sounds.

The problem in the sound list is that the index there and the index used by the game are not the same. For example, plysnd 370 in iscripts is actually 241 in DatEd, meaning that DatEd is 1 index behind...

As for "one-guy" stuff, sure, I don't mind, they were mostly trivial things which I don't think many will mind
I'll compile it tomorrow I think.

Remember, DatEdit only gives you what hex gives you. That's how this units.dat property works, and that's what I is presented to you in DatEd.

fact !

However, it might be either the tbl's fault, either a problem in sfxdata.txt
Maybe adding a dummy entry in the txt to compensate... when I'll compile that sexyness list tomorrow or monday I'll tell you where the sound list does a wrong turn

Well cause i could actaully go through the sounds easily and see what their index number is. And not have to find the name seperately.

But if your gonna do it save it for the next release!

DatEdit is one index behind because the index of 0 means "no sound". I think I am missing something about the picture because I cannot understand the problem. Explain it again, slowly and precisely

Err ignore what I wrote there... I must have been tired
This is what I wanted to say:

For this I will require a volunteer!
* sees IceCC stepping forth *

IceCC has this to say about the Marine and Infested CC IScripts:



OK, notice the index corresponding to the death sound
Now, lift-off...



As you can see, in the first example (Marine), DatEd is 1 index ahead and in the case of lift-off, it's one index behind.

Check out what DatEd says:

Hmm....strange. I'll look into it, certainly.

ADDITION:
Find:
I looked into some of the weapon behaviours and I think someone has to carefully and precisely look through each single of them, because they may be seriously mislabled. I looked into the "Persistant Explosion" behaviour, and the fact of the matter is - you guessed it - it doesn't have anyting to do with the explosion being persistant. The true effect this behaviour has is that is allows the weapon/spell to 'explode' over terrain. This is in opposite to the "Appear on Target" behaviour, which allows the weapon to 'explode' over units.dat targets only! Try to change it for Plague and see for yourselves - if it has "Persistant Explosion" (the working version of the relabel is "Appear on site") set, you can freely target ground and have the explosion normally. If you set it to "Appear on Target", it no longer can be cast over terrain, only over units.dat targets. An interesting effect happens if you set it to "Normal Hit" - the explosion happens over the Defiler, but the effects are normally aplied to the site you cast the spell on.

So, any volounteers to check this property?

EDIT:No, you can't make weapons attack terrain with this. I already tried

Dang you were getting me hopeful there.

did you also change Orders.dat "Use Weapon Targeting" ?

Persistant Explo isn't solely responsible for terrain attacks, you know
OK, I'll look into all of them this week and I'll send you my "sexy DatEd requirements" post after I finish them all and tell you what I find

I still need to find the criteria for having only the Psi Storm image work with the Psi Storm behavior... if anyone knows why, I'd appreciate the help and it'd speed up the research on weapons

Ill do some weapon research too just to double check for you guys.

OK, to be more precise: "I couldn't get it to work"

TheNomad>Thanks:) As I said, be very observative and do not be satisfied with the most apparent effects, as there can some more things involved here, okay? Btw, what was it that you said once about overlays being affected by the "Draw If Cloaked" property?

ADDITION:
Thanks Kooks - it's really appreciated

ADDITION:
Also, try to test the effects on as much different weapons and other properties' (e.g. Missile, Gfx) configurations as possible, okay? Thanks

Ill test the weapons affects in 3 different ways:
1)Using a spell to target the ground
2)Auto attack from the unit
3)and direct attack click

Is there any other way you want me to test them?

Well I gotta go to work, Ill start testing sometime when I get home in about 6 hours.

Well, I said that even if your unit is not rendered, overlays DO appear on the unit. That is because you'd have to remove the "Draw if cloaked" on overlays too (but then they wouldn't appear AT ALL).

"Draw if Cloaked" disabled is basically the same like removing the current unit sprite.

We're slowly getting "there" with DatEd
GJ and thanks for putting up with all of us Broody

Especially TheNomad, JK.

I just got home and started testing.



you mean it disappears until a new action is taken???

You know I had a simalar action happen when I checked the visable checkbox for sprite, it was for the zerg cocoon, I couldnt select it, but I could see it. Im still not certain why it did that.

ADDITION:
O I have a suggestion that would be helpful.
You know how you have the mulitiple mpq export. Could you do a multiple Save something, so you can choose which ones you want to save all at once instead of having to click on each tab then save.

I like to backup my files, that is why I would like this Please!

Don't say "jk", you're right But Broody saw I meant well with most of my crazy stuff, hehe... (I hope)



No, but the "end" command in IceCC deletes the current sprite (not the unit). It is a similar effect to unchecking this (because no image overlay is created in the first place)

Yeah thats what I meant, thats interesting.


But you had alot of good imput so I wouldnt say we put up with you, you have added alot, and have solved ALOT of unknowns!!!

You people are blind....and I mean it. How possibly could noone see the dramatic bug I now behold (and fix), that's beyond my comprehension...

EDIT:Go to any non-Units Editor and use the "Sort by Origin" viewing method. Notice anything?