You are just doing it wrong... You are sure not using action definitions, functions and cycles to write less code possible. If you are using copy and paste more then 2 times on the same code you probably could write it in a better way.
There is no way to reach this trigger size if you do an efficient triggering!
My Crush Company map that has a heavy trigger usage is just 623k compressed and it could be less if i found some way to recycle some scripts for each unit's AI
You are just doing it wrong... You are sure not using action definitions, functions and cycles to write less code possible. If you are using copy and paste more then 2 times on the same code you probably could write it in a better way.
There is no way to reach this trigger size if you do an efficient triggering!
My Crush Company map that has a heavy trigger usage is just 623k compressed and it could be less if i found some way to recycle some scripts for each unit's AI
i dont do it wrong, its just way more complex than Crush Compagy
Even though I'm on your side, Bibendus kind of right. There HAS to be some way you can compress all of your triggers down into smaller ones. I ended up removing 1/3 of my triggers thanks to some help. Maybe what you need is anotheer thread asking for help to compress it. Unless you truely want to do it all by yourself and compress it on your own. :) Hope you get back to working soon! :)
Edit: Unless your triggers for your hero selection is pact down into 2-4 triggers, then you need A LOT of work.
If you are a programmer (not progammer xD) it's easier to well manage the scripts... and NO... the diablo rpg is not more complex.
BTW having a huge trigger where you copy paste the same row 100 times it doesnt mean that the trigger is complex, its just bad done.
Even UI creation can be optimized using some action definitions or for cycles, unfortunatel not many modders do that.
To have this huge amount of well made triggers you would need many game features and your diablo map should have something like x10 times the features of a standard custom map.
There is no way you are efficiently coding. Lets look at your trigger stats.
635 seperate triggers? holy crap are you kidding me?
only 12 functions? 12 functions to 635... some thing not right there. I only started doing my triggering my map and i have 5 functions to my 20 triggers...
1770 variables? have you heard of using arrays? or even data table?
No offense meant mate but you need someone to look over your triggers. because there is no way you doing them efficiently, I and nobody else will beleive it. Action functions can be small peices of code that you use several times and it will cut down your length easily.
Custom conditions is another thing if used several times, that can be used to cut down the amount of times it used.
They're definitely right... If you reached the triggers limit, you obviously did it wrong. Think of your code as a human body: The brain (one trigger) controls EVERYTHING, he gives all the orders to the other parts but doesn't do anything else (basically, it will be filled with "run trigger" and "wait for condition" triggers in-between, if needed).
The heart is the core of your game, its role is to set variables according to other variables. It's probably the biggest one, and if you need to split it to reduce its size, do the same process as for the brain: run trigger, and wait for condition. It is the trigger (up to 4, or else you screwed something up) that will "feed" the other triggers with data.
The lungs/liver/kidneys are the other triggers that will actually run when both the brain and the heart have done their job. This is the part that actually do anything on screen, thanks to what was defined with the previous triggers. It can be divided in 6-8 triggers approximately, to reduce the size of each. But the less trigger you need to create, the better. Each "organ" is a huge trigger which, as always, executes "run trigger" and "wait for condition" again. Any other task is done by dozens of small triggers running, let's say, up to 20 instructions each.
When you have lots of instructions to be done, the more you discharge/delegate the better. Think of it as a company, if you prefer: The CEO does nothing but delegate (which is not as an easy job as it looks, by the way!), and everyone working for the CEO try to do the same, until the poor little interns are submerged with work. (ahhhh, good old times...)
Anyway, you SHOULDN'T have 1500+ variables (this is totally insane... you're not even using arrays, are you?), and 500+ triggers is obviously something you can reduce by half if you do what we said. A code is like a tree: the roots hold everything together, branches divide the work, so that the leaves can manage one task at a time.
It's an important matter in the process of creating a game: you need to think it as if it was a human body. Brain for the boss room (or any final epic event... whatever it is, it is your goal); heart which stands for the big room/crossroad (most often right next the boss) where you come back multiple times in the game, right after visiting the other parts (kidneys, liver, and lungs... etc etc...). Each organ of the human body can be defined as a part of a game, and each of these have a specific role you can't switch or remove. It may look silly, but it's not. Arkham Asylum works this way. Darksiders works this way. Starcraft 2, well... it's not as obvious, but it works the same way (Char is the Brain, the briefing room is the Heart, etc...). Remove anything and it will be unstable. ;)
635 separate triggers? There isn't even that many different event types and you have only got 12 functions. You must be repeating the same script several times.
635 separate triggers? There isn't even that many different event types and you have only got 12 functions. You must be repeating the same script several times.
Do most of these triggers have events?
Because triggers eat up more memory than a function does, so turning triggers without events into functions/actions is a good idea.
Do most of these triggers have events?
Because triggers eat up more memory than a function does, so turning triggers without events into functions/actions is a good idea.
lot of events yeah
but the worst is the skill UI panel
its around 5xDialog item for 1 skill, there maybe 20xSkill for 1xHero, with 6xHeros, its around 120xdialog item just for the talent tree system, yep it hurt.
This makes you want to have a IDE trigger/galaxy program that allows people to share and modify it right?
Because if you can easily have the experienced programmers look at it, they might be able to shrink your triggers to half it's size.
I'm also wondering if Blizzard will allow modders to actually implement addons onto maps, say a mod file.
It shouldn't be ridiculously hard to do, just a separate entity that can be called and ran by a map...
Of course, the problem is that maps won't be downloaded with it, and maybe maps would have to have links to get it... The idea is this:
- You have a mapper who makes a mod, that works with a series of his maps, meaning it reuses codes from the mods, not triggers from the map, thus saving map file space.
Too bad Blizzard would get paranoid because of the possibility of running "viral maps" but it's not like people can't do that right now by importing files...
its around 120xdialog item just for the talent tree system
Yet, you don't have to display everything, every time... If the player is of class X, you don't have to show the whole tree for each class in the UI. It's not even necessary to show the 5 dialog items per skill, just show the current level and the item corresponding to the next level. 20 skills per hero also means you only need to display the current hero for player X in the UI.
So basically, there are at least 3 things you can do to reduce the content of the trigger showing the UI. You don't need to do a trigger for each of the 120 cases, your trigger CAN'T possibly check for the 120 cases alone either, so you just need to do a trigger generating a UI depending on values (integers/reals, unit type, etc...) and booleans defined by other triggers. The trigger showing the UI should do nothing but check values that were already modified by triggers BEFORE, so that you don't have to check every possible case at the moment you display the UI.
What you need should be something like:
1 trigger to define each dialog items (this is the biggest trigger you will have, it is used to create a menu containing the maximum of 120 items you speak of... but I seriously advice you DON'T display the whole tree for each hero and each level of each skill... that's just insane)
1 trigger "show UI" (which will show the dialog box, check for values from other triggers then display them in the right dialog item)
1 trigger to define the 5 levels of a skill (basically a switch that will change the settings/actions done depending on which skill it is)
1 trigger to define which hero has which skills in his "tech tree".
You will have something like 30-40 variables (most likely integer arrays and/or booleans) to recognize every piece of information, and display them in a dialog box as needed. If you have more, you're doing it wrong. From what I remember from the video you showed once, there were errors very often in the error frame and the game mechanics were not working fine. So, obviously, the project is very hard to make (who could deny it?) but you're doing something wrong nonetheless. You shouldn't give up this project, just seriously work on a better way to organize your triggers so that it will be easier for you to build on it. You started in the wrong direction, that sucks but it's OK. You feel like you're in a dead end because you are, and this is the only way your method could have ended because it's not the right one. The only option left now is to take the problem from another point of view... ;)
I am also going to guess that you have done absolutly nothing in the data editor.... because of the size of your data files. If you are running all your data files through triggers we then have problem number two.
Data files are a lot smaller than triggers, so doing absolutly everythign you can in data is important. and trust me I have been learning a lot in data recently and there is an awful lot you can there.
As I said before you ahve 635 triggers, as twinmold said there isn't even that many events. if you are using the event "any unit dies" 40 times... thats 40 times smaller your triggers could be by putting them into one. Just use if then else or a switch to check with a condition which unit died that you required.
I have 8 dialogs set up for a hero/ability/difficulty selection which changes information as you go. it takes up 6 triggers and 3 events for the lot....
It sounds like you need to look in the team recruitment for someone to look over your code and break it down, I am sure there is someone out there looking for something to do at the moment.
What you need should be something like:
1 trigger to define each dialog items (this is the biggest trigger you will have, it is used to create a menu containing the maximum of 120 items you speak of... but I seriously advice you DON'T display the whole tree for each hero and each level of each skill... that's just insane)
1 trigger "show UI" (which will show the dialog box, check for values from other triggers then display them in the right dialog item)
1 trigger to define the 5 levels of a skill (basically a switch that will change the settings/actions done depending on which skill it is)
1 trigger to define which hero has which skills in his "tech tree".
i did, its like 120xDialogs items for 1xTalent tree (assassin for exemple), the level of the skill are just changed with variable, so dont worry about it
when the player 1 choose a assasin, the trigger run the assassin tree
when the player 2 choose a firetrooper, the trigger run the firetrooper tree
etc..
basictly, its 6x120 in one trigger = lots of lines (i actuelly reach the limit of 1xtrigger so i need 2xtriggers to complete 1xUI tree)
here a example:
pick each player in PGX group (player1=x)
if player X = Assassin hero
Run (Assasin skill tree UI) (120xDialog items)
if Player X = Firetrooper hero
Run (Firetrooper skill tree UI) (120xDialogs items)
that is funny, all people are like: you are a bad programmer, but actuelly, i simplified almost all my triggers with variable and array (for 12xplayers)
The fact you reached trigger limit says your doing it wrong >.> But if you want to think your right and not listen to all these advanced map makers advice, that is your choice. We were meerly trying to help.
@egodbout: Go
You are just doing it wrong... You are sure not using action definitions, functions and cycles to write less code possible. If you are using copy and paste more then 2 times on the same code you probably could write it in a better way.
There is no way to reach this trigger size if you do an efficient triggering!
My Crush Company map that has a heavy trigger usage is just 623k compressed and it could be less if i found some way to recycle some scripts for each unit's AI
i dont do it wrong, its just way more complex than Crush Compagy
@Bibendus: Go
Actually, there is. Final Frontier had gotten to max trigger space 2 times. Maybe 3. He had to fix it every time.
@egodbout: Go
Even though I'm on your side, Bibendus kind of right. There HAS to be some way you can compress all of your triggers down into smaller ones. I ended up removing 1/3 of my triggers thanks to some help. Maybe what you need is anotheer thread asking for help to compress it. Unless you truely want to do it all by yourself and compress it on your own. :) Hope you get back to working soon! :)
Edit: Unless your triggers for your hero selection is pact down into 2-4 triggers, then you need A LOT of work.
If you are a programmer (not progammer xD) it's easier to well manage the scripts... and NO... the diablo rpg is not more complex.
BTW having a huge trigger where you copy paste the same row 100 times it doesnt mean that the trigger is complex, its just bad done.
Even UI creation can be optimized using some action definitions or for cycles, unfortunatel not many modders do that.
To have this huge amount of well made triggers you would need many game features and your diablo map should have something like x10 times the features of a standard custom map.
There is no way you are efficiently coding. Lets look at your trigger stats.
635 seperate triggers? holy crap are you kidding me? only 12 functions? 12 functions to 635... some thing not right there. I only started doing my triggering my map and i have 5 functions to my 20 triggers...
1770 variables? have you heard of using arrays? or even data table?
No offense meant mate but you need someone to look over your triggers. because there is no way you doing them efficiently, I and nobody else will beleive it. Action functions can be small peices of code that you use several times and it will cut down your length easily. Custom conditions is another thing if used several times, that can be used to cut down the amount of times it used.
They're definitely right... If you reached the triggers limit, you obviously did it wrong. Think of your code as a human body: The brain (one trigger) controls EVERYTHING, he gives all the orders to the other parts but doesn't do anything else (basically, it will be filled with "run trigger" and "wait for condition" triggers in-between, if needed).
The heart is the core of your game, its role is to set variables according to other variables. It's probably the biggest one, and if you need to split it to reduce its size, do the same process as for the brain: run trigger, and wait for condition. It is the trigger (up to 4, or else you screwed something up) that will "feed" the other triggers with data.
The lungs/liver/kidneys are the other triggers that will actually run when both the brain and the heart have done their job. This is the part that actually do anything on screen, thanks to what was defined with the previous triggers. It can be divided in 6-8 triggers approximately, to reduce the size of each. But the less trigger you need to create, the better. Each "organ" is a huge trigger which, as always, executes "run trigger" and "wait for condition" again. Any other task is done by dozens of small triggers running, let's say, up to 20 instructions each.
When you have lots of instructions to be done, the more you discharge/delegate the better. Think of it as a company, if you prefer: The CEO does nothing but delegate (which is not as an easy job as it looks, by the way!), and everyone working for the CEO try to do the same, until the poor little interns are submerged with work. (ahhhh, good old times...)
Anyway, you SHOULDN'T have 1500+ variables (this is totally insane... you're not even using arrays, are you?), and 500+ triggers is obviously something you can reduce by half if you do what we said. A code is like a tree: the roots hold everything together, branches divide the work, so that the leaves can manage one task at a time.
I'm running out of metaphors now. :D
@ZealNaga: Go
Why did you make a comparsion with the human body? That's insane xD
@Bibendus: Go Insane, but true! :D
It's an important matter in the process of creating a game: you need to think it as if it was a human body. Brain for the boss room (or any final epic event... whatever it is, it is your goal); heart which stands for the big room/crossroad (most often right next the boss) where you come back multiple times in the game, right after visiting the other parts (kidneys, liver, and lungs... etc etc...). Each organ of the human body can be defined as a part of a game, and each of these have a specific role you can't switch or remove. It may look silly, but it's not. Arkham Asylum works this way. Darksiders works this way. Starcraft 2, well... it's not as obvious, but it works the same way (Char is the Brain, the briefing room is the Heart, etc...). Remove anything and it will be unstable. ;)
@ZealNaga: Go
Stop that arghhhhhhhhhhhh xD
@Bibendus: Go
You DO realize this is like encouraging me to continue, right? xD
OK then, let's live in trees and be friend with bears... :P
@egodbout: Go
635 separate triggers? There isn't even that many different event types and you have only got 12 functions. You must be repeating the same script several times.
not so much
@egodbout: Go
Do most of these triggers have events?
Because triggers eat up more memory than a function does, so turning triggers without events into functions/actions is a good idea.
lot of events yeah but the worst is the skill UI panel its around 5xDialog item for 1 skill, there maybe 20xSkill for 1xHero, with 6xHeros, its around 120xdialog item just for the talent tree system, yep it hurt.
This makes you want to have a IDE trigger/galaxy program that allows people to share and modify it right?
Because if you can easily have the experienced programmers look at it, they might be able to shrink your triggers to half it's size.
I'm also wondering if Blizzard will allow modders to actually implement addons onto maps, say a mod file.
It shouldn't be ridiculously hard to do, just a separate entity that can be called and ran by a map...
Of course, the problem is that maps won't be downloaded with it, and maybe maps would have to have links to get it... The idea is this:
- You have a mapper who makes a mod, that works with a series of his maps, meaning it reuses codes from the mods, not triggers from the map, thus saving map file space.
Too bad Blizzard would get paranoid because of the possibility of running "viral maps" but it's not like people can't do that right now by importing files...
Yet, you don't have to display everything, every time... If the player is of class X, you don't have to show the whole tree for each class in the UI. It's not even necessary to show the 5 dialog items per skill, just show the current level and the item corresponding to the next level. 20 skills per hero also means you only need to display the current hero for player X in the UI.
So basically, there are at least 3 things you can do to reduce the content of the trigger showing the UI. You don't need to do a trigger for each of the 120 cases, your trigger CAN'T possibly check for the 120 cases alone either, so you just need to do a trigger generating a UI depending on values (integers/reals, unit type, etc...) and booleans defined by other triggers. The trigger showing the UI should do nothing but check values that were already modified by triggers BEFORE, so that you don't have to check every possible case at the moment you display the UI.
What you need should be something like:
1 trigger to define each dialog items (this is the biggest trigger you will have, it is used to create a menu containing the maximum of 120 items you speak of... but I seriously advice you DON'T display the whole tree for each hero and each level of each skill... that's just insane)
1 trigger "show UI" (which will show the dialog box, check for values from other triggers then display them in the right dialog item)
1 trigger to define the 5 levels of a skill (basically a switch that will change the settings/actions done depending on which skill it is)
1 trigger to define which hero has which skills in his "tech tree".
You will have something like 30-40 variables (most likely integer arrays and/or booleans) to recognize every piece of information, and display them in a dialog box as needed. If you have more, you're doing it wrong. From what I remember from the video you showed once, there were errors very often in the error frame and the game mechanics were not working fine. So, obviously, the project is very hard to make (who could deny it?) but you're doing something wrong nonetheless. You shouldn't give up this project, just seriously work on a better way to organize your triggers so that it will be easier for you to build on it. You started in the wrong direction, that sucks but it's OK. You feel like you're in a dead end because you are, and this is the only way your method could have ended because it's not the right one. The only option left now is to take the problem from another point of view... ;)
@ZealNaga: Go
I am also going to guess that you have done absolutly nothing in the data editor.... because of the size of your data files. If you are running all your data files through triggers we then have problem number two.
Data files are a lot smaller than triggers, so doing absolutly everythign you can in data is important. and trust me I have been learning a lot in data recently and there is an awful lot you can there.
As I said before you ahve 635 triggers, as twinmold said there isn't even that many events. if you are using the event "any unit dies" 40 times... thats 40 times smaller your triggers could be by putting them into one. Just use if then else or a switch to check with a condition which unit died that you required.
I have 8 dialogs set up for a hero/ability/difficulty selection which changes information as you go. it takes up 6 triggers and 3 events for the lot....
It sounds like you need to look in the team recruitment for someone to look over your code and break it down, I am sure there is someone out there looking for something to do at the moment.
i did, its like 120xDialogs items for 1xTalent tree (assassin for exemple), the level of the skill are just changed with variable, so dont worry about it
basictly, its 6x120 in one trigger = lots of lines (i actuelly reach the limit of 1xtrigger so i need 2xtriggers to complete 1xUI tree)
here a example:
that is funny, all people are like: you are a bad programmer, but actuelly, i simplified almost all my triggers with variable and array (for 12xplayers)
just admit blizz have a fail editor, come on!
@egodbout: Go
The fact you reached trigger limit says your doing it wrong >.> But if you want to think your right and not listen to all these advanced map makers advice, that is your choice. We were meerly trying to help.
@egodbout: Go
You could try to level of the skills in one string this makes you use less variables you can do it like this :
SetVariable(strSkills, (CombineStringsMult((IntToString(1)), " ", (IntToString(2))))) to save
SetVariable(skill1, (StringToInt((StringWord(strSkills, 1))))) to get it back
just some help in cutting down your variables