Report, edit, etc...Posted by DiscipleOfAdun on 2006-08-04 at 10:52:17
[center]The 'It won't work' Checklist.[/center]
Since there has been a recent 'surge' in modding(yay!), I feel that this is needed to better help explain the different things needed before posting asking why something you did won't work. Here's both possible scenarios and what other modders need to help. Remember: The smallest things can cause a crash. Unless you have it on 'GOOD' authority that something doesn't cause the crash, don't overlook it.
My mod crashes when I start a game.
Okay, there's nothing fun about this. Chances are you've actually got a unit that is preplaced causing it to crash...but there's other things that will do this. Now, the thing is, you don't know what unit is crashing(unless you only edited only one). So, the following steps should help us figure things out:
First, try your mod with only 1 modified file(I know, major mods can't do this...but for now...), starting with units.dat. Work through your files trying to find what file is causing the crash. If you do find that it is a specific file, follow the directions for that file(or post if you can't remember)...
1. If you edited units.dat, create a list of every unit edited. Then, under each unit, place what was changed(within reason, please. Some changes never cause crashes). For example:
Terran Marine - HP: 80, Ground Weapon: Glave Wurm, Sight: 12, Properties: Perm Cloak, Robotic, Detector, remove Organic. Movement: minesafe, Graphics: Probe.
2. If you edited weapons.dat, do the same.
3. If any other dat files were edited, make notes telling us these were edited. Most likely, make sure to include images.dat changes.
4. If you did any Iscript editing, please tell us. Make sure to tell us which editor(Ice or IceCC). Here's what to do for each:
a. Ice: Put down the animations edited, and what you did to each.
b. IceCC: Post(in code blocks) your scripts that were edited. Many modders can readily spot problems with IceCC scripts just by looking at them.
5. Any other major edits should also be mentioned.
If you can't remember all the changes, or don't want to type them up, just put what units/weapons were edited, and then post your files. It might take longer, but that's just as good an option.
Now, if all I did was units.dat, and I put up that marine example, I would instantly be told: "Units cannot have sight ranges over 11. Your crash is caused by the sight range. The other changes should all be fine". Now, if you can narrow down the unit list, that'd be really good. But, if not, try to limit the size of your post by only putting down what is most likely to cause it. If It was me asking for help, I'd only put down the sight, the properties, and the graphics...the other ones aren't as important.
"Unit" is causing a crash.
So, you've know what unit is causing the crash...but you don't know why? Simply follow the same steps for unknown crashes, except only for changes on that one unit. Meaning, try the above method, but only report on that one unit. Also, here's some things to look out for:
Problem: I change the grp file, now it crashes.
Solution: Either the iscript, an .lo? file, or both is causing you problems. If this is your problem, chances are you need to learn to edit the iscript.
Problem: I added a weapon to a unit, but it crashes.
Answer: Oh, another Iscript problem. Well, this solution is for both units that don't have any weapons, or don't have an air weapon. Check out this thread. The answer you are looking for is the 3rd one.
Problem: I know this should work: I edited my building and its iscript. It works fine until I start to heavily damage it, then it crashes. WTF?!?!?
Answer: Calm down. You missed something. When a building is damaged, it reads an .lof file for placing overlays(like fire or blood). Either edit the file, or remove the reference in images.dat.
Problem: I want my unit to act like a peon, but it crashes when it goes to gather minerals/gas.
Answer: Another .lo? problem. Don't these pop up everywhere? My suggestion, try the drone's .loo file(overlay 3 in DatEdit). It has the most frames. If that doesn't work, either learn how .lo? files work, or change your unit.
I've got a random crash. I don't know why.
Okay, these are the hardest to solve. Try to make a basic list of what units were edited, then post your MPQ. If you can, try to find a way to 'unrandomize' the crash. Even if you don't know what is causing it, if you can repeat it, then we can. Other modders might see something you missed out on.
So, those are what I can think of. Most that info isn't important to the crashing, but it could be depending on the change. If you don't put down enough to let us 'see' what is going on, your problem won't be solved. Maybe later I'll put up some explanations of the .lo? files, since I know they cause a lot of crashes.
Since there has been a recent 'surge' in modding(yay!), I feel that this is needed to better help explain the different things needed before posting asking why something you did won't work. Here's both possible scenarios and what other modders need to help. Remember: The smallest things can cause a crash. Unless you have it on 'GOOD' authority that something doesn't cause the crash, don't overlook it.
My mod crashes when I start a game.
Okay, there's nothing fun about this. Chances are you've actually got a unit that is preplaced causing it to crash...but there's other things that will do this. Now, the thing is, you don't know what unit is crashing(unless you only edited only one). So, the following steps should help us figure things out:
First, try your mod with only 1 modified file(I know, major mods can't do this...but for now...), starting with units.dat. Work through your files trying to find what file is causing the crash. If you do find that it is a specific file, follow the directions for that file(or post if you can't remember)...
1. If you edited units.dat, create a list of every unit edited. Then, under each unit, place what was changed(within reason, please. Some changes never cause crashes). For example:
Terran Marine - HP: 80, Ground Weapon: Glave Wurm, Sight: 12, Properties: Perm Cloak, Robotic, Detector, remove Organic. Movement: minesafe, Graphics: Probe.
2. If you edited weapons.dat, do the same.
3. If any other dat files were edited, make notes telling us these were edited. Most likely, make sure to include images.dat changes.
4. If you did any Iscript editing, please tell us. Make sure to tell us which editor(Ice or IceCC). Here's what to do for each:
a. Ice: Put down the animations edited, and what you did to each.
b. IceCC: Post(in code blocks) your scripts that were edited. Many modders can readily spot problems with IceCC scripts just by looking at them.
5. Any other major edits should also be mentioned.
If you can't remember all the changes, or don't want to type them up, just put what units/weapons were edited, and then post your files. It might take longer, but that's just as good an option.
Now, if all I did was units.dat, and I put up that marine example, I would instantly be told: "Units cannot have sight ranges over 11. Your crash is caused by the sight range. The other changes should all be fine". Now, if you can narrow down the unit list, that'd be really good. But, if not, try to limit the size of your post by only putting down what is most likely to cause it. If It was me asking for help, I'd only put down the sight, the properties, and the graphics...the other ones aren't as important.
"Unit" is causing a crash.
So, you've know what unit is causing the crash...but you don't know why? Simply follow the same steps for unknown crashes, except only for changes on that one unit. Meaning, try the above method, but only report on that one unit. Also, here's some things to look out for:
Problem: I change the grp file, now it crashes.
Solution: Either the iscript, an .lo? file, or both is causing you problems. If this is your problem, chances are you need to learn to edit the iscript.
Problem: I added a weapon to a unit, but it crashes.
Answer: Oh, another Iscript problem. Well, this solution is for both units that don't have any weapons, or don't have an air weapon. Check out this thread. The answer you are looking for is the 3rd one.
Problem: I know this should work: I edited my building and its iscript. It works fine until I start to heavily damage it, then it crashes. WTF?!?!?
Answer: Calm down. You missed something. When a building is damaged, it reads an .lof file for placing overlays(like fire or blood). Either edit the file, or remove the reference in images.dat.
Problem: I want my unit to act like a peon, but it crashes when it goes to gather minerals/gas.
Answer: Another .lo? problem. Don't these pop up everywhere? My suggestion, try the drone's .loo file(overlay 3 in DatEdit). It has the most frames. If that doesn't work, either learn how .lo? files work, or change your unit.
I've got a random crash. I don't know why.
Okay, these are the hardest to solve. Try to make a basic list of what units were edited, then post your MPQ. If you can, try to find a way to 'unrandomize' the crash. Even if you don't know what is causing it, if you can repeat it, then we can. Other modders might see something you missed out on.
So, those are what I can think of. Most that info isn't important to the crashing, but it could be depending on the change. If you don't put down enough to let us 'see' what is going on, your problem won't be solved. Maybe later I'll put up some explanations of the .lo? files, since I know they cause a lot of crashes.
Report, edit, etc...Posted by Lord_Agamemnon(MM) on 2006-08-04 at 11:04:53
Somehow I get the feeling that this is partially aimed at me. 
Will remember to post MPQs in the future when stuff crashes and I don't know why.
Will remember to post MPQs in the future when stuff crashes and I don't know why.Report, edit, etc...Posted by DiscipleOfAdun on 2006-08-04 at 11:47:28
No it wasn't. If you are really curious, I started typing this up before you made your thread. This is meant as a guideline for modders who have crashes and would like them solved, nothing more. The fact that you posted while I was making this is pure coincidence.
An additional note:
To those of you who what to make large modding project:
Some tips to help you:
1. Organize on paper what you are doing first. Write out the tech tree so you know what it is. Record what slots you use for what units/weapons(along with the fling->sprite->images->Iscript id's). If you make new grp's, write down what each frame set is meant to be. This greatly helps if you have to come back to a project. Plus, you can also get an idea of what is what before starting.
2. Balance as you go. Balancing is a major issue for some mods. There's no set formula for it. Here's some tips given taught to me by Hercanic, creator of Starcraft: Team Fortress.(I hope he doesn't mind me sharing these...)
a. Make sure everything has a counter. Don't make unstoppable units. But, there's more to this than just rock<paper<scissors, that's not a good way to counter. Try different combinations to make counters. Herc actually showed me a 5 way balance relationship when teaching this. I don't have it with me, but basically, each unit had 2 counters, and there were five units. Make up whatever you want when creating counters. Use the next tip to make your counters.
b. Don't set in stone the properties of your units. Herc's advice to me is to take general properties of units(like flyer, mid-damage, splash, long range, melee, etc.) and find which ones balance each other. Then, assign them to my units. Then, towards the final stages of the mod can stats be tweaked. Certain properties counter other ones. Firebats are designed so that they counter other melee ground units. Goliaths are the anti-air unit. DT's are designed to counter infantry style units. Their properties help define those counter relationships.
c. Mods aren't magnets. Opposites don't attract. The biggest example I have is this: When I was asking him about this, I presented an idea for a mod(yes Voy, the same mod I told you about...) where one race had mass units, mainly flyers, and most were spellcasters. Herc pointed out to me that massing spellcasters doesn't go hand in hand, unless the spells are self targeting. Those two aspects of the game are polar opposites. Also, flyers stack on top of each other easily. My ideas to a hard hit, but I have changed the basic idea to accommodate this principle. Other things, like low cost-high damage aren't good to combine. Sure, it sounds good, but think about balancing things first.
d. Make sure every unit has a point. One thing that each unit has to be is useful. Every original SC unit is useful, so why should you make non-important unit in your mod?
e. When balancing, don't forget about unit types. These are the basic kinds of units, like peons, melee ground, ranged ground, meatshields, spy, spellcaster, siege units, anti-air, anti-personnel, air fighters, capitol ships, suicide units, and so on(there's a lot). Make sure your balance has just the right amount. A race where there isn't a good anti-air unit is instantly weak against races that have a good air balance.
3. Test everything. If you have a large project, sometimes it can be overwhelming. You'll not be able to 'test as you go' for everything, but it's a good idea to try. That way, you can catch crashes as they come. If you are changing existing units, try doing them one-by-one, and run the game and check the unit before going on to the next one. You are more likely to isolate problems this way.
4. Don't be afraid to experiment. There's a few nifty effects that people wouldn't have figured out if they weren't pushing things to the limit. The iscript is a powerful tool if used right. Combined with some small orders.dat changes, there's a world of effects out there just waiting to be used. If it doesn't work they way you want the first time, change something.
5. Pay attention to spells. Each race's spellcasters have a balance of spells in and of themselves. Don't give overly strong spells to an early game low cost spellcaster...that's not right. The balance must be preserved. Spell balancing also includes research costs, and energy, in addition to the caster's stats, don't forget this.
6. Avoid superweapons if you can. Sure, some spells(nuke, yamato cannon, spawn broodlings, feedback) are ultra powerful, but they take a lot to use. A normal unit shouldn't be able to inflict that much damage unless you've got some very steep balancing, such as low hp, high cost, or the perfect balance: suicide(Yay infested terrans!)
Okay, that's some more help...I guess this is becoming less of a crash-guide to more an advanced modding theory...oh well.
just so you know, when I'm done with FG, I'll be looking for 3d artists and a couple of modders to help me with my mod, so just a heads up...
An additional note:
To those of you who what to make large modding project:
Some tips to help you:
1. Organize on paper what you are doing first. Write out the tech tree so you know what it is. Record what slots you use for what units/weapons(along with the fling->sprite->images->Iscript id's). If you make new grp's, write down what each frame set is meant to be. This greatly helps if you have to come back to a project. Plus, you can also get an idea of what is what before starting.
2. Balance as you go. Balancing is a major issue for some mods. There's no set formula for it. Here's some tips given taught to me by Hercanic, creator of Starcraft: Team Fortress.(I hope he doesn't mind me sharing these...)
a. Make sure everything has a counter. Don't make unstoppable units. But, there's more to this than just rock<paper<scissors, that's not a good way to counter. Try different combinations to make counters. Herc actually showed me a 5 way balance relationship when teaching this. I don't have it with me, but basically, each unit had 2 counters, and there were five units. Make up whatever you want when creating counters. Use the next tip to make your counters.
b. Don't set in stone the properties of your units. Herc's advice to me is to take general properties of units(like flyer, mid-damage, splash, long range, melee, etc.) and find which ones balance each other. Then, assign them to my units. Then, towards the final stages of the mod can stats be tweaked. Certain properties counter other ones. Firebats are designed so that they counter other melee ground units. Goliaths are the anti-air unit. DT's are designed to counter infantry style units. Their properties help define those counter relationships.
c. Mods aren't magnets. Opposites don't attract. The biggest example I have is this: When I was asking him about this, I presented an idea for a mod(yes Voy, the same mod I told you about...) where one race had mass units, mainly flyers, and most were spellcasters. Herc pointed out to me that massing spellcasters doesn't go hand in hand, unless the spells are self targeting. Those two aspects of the game are polar opposites. Also, flyers stack on top of each other easily. My ideas to a hard hit, but I have changed the basic idea to accommodate this principle. Other things, like low cost-high damage aren't good to combine. Sure, it sounds good, but think about balancing things first.
d. Make sure every unit has a point. One thing that each unit has to be is useful. Every original SC unit is useful, so why should you make non-important unit in your mod?
e. When balancing, don't forget about unit types. These are the basic kinds of units, like peons, melee ground, ranged ground, meatshields, spy, spellcaster, siege units, anti-air, anti-personnel, air fighters, capitol ships, suicide units, and so on(there's a lot). Make sure your balance has just the right amount. A race where there isn't a good anti-air unit is instantly weak against races that have a good air balance.
3. Test everything. If you have a large project, sometimes it can be overwhelming. You'll not be able to 'test as you go' for everything, but it's a good idea to try. That way, you can catch crashes as they come. If you are changing existing units, try doing them one-by-one, and run the game and check the unit before going on to the next one. You are more likely to isolate problems this way.
4. Don't be afraid to experiment. There's a few nifty effects that people wouldn't have figured out if they weren't pushing things to the limit. The iscript is a powerful tool if used right. Combined with some small orders.dat changes, there's a world of effects out there just waiting to be used. If it doesn't work they way you want the first time, change something.
5. Pay attention to spells. Each race's spellcasters have a balance of spells in and of themselves. Don't give overly strong spells to an early game low cost spellcaster...that's not right. The balance must be preserved. Spell balancing also includes research costs, and energy, in addition to the caster's stats, don't forget this.
6. Avoid superweapons if you can. Sure, some spells(nuke, yamato cannon, spawn broodlings, feedback) are ultra powerful, but they take a lot to use. A normal unit shouldn't be able to inflict that much damage unless you've got some very steep balancing, such as low hp, high cost, or the perfect balance: suicide(Yay infested terrans!)
Okay, that's some more help...I guess this is becoming less of a crash-guide to more an advanced modding theory...oh well.
just so you know, when I'm done with FG, I'll be looking for 3d artists and a couple of modders to help me with my mod, so just a heads up...
Report, edit, etc...Posted by SuperToast on 2006-08-04 at 14:26:48
Very nice post, I vote for this to get stickied.
Report, edit, etc...Posted by Voyager7456(MM) on 2006-08-04 at 15:17:13
Of course.
>>Pinned
>>Pinned
Report, edit, etc...Posted by nirvanajung on 2006-08-04 at 21:31:30
QUOTE
just so you know, when I'm done with FG, I'll be looking for 3d artists and a couple of modders to help me with my mod, so just a heads up...
if u wanna find 3d artists easily and quickly
i suggest hre http://boards.polycount.net/ubbthreads.php
this polycount website has been most major 3d artist community site which
turn a conversation to 3d art for Game Modding
Report, edit, etc...Posted by DT_Battlekruser on 2006-08-05 at 04:09:57
QUOTE
I've got a random crash. I don't know why.
Okay, these are the hardest to solve. Try to make a basic list of what units were edited, then post your MPQ. If you can, try to find a way to 'unrandomize' the crash. Even if you don't know what is causing it, if you can repeat it, then we can. Other modders might see something you missed out on.
So, those are what I can think of. Most that info isn't important to the crashing, but it could be depending on the change. If you don't put down enough to let us 'see' what is going on, your problem won't be solved. Maybe later I'll put up some explanations of the .lo? files, since I know they cause a lot of crashes.
Okay, these are the hardest to solve. Try to make a basic list of what units were edited, then post your MPQ. If you can, try to find a way to 'unrandomize' the crash. Even if you don't know what is causing it, if you can repeat it, then we can. Other modders might see something you missed out on.
So, those are what I can think of. Most that info isn't important to the crashing, but it could be depending on the change. If you don't put down enough to let us 'see' what is going on, your problem won't be solved. Maybe later I'll put up some explanations of the .lo? files, since I know they cause a lot of crashes.
You would want to be sure to be using an Expansion stat_txt.tbl. Otherwise when you mouse-scroll over the build button for any Expansion units, you get a crash.
Report, edit, etc...Posted by Killer_Kow(MM) on 2006-08-08 at 13:53:36
This will make it easier for everyone who helps in here 
Thanks.
Off topic: Lol, 33333rd topic!
Thanks.Off topic: Lol, 33333rd topic!
Report, edit, etc...Posted by DiscipleOfAdun on 2006-08-08 at 14:31:29
About *.lo? Files Part 1.
Q: What are *.lo? files?
A: LO? files are a specific type of file used in Starcraft. These files contain offsets which are read when certain over/underlays are created, either by the engine or by the Iscript.bin file.
Q. What do I use to edit them?
A. Use LoEdit, written by Shadowflare.
Q: Why are there so many different extensions?
A: Because each different extension is meant for a different kind of overlay.
Q: How do I tell what extension means what?
A: Well, there's no complete listing of what each file does. However, here's what I've got so far:
.lof - Fire overlays. These files are used when a building enters critical HP and starts to display flames or blood.
.lou - Up overlays. The offsets in this file determine placement of dust when a building lifts off.
.lod - Down overlays. Same as up, but for landing.
.lob - Birth overlay. Used to units with the 2 in 1 egg spawning option.
.loa - Attack overlay. Used by the bunker, this is where the firing animations are placed. Also used by siege mode siege tank.
.loo - Object overlay. Used by workers to place powerups when carried.
.los - Shield overlay. Used when placing shield hit graphics. LOS files also can stand for smoke overlay, in which case they are used for the vespene gas poofs
.log, .lol, .lox - these don't really have a true name to place. Some are attack overlay offsets, some are for spells, and some are for engine overlays, and then there's some more effects they have. Basically, these are used most by the Iscript, while the above ones(except for .loa) are used by the engine.
Q. So, what's so special about these files?
A. Well, .lo? files contribute to most Iscript related crashes. Also, you can make things look rather interesting this way. One easy effect is to edit an .lof file and make both blue and orange flame appear.
.lof files have 22 offsets per frame, each corresponding to a different Image.dat entry, starting at entry 450. 0,0 on an offset is the center of the unit(see units.dat graphics tab in DatEdit for how units are sized graphically). If 127,127 is put in, the offset is ignored(meaning the flame doesn't show up).
Well, I'm done for now. I'll add more about the different lo? files(mainly, what image Id each starts at and how many offsets per frame.) I might also put up some help on using LoEdit if I manage to type it up.
Report, edit, etc...Posted by TERRAINFIGHTER on 2006-08-08 at 17:12:22
Or if you want to read something shorter, you can read what I wrote a while back
also, LO* files have 17 entries per-frame just like in the grp's, not 22
QUOTE
LO* files - LO* files are used for telling each frame where the graphic is placed,
don't pay attention to their extensions, the LO* files use differant extensions
so blizzard could give a group of LO* files for the same unit the same name,
even though they're the exact same format and have the same use.
don't pay attention to their extensions, the LO* files use differant extensions
so blizzard could give a group of LO* files for the same unit the same name,
even though they're the exact same format and have the same use.
also, LO* files have 17 entries per-frame just like in the grp's, not 22
Report, edit, etc...Posted by CommmanderMoo19 on 2006-08-11 at 16:50:49
expansion set????where can you get that
Report, edit, etc...Posted by Killer_Kow(MM) on 2006-08-11 at 17:02:23
Seriously, what are you talking about?
Report, edit, etc...Posted by TERRAINFIGHTER on 2006-08-11 at 18:14:44
QUOTE(CommmanderMoo19 @ Aug 11 2006, 03:50 PM)
expansion set????where can you get that
[right][snapback]543502[/snapback][/right]
[right][snapback]543502[/snapback][/right]
expansion set = Brood War, but for some reason people prefer to say it.
Report, edit, etc...Posted by Lord_Agamemnon(MM) on 2006-08-11 at 21:58:33
Disciple: I've got another problem that people--especially me--can fall victim to quite easily for you to put in the big list of "Unit makes game crash:" Button number exceeds actual number of buttons. That is, the number of buttons in the "Unit" tab of Memgraft > the number of buttons in the unit's actual command list.
Report, edit, etc...Posted by Pyro-Fire on 2006-08-13 at 01:06:34
Yay, finally someone had the guts to make an attempt to stop people from spamming up on "OMG MY MOD DUN WURK SEN YUO BR0KE MAH COMPUT~~~!!"
Report, edit, etc...Posted by DiscipleOfAdun on 2006-08-14 at 14:51:28
QUOTE(TERRAINFIGHTER @ Aug 8 2006, 03:11 PM)
Or if you want to read something shorter, you can read what I wrote a while back
also, LO* files have 17 entries per-frame just like in the grp's, not 22
[right][snapback]542514[/snapback][/right]
also, LO* files have 17 entries per-frame just like in the grp's, not 22
[right][snapback]542514[/snapback][/right]
The lof files have 22 entries per each frame. However many frame the building has, then it has that many. I had an .lof file open when typing that up, so I know it is right. Remember, different lo? files have different number of offsets per frame. Also, the names that blizz put do tell you what offsets are in the file, that's why my list. Of course the name doesn't matter when you make new ones, but for clarity sake, I suggest using the extentions that tell you what is in the file.
QUOTE(Lord_Agamemnon @ Aug 11 2006, 07:58 PM)
Disciple: I've got another problem that people--especially me--can fall victim to quite easily for you to put in the big list of "Unit makes game crash:" Button number exceeds actual number of buttons. That is, the number of buttons in the "Unit" tab of Memgraft > the number of buttons in the unit's actual command list.
[right][snapback]543651[/snapback][/right]
[right][snapback]543651[/snapback][/right]
True, I forgot that one. However, I never encouter it, because FG does not have that problem. And I'm using an old build of FG for 1.13f for any buttons that I do right now.
Report, edit, etc...Posted by TERRAINFIGHTER on 2006-08-14 at 16:17:23
QUOTE(DiscipleOfAdun @ Aug 14 2006, 01:51 PM)
The lof files have 22 entries per each frame. However many frame the building has, then it has that many. I had an .lof file open when typing that up, so I know it is right. Remember, different lo? files have different number of offsets per frame. Also, the names that blizz put do tell you what offsets are in the file, that's why my list. Of course the name doesn't matter when you make new ones, but for clarity sake, I suggest using the extentions that tell you what is in the file.
True, I forgot that one. However, I never encouter it, because FG does not have that problem. And I'm using an old build of FG for 1.13f for any buttons that I do right now.
[right][snapback]544827[/snapback][/right]
1. I was using 17 as an example for the common unit, the frames in the LO* files are always the same as the unit.
2. I know they have differant extensions to tell you what they're for, that's just a note so they know it's the same format.
[offtopic]3. If you have a working version of 1.13f, can you please send it to me since my game refuses to upgrade to 1.14?
I could just stick to memgraft, but I lost the version you have to save with in order to open your own files
[/offtopic]Report, edit, etc...Posted by DaMiNaToR on 2006-08-23 at 00:21:32
Why do you talk in orange?
Report, edit, etc...Posted by DiscipleOfAdun on 2006-08-23 at 19:19:48
lol, I like orange.
Would you prefer the purple I use for MSN?
Would you prefer the purple I use for MSN?
Report, edit, etc...Posted by Killer_Kow(MM) on 2006-08-24 at 15:40:16
No.
Report, edit, etc...Posted by Heavyclone on 2006-10-25 at 19:14:14
The details of my crash:
So far the only units causeing me crash on select is the Carrier. My brother has been begging me to make it shoot a array of laser's in normal attack's for ground and air, despite it haveing untis stored inside it. So, I went into the dat files for weapon's and units and modified them so the carrier has both air and ground weapons. I then went into IceCC added the Script for air and ground attack. And I can build it sucessfully, just when I click on it it crashes. My IceCC code is:
# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Wed Oct 25 23:53:58 2006
# ----------------------------------------------------------------------------- #
# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 112 Carrier (protoss\carrier.grp)
.headerstart
IsId 151
Type 21
Init CarrierInit
Death CarrierDeath
GndAttkInit CarrierGndAttkInit
AirAttkInit CarrierAirAttkInit
SpAbility1 [NONE]
GndAttkRpt [NONE]
AirAttkRpt [NONE]
SpAbility2 [NONE]
GndAttkToIdle [NONE]
AirAttkToIdle [NONE]
SpAbility3 [NONE]
Walking CarrierWalking
Other CarrierOther
BurrowInit [NONE]
ConstrctHarvst [NONE]
IsWorking [NONE]
Landing [NONE]
LiftOff [NONE]
Unknown18 [NONE]
Unknown19 [NONE]
Unknown20 [NONE]
Unknown21 CarrierUnknown21
.headerend
# ----------------------------------------------------------------------------- #
CarrierInit:
__3d 10752
playfram 0x00 # frame set 0
goto CarrierOther
CarrierOther:
shvertpos 1
waitrand 8 10
shvertpos 2
waitrand 8 10
shvertpos 1
waitrand 8 10
shvertpos 0
waitrand 8 10
goto CarrierOther
CarrierDeath:
playsndbtwn 595 596 # Protoss\Carrier\PCaDth00.WAV, Protoss\Carrier\PCaDth01.WAV
imgol08 214 0 0 # ProtossBuildingExplosionMedium (thingy\tBangL.grp)
wait 3
end
CarrierGndAttkInit:
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
goto CarrierGndAttkInit
CarrierAirAttkInit:
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
goto CarrierAirAttkInit
CarrierWalking:
imgol08 114 0 0 # CarrierGlow (thingy\pcaGlow.grp)
goto local00
local00:
wait 125
goto local00
CarrierUnknown21:
imgol08 115 0 0 # Unknown115 (protoss\carrier.grp)
goto local00
Thats the entire code, I don't know why it doesnt work, i'm haveing a slight guess it's because I didn't use the Repeat Attack tag, I dunno. Please help
So far the only units causeing me crash on select is the Carrier. My brother has been begging me to make it shoot a array of laser's in normal attack's for ground and air, despite it haveing untis stored inside it. So, I went into the dat files for weapon's and units and modified them so the carrier has both air and ground weapons. I then went into IceCC added the Script for air and ground attack. And I can build it sucessfully, just when I click on it it crashes. My IceCC code is:
CODE
# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Wed Oct 25 23:53:58 2006
# ----------------------------------------------------------------------------- #
# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 112 Carrier (protoss\carrier.grp)
.headerstart
IsId 151
Type 21
Init CarrierInit
Death CarrierDeath
GndAttkInit CarrierGndAttkInit
AirAttkInit CarrierAirAttkInit
SpAbility1 [NONE]
GndAttkRpt [NONE]
AirAttkRpt [NONE]
SpAbility2 [NONE]
GndAttkToIdle [NONE]
AirAttkToIdle [NONE]
SpAbility3 [NONE]
Walking CarrierWalking
Other CarrierOther
BurrowInit [NONE]
ConstrctHarvst [NONE]
IsWorking [NONE]
Landing [NONE]
LiftOff [NONE]
Unknown18 [NONE]
Unknown19 [NONE]
Unknown20 [NONE]
Unknown21 CarrierUnknown21
.headerend
# ----------------------------------------------------------------------------- #
CarrierInit:
__3d 10752
playfram 0x00 # frame set 0
goto CarrierOther
CarrierOther:
shvertpos 1
waitrand 8 10
shvertpos 2
waitrand 8 10
shvertpos 1
waitrand 8 10
shvertpos 0
waitrand 8 10
goto CarrierOther
CarrierDeath:
playsndbtwn 595 596 # Protoss\Carrier\PCaDth00.WAV, Protoss\Carrier\PCaDth01.WAV
imgol08 214 0 0 # ProtossBuildingExplosionMedium (thingy\tBangL.grp)
wait 3
end
CarrierGndAttkInit:
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
goto CarrierGndAttkInit
CarrierAirAttkInit:
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 1
wait 1
attack25 2
wait 1
attack25 1
wait 1
goto CarrierAirAttkInit
CarrierWalking:
imgol08 114 0 0 # CarrierGlow (thingy\pcaGlow.grp)
goto local00
local00:
wait 125
goto local00
CarrierUnknown21:
imgol08 115 0 0 # Unknown115 (protoss\carrier.grp)
goto local00
Thats the entire code, I don't know why it doesnt work, i'm haveing a slight guess it's because I didn't use the Repeat Attack tag, I dunno. Please help
Report, edit, etc...Posted by Pie_Sniper on 2006-10-25 at 19:26:32
Why did you post that in here? But yeah, it should end with
and CarrierGndAttkToIdle should just wait and repeat.
Also, since AirAttkInit and GndAttkInit are the same, just set them both to the same header.
CODE
gotorepeatattk
goto CarrierGndAttkToIdle
goto CarrierGndAttkToIdle
and CarrierGndAttkToIdle should just wait and repeat.
Also, since AirAttkInit and GndAttkInit are the same, just set them both to the same header.
Report, edit, etc...Posted by Heavyclone on 2006-10-25 at 19:39:35
Because it say's if it's an IceCC problem post the code, or sumet like that. And if you check through carefully the to codes are actually diffrent, every 5 "attack25 1" theres a "attack25 2" i'll give it a shot tho
Report, edit, etc...Posted by Pie_Sniper on 2006-10-25 at 19:45:44
Yeah, post the code in your thread... I see what you mean with the attacks, I guess you can't do it then.
Report, edit, etc...Posted by Lord_Agamemnon(MM) on 2006-10-25 at 20:20:32
Carriers are forced to attack with Interceptors. It's hard-coded into the game, unfortunately. I've tried giving them regular attacks, but it doesn't work so well and either plain doesn't work or crashes.