Report, edit, etc...Posted by Lord_Agamemnon(MM) on 2006-08-29 at 15:50:08
Which feature is this that we're talking about removing? Reload tab or copy/paste tab? I never had problem with copy/paste.
Report, edit, etc...Posted by BroodKiller on 2006-08-29 at 16:25:59
The normal Copy/Paste works allright, the problem is with the Copy/Paste Tab feature, because after the layout was changed in v1.1, I forgot to change the list of "which property lie on which subtab".
And yes, we're speaking about all the tab-related funtions. Reload tab is not yet there, just FYI
And yes, we're speaking about all the tab-related funtions. Reload tab is not yet there, just FYI
Report, edit, etc...Posted by Kookster on 2006-08-31 at 05:25:12
I think i found something i wont say for sure until someone else confirms but in orders.dat when you check use weapon targeting it doesnt only use weapon targeting but it also used the weapon cooldown time.
and on a bad note brood sometimes when i try to save directly to the mpq it has an error it seems to happen when i have two datedits open at once or after i have had to datedits open at once the error message is:
"Cannot Create file C:\Program Files\DatEdit v1.1\temp\...then what ever dat i was trying to save"
and on a bad note brood sometimes when i try to save directly to the mpq it has an error it seems to happen when i have two datedits open at once or after i have had to datedits open at once the error message is:
"Cannot Create file C:\Program Files\DatEdit v1.1\temp\...then what ever dat i was trying to save"
Report, edit, etc...Posted by Lord_Agamemnon(MM) on 2006-08-31 at 10:01:50
That might have to do with multiple programs using the same file, like how Windows doesn't let you delete/move something if it's in use.
Report, edit, etc...Posted by Killer_Kow(MM) on 2006-08-31 at 10:17:20
Hmm... I think I've found something strange.
All air units and buildings with the flight ability have the "0x80 (Mine-safe)" flag checked. Now I thought, prehaps if I uncheck this flag, there might be some sort of effect it creates (or maybe a crash). So I tried it. I got no effect. This leads me to believe that there could possibly be a second purpose for this flag...
Just something I thought I'd let you know
All air units and buildings with the flight ability have the "0x80 (Mine-safe)" flag checked. Now I thought, prehaps if I uncheck this flag, there might be some sort of effect it creates (or maybe a crash). So I tried it. I got no effect. This leads me to believe that there could possibly be a second purpose for this flag...
Just something I thought I'd let you know
Report, edit, etc...Posted by BroodKiller on 2006-08-31 at 17:53:39
They have this flag set, so that they don't activate mines, obviously 
Check if they do after unchecking, what would mean that the "Flyer" advanced flag is also of importance here.
ADDITION:
And as for your problem, kookster - don't do this. DatEd exports the MPQ content it can deal with into a fixed temporary directory, and deletes the files on termination. So, if you have two DatEds from the same directory running, then one would delete files of the other one on termination, which is what causes the problem. On a side note, thanks for pointing this out, I'll fix it for 1.2b
Check if they do after unchecking, what would mean that the "Flyer" advanced flag is also of importance here.ADDITION:
And as for your problem, kookster - don't do this. DatEd exports the MPQ content it can deal with into a fixed temporary directory, and deletes the files on termination. So, if you have two DatEds from the same directory running, then one would delete files of the other one on termination, which is what causes the problem. On a side note, thanks for pointing this out, I'll fix it for 1.2b
Report, edit, etc...Posted by Killer_Kow(MM) on 2006-08-31 at 18:01:40
QUOTE(Killer_Kow(MM) @ Aug 31 2006, 11:16 AM)
So I tried it. I got no effect.
[right][snapback]553911[/snapback][/right]
[right][snapback]553911[/snapback][/right]
Report, edit, etc...Posted by Kookster on 2006-08-31 at 18:03:35
thanks bk
Report, edit, etc...Posted by BroodKiller on 2006-08-31 at 18:15:49
KK, uncheck the 'flyer' flag for an originally-airborne unit, and see if it activates the mines then.
Report, edit, etc...Posted by Killer_Kow(MM) on 2006-08-31 at 18:28:31
That wasn't the point. The point was, if flyers don't need the mine-safe flag, why is it checked?
Report, edit, etc...Posted by Kookster on 2006-08-31 at 18:30:52
so mines you know vulture mines dont attack them tho it would be cool to have a air mine
Report, edit, etc...Posted by Lord_Agamemnon(MM) on 2006-08-31 at 22:33:53
Bug alert! When I try opening a file from the history or click "OK" in the "Custom tbl" tab, the program freezes. And then it doesn't delete the temp folder, which worries me...but not as much as bugs in DatEdit. I'm using 1.2.
EDIT: And once this happens, it keeps happening, and then it won't load ANY files, period, without crashing. Reinstalling it temporarily fixes the problem.
EDIT: It also happens with 1.1d. I think it's something with my files, since nothing happens with the default, and, when I tried putting my edited .dats in the default folder, it also froze when I click anything. I didn't use anything but datedit ( or tblpad for the .tbls) on them, so it must have done something weird with them...
EDIT: And once this happens, it keeps happening, and then it won't load ANY files, period, without crashing. Reinstalling it temporarily fixes the problem.
EDIT: It also happens with 1.1d. I think it's something with my files, since nothing happens with the default, and, when I tried putting my edited .dats in the default folder, it also froze when I click anything. I didn't use anything but datedit ( or tblpad for the .tbls) on them, so it must have done something weird with them...
Report, edit, etc...Posted by ShadowFlare on 2006-09-01 at 10:21:37
BTW, you shouldn't really need to have a "temp" folder to extract files to since the files could just be used straight from the mpq archives if you programmed it as such.
Report, edit, etc...Posted by BroodKiller on 2006-09-01 at 15:40:12
QUOTE(ShadowFlare @ Sep 1 2006, 04:21 PM)
BTW, you shouldn't really need to have a "temp" folder to extract files to since the files could just be used straight from the mpq archives if you programmed it as such.
[right][snapback]554215[/snapback][/right]
[right][snapback]554215[/snapback][/right]
The thing is that I didn't
. The file loading/parsing routine does not take as a parameter a data buffer to process, but it takes a file pathname which it opens and then processess. Having said that...I can actually think of a way to change it, since the very format-specific processing is activated only in one routine in the entire application, but I would need to overload/modify that routine anyways...gimme a sec,I need to think of it... 
Report, edit, etc...Posted by ShadowFlare on 2006-09-01 at 15:45:28
QUOTE(BroodKiller @ Sep 1 2006, 01:39 PM)
The thing is that I didn't . The file loading/parsing routine does not take as a parameter a data buffer to process, but it takes a file pathname which it opens and then processess. Having said that...I can actually think of a way to change it, since the very format-specific processing is activated only in one routine in the entire application, but I would need to overload/modify that routine anyways...gimme a sec,I need to think of it...
[right][snapback]554306[/snapback][/right]
. The file loading/parsing routine does not take as a parameter a data buffer to process, but it takes a file pathname which it opens and then processess. Having said that...I can actually think of a way to change it, since the very format-specific processing is activated only in one routine in the entire application, but I would need to overload/modify that routine anyways...gimme a sec,I need to think of it... [right][snapback]554306[/snapback][/right]
Hmm, if you are going to be changing any of it, keep in mind while doing it that SFileOpenFileEx can open files on the hard drive, not just files in mpq archives.
Report, edit, etc...Posted by BroodKiller on 2006-09-01 at 15:49:48
Well, I think it doesn't really matter what function is used, if the point is only to get a pointer to the file content buffer, right?
LA>Hmm...sounds strange. Can you check your DATs for default file length? Damn, I should have really implemented this check right at the start...:/
LA>Hmm...sounds strange. Can you check your DATs for default file length? Damn, I should have really implemented this check right at the start...:/
Report, edit, etc...Posted by ShadowFlare on 2006-09-01 at 16:01:06
Well, here's a small sample of some code demonstrating opening files not in an mpq archive using SFileOpenFileEx:
Note that SFILE_SEARCH_ALL_OPEN makes it so that besides searching through open archives for the file it will also look on the hard drive at the location specified. More on this with the next example:
This example will attempt to open arr\units.dat from any open mpq archive, starting with the one having the highest priority, and if it doesn't find it in any of them, it will open C:\DatEdit\default\arr\units.dat if it exists.
CODE
BOOL bReturnValue;
MPQHANDLE hFile;
bReturnValue = SFileOpenFileEx(0, "C:\\folder\\somefile.dat", SFILE_SEARCH_ALL_OPEN, &hFile);
MPQHANDLE hFile;
bReturnValue = SFileOpenFileEx(0, "C:\\folder\\somefile.dat", SFILE_SEARCH_ALL_OPEN, &hFile);
Note that SFILE_SEARCH_ALL_OPEN makes it so that besides searching through open archives for the file it will also look on the hard drive at the location specified. More on this with the next example:
CODE
BOOL bReturnValue;
MPQHANDLE hFile;
SFileSetBasePath("C:\\DatEdit\\default");
bReturnValue = SFileOpenFileEx(0, "arr\\units.dat", SFILE_SEARCH_ALL_OPEN, &hFile);
MPQHANDLE hFile;
SFileSetBasePath("C:\\DatEdit\\default");
bReturnValue = SFileOpenFileEx(0, "arr\\units.dat", SFILE_SEARCH_ALL_OPEN, &hFile);
This example will attempt to open arr\units.dat from any open mpq archive, starting with the one having the highest priority, and if it doesn't find it in any of them, it will open C:\DatEdit\default\arr\units.dat if it exists.
Report, edit, etc...Posted by BroodKiller on 2006-09-01 at 18:33:30
It's a nice feature, but -to be perfectly honest- I prefer to maintain close and tight control over the program's execution and functioning. I code many things myself, which is an obvious waste of time, since similar things were done dozens of times before, but I want to know precisely what is hapenning in my program. Anyways, thanks for the other idea - I'll use it, since it offers a clean and neat solution to the problem kooks reported
Report, edit, etc...Posted by ShadowFlare on 2006-09-01 at 20:30:29
QUOTE(BroodKiller @ Sep 1 2006, 04:33 PM)
It's a nice feature, but -to be perfectly honest- I prefer to maintain close and tight control over the program's execution and functioning. I code many things myself, which is an obvious waste of time, since similar things were done dozens of times before, but I want to know precisely what is hapenning in my program. Anyways, thanks for the other idea - I'll use it, since it offers a clean and neat solution to the problem kooks reported
[right][snapback]554430[/snapback][/right]
[right][snapback]554430[/snapback][/right]
Hmm, so which things were you referring to with each of those statements? I'm not really sure which goes with what. lol
Report, edit, etc...Posted by BroodKiller on 2006-09-01 at 23:31:30
The other idea = changing the file parsing routine to take a data buffer as input instead of a filename.
Report, edit, etc...Posted by coolpotatoes on 2006-09-02 at 17:08:01
QUOTE(Lord_Agamemnon @ Aug 31 2006, 09:33 PM)
Bug alert! When I try opening a file from the history or click "OK" in the "Custom tbl" tab, the program freezes.
EDIT: It also happens with 1.1d.
EDIT: It also happens with 1.1d.
I have this same problem so its not your files Lord_Agamemnon. This bug really annoys me too, because i have to open files the slow way.
Report, edit, etc...Posted by BroodKiller on 2006-09-03 at 13:59:03
*Dispatched a repair team to fix the problem*
Report, edit, etc...Posted by BSTRhino on 2006-09-14 at 17:40:20
QUOTE(TheNomad @ Jul 29 2006, 10:38 PM)
I am sorry to disappoint you but it's not.
But if it will make you feel better, it's not my theory either. My theory was that "Flaots" is a pointer to a base owner (In a 3D world, any attached Actor would move relatively to the Base, like say a Weapon... the Player in a FPS game will movedynamically, but the weapon will always move relative to the Player's position since the Player is a base).
In this case, the slave actors would have been the shadows and engine effects...
Alas, I was wrong. What "FLOATS" does will AMAZE you.
It is actually responsible for cloaking. What I mean is, anything checked with "FLOATS" will be "visible" when cloaked.
A little explanation now...
To use my base example, any base owner has FLOATS checked and shadows unchecked. This means that when it is cloaked it will have the whirly effect, but it will STILL BE VISIBLE (well... as much as it can since it's cloaked
), but the shadow is gone. If you remove this flag on a base actor, then that actor will be COMPLETELY invisible and won't be drawn at all. What I mean is, there will be NO whirly thing and there will be NO DETECTION, meaning that even if you bring an observer, it will still not show up. Howto test if I'm right ? Enable it on a HT shadow (the blue echoed shadow thing) or on Scout Engines and be amazed that you see them even if the unit is cloaked.
Current name: Floats (?)
Suggested name: Don't hide if cloaked
Explanation: Will hide the unit from the map completely if unchecked (even by detectors), or will make it visible when cloaked
... don't ask how I found out what it does... let's just say I am a genius, you guys make me a statue and we'll move on from there
Come to think of it, what you said (about headers, iscript and death inits) is done by "USE FULL ISCRIPT" I think (but I am not sure).
Oh my... I am finding out so many unknowns... BK will hate me lol... (or envy me)
Note: this applies to units though... and I am not sure about burrowing, but if someone is willing to continue the research, I'll give him a cookie
[right][snapback]534105[/snapback][/right]
But if it will make you feel better, it's not my theory either. My theory was that "Flaots" is a pointer to a base owner (In a 3D world, any attached Actor would move relatively to the Base, like say a Weapon... the Player in a FPS game will movedynamically, but the weapon will always move relative to the Player's position since the Player is a base).
In this case, the slave actors would have been the shadows and engine effects...
Alas, I was wrong. What "FLOATS" does will AMAZE you.
It is actually responsible for cloaking. What I mean is, anything checked with "FLOATS" will be "visible" when cloaked.
A little explanation now...
To use my base example, any base owner has FLOATS checked and shadows unchecked. This means that when it is cloaked it will have the whirly effect, but it will STILL BE VISIBLE (well... as much as it can since it's cloaked
), but the shadow is gone. If you remove this flag on a base actor, then that actor will be COMPLETELY invisible and won't be drawn at all. What I mean is, there will be NO whirly thing and there will be NO DETECTION, meaning that even if you bring an observer, it will still not show up. Howto test if I'm right ? Enable it on a HT shadow (the blue echoed shadow thing) or on Scout Engines and be amazed that you see them even if the unit is cloaked.Current name: Floats (?)
Suggested name: Don't hide if cloaked
Explanation: Will hide the unit from the map completely if unchecked (even by detectors), or will make it visible when cloaked
... don't ask how I found out what it does... let's just say I am a genius, you guys make me a statue and we'll move on from there
Come to think of it, what you said (about headers, iscript and death inits) is done by "USE FULL ISCRIPT" I think (but I am not sure).
Oh my... I am finding out so many unknowns... BK will hate me lol... (or envy me
)Note: this applies to units though... and I am not sure about burrowing, but if someone is willing to continue the research, I'll give him a cookie
[right][snapback]534105[/snapback][/right]
I've been working on Ultimate Doom and I think there is a high chance this guy could be right. I can't find any other explanation as to why shadows disappear because we all know they use the followmaingraphic command, not the __2b or __2c command which I proposed as playfram-when-not-cloaked commands. What that could mean is that __2b and __2c have entirely different meanings, perhaps they've got nothing to do with cloaking at all. Maybe they've got something to do with a LO file. I'm convinced that TheNomad is right about what floats does. The testing that TheNomad has done does confirm it.
Perhaps the way he's written it has confused the meaning. It is true if you bring an observer the graphic won't be drawn on a cloaked unit that has this setting checked, just like the Wraith's engine graphics aren't drawn on the cloaked wraith, but you'll of course still be able to select the unit.
So I think he's right and I thought you should know.
Report, edit, etc...Posted by DiscipleOfAdun on 2006-09-14 at 18:41:55
Yes, that is 1 confirmed effect of that variable. However, I believe that there are a one or two other things that I believe it does(because of an exe search and how the variable is stored).
On those line, BST: I will try to find what __2b and __2c do. If they use an .lo* file for reference, I will be able to tell you which overlay it uses. I'll let you know any other things it does, and you can test visible effects to see if I was correct in my exe deciphering.
On those line, BST: I will try to find what __2b and __2c do. If they use an .lo* file for reference, I will be able to tell you which overlay it uses. I'll let you know any other things it does, and you can test visible effects to see if I was correct in my exe deciphering.
Report, edit, etc...Posted by BroodKiller on 2006-09-16 at 12:15:18
DatEd's v1.2b fixup is ready. Will upload it shortly