|
|
PyDat |
|
|
Apr 21 2009, 09:50 PM Post
#1
|
|
First of all, wow what an awesome package and thanks for doing this! I've been playing around with the .dat editor and run into some problems. I'm trying to make a basic zerg tweak where I set drones to zero cost/supply and free hatcheries. I then save the mpq as a self-run exe, and open it up. I can't actually get into any of the campaigns first of all, (the menu for mission select comes up, but when i click a mission it just closes the mission select window) and the second issue is that the game won't let me build hatcheries on the creep post-change. Any help would be great on this!
|
|
|
|
|
Apr 22 2009, 11:07 AM Post
#2
|
Thanks, I'm glad you like it  For the first problem, I'm 90% sure its not a PyDAT problem. Are you using No-CD by copying the CD's Install.exe's to your SC folder and renaming them to Starcraft.mpq and Broodwar.mpq? I believe this happened to me when I tried to play the vanilla campaign with the No-CD stuff, but the only way to do it was remove Broodwar.mpq from the StarCraft folder. I think SC gets confused about which game you are trying to play if you have both mpq's in the SC folder, and it cant load the vanilla campaign because its looking in Broodwar.mpq instead of Starcraft.mpq. The second problem could be caused by a problem in PyDAT, or just be a result of something you changed in your dat file. What did you edit in the dat file exactly? And could you attach the dat file in question so I can have a look? Thanks for the report!
|
|
|
|
|
Apr 22 2009, 11:42 AM Post
#3
|
Many years ago, I extracted all of the Vanilla Campaign files and put them on my install.exe (Before broodwar.mpq + .iso) I did this so I could play the Vanilla Campaign any time I wanted. I never did of course, but at least I could if I wanted. This has come up recently in our BlizzHard topic as well. You might have to extract/add files in bunches tho. Sometimes WinMPQ goes haywire if you try to add HUGE amounts of large files such as that of the Vanilla campaign directory.  This setup has worked for me for years tho. Oh.. and you'll also need the cinematic .smks too.
|
|
|
|
|
Apr 22 2009, 12:05 PM Post
#4
|
|
No I just got the best buy battle chest version and re-installed it, which it forced me to install broodwar and sc together, immediately following I patched it with the latest version. All I'm doing is opening pydat, changing the cost of drone/scv/probe to be no supply cost or mineral cost, saving it as an exempq, then running the game. The single-player skirmishes work in the original sc, but not the campaign, in brood war I can do everything. So what is the primary issue? That sc is getting confused on which mpq? I'm a new to modding so you will have to excuse me for not being able to provide you with a lot of technical data.
|
|
|
|
|
Apr 22 2009, 12:16 PM Post
#5
|
|
Sorry, I was the one that was being confusing. The single player Vanilla campaigns won't work for you with your BroodWar CD. You would need to put your Vanilla CD in the drive for this or copy the campaign files from the Vanilla Cd to the Broodwar "cd" i.e. install.exe, which is now broodwar.mpq if you are following the no-cd method Blizzard implemented for 1.15.2 and above.
There is a way to play Vanilla SCraft without the CD I imagine as well by renaming Vanilla install.exe to starcraft.mpq. Poiuy must have been referring to this as far as the mpq's getting mixed up. Either put your Vanilla CD in the drive for Vanilla Campaigns or copy the campaign directory to your Broodwar.mpq.
But maybe you're not even wishing to play the vanilla Campaigns? Sound like that's your only issue?
|
|
|
|
|
Apr 22 2009, 12:31 PM Post
#6
|
|
Yea the issue about the hatchery had to do with cost, If I set the cost to zero it wouldn't allow me to build on creep, but if it was 25 minerals it would. I also can't seem to be able to make protoss zealots free because then the game says they need an infinite amount of gas afterwards, but it isn't a big issue. Thanks for the help Ill try the cd swap.
|
|
|
|
|
Apr 22 2009, 01:44 PM Post
#7
|
|
Hmm, the cd in the drive did not fix the issue, I still can't play the original campaign with the modded exe.
|
|
|
|
|
Apr 23 2009, 11:59 AM Post
#8
|
|
Yea, I've had the same problem here. But the thing is I can play the vanilla campaigns normally by coping the cd file and renaming it starcraft mpq just not with any of the modded exe
|
|
|
|
|
May 14 2009, 10:05 PM Post
#9
|
Working with sfxdata.dat. This seems like as good a place as any to discuss the following: I'm trying to have certain error sounds to be shared by all 3 races, but labeling for some of the entries in datedit and pydat is really wacky for the non-unit sounds like advisors and errors/announcements? For instance the supply limit max error. It appears to be buzz.wav, perror.wav, and zdrerr00.wav for TPZ respectively. However in sfxdata.dat, there are several of the same entries. 1,2,3 and 139,140,141? The sound preview button (red arrow) is really a nice feature with Pydat!  However similar to Firegraft's unit action/requirement strings, the entries are indexed one off because of the null "0" entry and thus don't correspond with sfx.tbl. With Firegraft, you always have to add one value for the string id or subtract one depending on whether you are working with the program or stat_txt.tbl. Same with this sound preview, you are actually previewing the following (+1) sound entry. Then there are other labels that have parenthesis? like 123 and 124, 137 and 138, 146 and 147 etc. Then entries like 131 and 132 are really bizarre. Anywhoo... IF/when I decipher which labels correspond to a few of these hard to locate sounds I'll document them here. Really, only locating which label corresponds to the supply limit error is giving me the most trouble.
|
|
|
|
|
May 14 2009, 11:50 PM Post
#10
|
The list of sfxdata entries is the same as from DatEdit (since thats where i got it from), and they are just labeled by the "Sound File" they pointed to in the original dats. The entries with duplicate labels use the same sound file, they just have different settings for the unknowns (Heinermann explained some of the unknowns in thread). Some of the duplicates have (#) or [#] to indicate which one they are (since this list was made by hand, by BK im guessing, it looks like there are some minor inconsistencies and errors). The newest version of PyMS (1.2.0 with PyDAT 1.10) plays the correct sound, you probably need to upgrade. Thanks!
|
|
|
|
|
May 15 2009, 12:01 AM Post
#11
|
My bad. User error! The first entries 1,2,3 are the supply limit error/announcement as noted. I had archived zerg/drone/zdrerr00.wav wrong and was getting false reports throwing everything off. Entries 139-141 are something else. I hijacked one sound for all 3 error messages and left 139-141 default for now. I am hoping to discover what 139-141 actually correspond to in game. I'll check out the link to Heinermann's thread first. Thnx. QUOTE(poiuy_qwert @ May 14 2009, 11:50 PM)  The newest version of PyMS (1.2.0 with PyDAT 1.10) plays the correct sound, you probably need to upgrade. Ahh.. yes. I have 1.9. I've been meaning to update. dl'ing now Sorry.
|
|
|
|
|
Nov 22 2009, 01:15 PM Post
#12
|
|
This is more of a modding question, but you'd probably know better than anyone else:
I'm using the function 6 for the drawing properties (images.dat) for 2 particular units (Scout and Interceptor) and the effects are just what I'm looking for. cloaked but still visible. My question is, how stable is this function? And do you have any idea what this function actually does?
Also, the function window is a bit small and thus some of these labels are getting truncated. Looks like there's a bit more room to elongate this window?
Nice program.
|
|
|
|
|
Nov 22 2009, 01:42 PM Post
#13
|
|
I don't really know anything about those functions, sorry. Your best bet for finding out is probably Heinermann.
Which window/labels? Things should expand/contract when resizing the main window, maybe you just made it too small?
|
|
|
|
|
Nov 22 2009, 08:53 PM Post
#14
|
|
Well it "seems" to be stable. I'll have to report back.
@ window Sorry, don't have any SCraft tools on this comp. the function window in images tab where you choose what type of palette etc. 0= no remapping, 9= remap etc. Some of the options aren't very readable. It's nothing that important just aesthetics.
|
|
|
|
|
Nov 25 2009, 08:30 PM Post
#15
|
Units.dat > basic tab> Space > Required field the tool tip reads: QUOTE Amount of loading space the unit takes up in a transport. If it is higher than the transport's loading space, the unit cannot be loaded. It DOES NOT resize the unit's wireframe when inside the transport. This should include a warning that transport wire frames need to match this unit size or game may crash when unloading unit. I had experienced such a crash with ARAI, and it has reappeared in PEAI. For unit sizes of 1, it appears the total size of frame (red in pyGRP) needs to be contained in a 32x32 area. I had a stray pixel on my tank wireframe in which the unit was reduced to a "1" transport space unit. This single stray pixel caused mod to crash. Just something to help future modders avoid this mistake. This crash is a hard one to spot, because it doesn't always happen for whatever reason. When it does fail however, you will (or may not at times) see traces of the wirefram still remain on board transport long after unit has been unloaded as seen in this pic:  This info is going in our wiki under known modding game crashers when we get it back up here soon.
|
|
|
|
|
Nov 26 2009, 09:48 AM Post
#16
|
QUOTE This should include a warning that transport wire frames need to match this unit size or game may crash when unloading unit. I had experienced such a crash with ARAI, and it has reappeared in PEAI. For unit sizes of 1, it appears the total size of frame (red in pyGRP) needs to be contained in a 32x32 area. I had a stray pixel on my tank wireframe in which the unit was reduced to a "1" transport space unit. This single stray pixel caused mod to crash. Does that happen when the AI unloads units?
|
|
|
|
|
Nov 26 2009, 10:05 PM Post
#17
|
|
@ computers: If you watch a replay and click on a transport, then yes. The replay that experienced this crash seemed to also crash at that same time without clicking on the transport. This would be an easy test to confirm as I still have the old .exe + replay. I'll have to get back on this. I would think that the wireframes wouldn't matter at all with the AI tho.
|
|
|
|
|
Nov 26 2009, 10:51 PM Post
#18
|
|
Okay. Just making sure - all of the AO units have 1 space, even turrets and stuff that originally never could be transported. But AO transports them all the time and it doesn't crash.
|
|
|
|
|
Feb 4 2010, 10:20 AM Post
#19
|
|
Not a bug, but a question:
I notice that in DatEdit, you can't set the value for provided supply above 127? (basic tab on units.dat) And yet with PyDat you can. Is this a bug with DatEdit or is there anything to this? Just wondering as I'm now using PyDat to adjust some values.
Also, I'm really enjoying the "string id" associated with most strings in PyDat. Something that really annoys me about DatEdit as does IceCC and not having Iscript ID's. At least Firegraft got it right... sort of. You still have to subtract one or add one from the string ID depending on whether you're looking up a string in stat_txt.tbl or associating one in Firegraft.
|
|
|
|
|
Feb 5 2010, 10:26 AM Post
#20
|
QUOTE(bajadulce @ Feb 4 2010, 10:20 AM)  I notice that in DatEdit, you can't set the value for provided supply above 127? (basic tab on units.dat) And yet with PyDat you can. Is this a bug with DatEdit or is there anything to this? Just wondering as I'm now using PyDat to adjust some values. Update: You can certainly save with values larger than 127 with PyDat, but when you reopen the file, it will show 22 which is the value DatEdit usually displays when you try to enter a number higher than 127. So must have to do with bits. Might want to make a note or amends for this in program.
|
|
|
|
|
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:
|
|