Ah, it's not a big deal. This is how we all learn. The best thing for you, OP, is to be humble as a programmer, you'll get a lot farther. As long as you're trying to learn, then it doesn't matter what skill level you are, you're a programmer.
The biggest problem to overcome in programming is learning to treat your code like a living creature, you need to take care of it throughout the process and continually revise, enhance, and change it. If you get stuck at a certain point, instead of giving up, use it as a way to learn. I know this sounds like pseudo-garbage, but it works. By reading these posts and noticing the similarity in people's suggestions you should be able to see what your next step is. You never have to "start over", think of it as part of the modding process and also think of it as you becoming a better programmer.
Every programmer runs into a situation where they get an idea and run away with it and create something nice, but inefficient (I'm doing it right now....for the millionth time). This isn't poor programming or lack of skill, it's simply part of programming. Just refine what you have until it fits the size needed, you'll probably learn that it's a lot easier to do things the way people are suggesting and that's a good thing. Don't be afraid to learn from others and to listen.
With that said, I am sure you'll find a way to correct this and I bet it will be better than you expected since more efficient code usually makes for a better game.
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)
This is how you should handle this part. (maybe should is a strong word... use could instead) *Im assuming your skill tree triggers are for the dialog/ui and not actually creating the skills.
Pick each player
{
run action definition here* in the action definition make a parameter of int type and send picked player
}
Action Definition - Player Skill Tree
- global variable - player class (this can be defined different ways. I would make this an int variable and define your actions on a number for each class... firetrooper = 2, assassin = 1... This can be defined when players chose a class. PlayerClass[pickedPlayer])
-temporary Int - skill row = 1
-temp Int - skill column = 1
Now in the actions portion you can setup your skill tree. If you used a tier skill tree, like wow or diablo, then its easy. Have a defining trigger/action at the map initialization that puts created abilities into arrays. To setup all your rows of skills call your variable with arrays like this..
That should make a sufficient(if not horrible) skill window UI. BTW this is just a quick example at 3:30am. dont judge. I would definently tweak this if it were my own. (I know my variable names are different as I typed em and a lot is missing) hehe.
A few things to look at;
-The action definition makes a simple row and column button list for any class, not just specific ones. This is done by making another action definition. for assassin as an example, class 1. create button-> define button style and details. set variable HeroSkillButton[1][1][2] = last create dialog item. This will make that said ability/button in row one, at the second collumn(middle). This button will only show to players who have chosen the assassin class. This is ofcourse if youve made an array for the dialog for each player. Show/Hide SkillTreeUI[triggering player]
-The if statement will allow you to skip spots in your tree and leave that space empty.
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)
You can replace all these "if" with only one "for" loop. The For will compare an integer setting the class of the character (1 for assassin, 2 for firetrooper, etc...) and do an action at the same time for each cases, which saves you lots of efforts (because using Ifs means you need to check manually which case happens when, to who, and with which values). Basically, instead of checking which player is of which class, you will check which class is attributed to who instead. It may look the same to you, but it's not. Don't forget to use switches, For loops, "pick each..." etc... It will save a loooooot of time and reduce your scripts at least by third, if not half. And don't forget to ask your triggers to give instructions via other triggers too. Assign a trigger per class, or a trigger per player, but not a trigger for each class for each player (this is just an example here, but judging by the number of triggers you have, you probably did this mistake more than once). You'll get exponentially more (useless) triggers if you don't automatize the tasks.
Your UI shows 120 buttons in one window? Fine! You need 2 consecutive For loops: one for checking the columns, one for checking the rows... every button will display the matching content linked to an array(integer)[columnmax][rowmax]. 3 elements, just to show 120 things... The 120 things are defined in a "map init" trigger which inserts all the values in the array. The UI actions done, depending on which button is pressed, work the exact same way... It's a bit tricky to remember which of your arrays/integers/booleans/types does what, but name them properly and it will be more obvious to you. This is precisely what I've been doing in my Smallworld map (in a smaller scale obviously), I had a trigger size problem too, but splitting the process in 3 triggers instead of 2 did the job. And I'm pretty sure I can still improve the code to make it work with only 2 triggers, as planned. In your case, despite the number of things to display, it should be easier than in my map. Because in my map, the content of the UI depends on random cards taken from a deck, while your tech tree is something permanent.
Actually, I'd like to see a screenshot or two of your triggers showing the assassin's class UI. I'd like to see how we can help and find how to improve your actual scripts. Because obviously, it needs to or you'll get stuck forever.
lol Sorry egod, but I refuse to believe its a "fail editor" just because of this.
Why are you so resistant to cropping your triggers? Evidently there are some great programmers willing to help... why not let them?... and then maybe you can release your map?... instead of bailing on all your hard work? Unless you actually just don't care anymore lol
sorry, i just had to laugh when you said "TRIGGERS EVERYTHING" so many times XD
now, I'm not exactly an amazing map-maker... but I've been using this stuff for years nonetheless
I'm also making a map with plenty of UI's, and believe me it'll be intensive (It's based to play like Final Fantasy 13, although I'm planning on implementing the system for leveling differently...)
Now, I'm not sure what your UI looks like, or how it functions, but believe me when I say this: There is always room for improvement.
Even if you believe it to work perfectly, eventually you might hit some sort of wall (as you have now) and wonder how anyone could ever possibly fix your problem, let alone you yourself D:
I am VERY glad that you've actually posted your problem on a site like this! I normally bash my brains out for days or even weeks when I get stuck on little things, end up scrapping entire folders of triggers and re-writing them, only to find out that that way didn't work either XD
You've completed the first step by asking for help... you just need t do the second and listen to the help that's been given!
I've learned wonders about how to optimize my triggers from classes in C++ and Java, some these guys probably have years of real-life programming experience behind them. At the very least they're familiar with the parts of the editor they're talking about!
Just give some of their ideas a try for once, or post an image of your largest trigger, or something. You may have to take criticism, but it'll certainly be well worth it if it allows you to continue work on your project!
Believe me, almost all of them would love to play your map when it's released! xD
And I suppose I would to... :P
I normally bash my brains out for days or even weeks when I get stuck on little things, end up scrapping entire folders of triggers and re-writing them, only to find out that that way didn't work either XD
Quoted for truth. Brainfreeze is our common friend.
I dont see the problem... The screenshot shows compressed size of 3.6mb. You can tripple the number of triggers and variables and still be ok for the 10 mb filesize
@progammer: Go
Progammer speaks the truth, soon-to-come Patch 1.2 simplifies nearly all aspects of your map (making them require less or no triggers). (Example: Custom UI based on layout files, mousemove detection function, etc)
I'm pretty sure what people are saying about using for-loops is probably true. If you ever see yourself having to copy/paste the same things over again, you probably could've just used a loop of some sort, or similar structured algorithms into "functions".
There's plenty of people that wanna help you optimize your scripts if you're still interested in completing this. The trigger limit is just another hurdle, not unlike any other feature you've had to research and implement before.
i am doing diablo 2 map i am at 6.8megs for triggers and im done about 40 % of the map i would say that you are not compression it enough here are my trigger stats uncompressed:
i am doing diablo 2 map i am at 6.8megs for triggers and im done about 40 % of the map i would say that you are not compression it enough here are my trigger stats uncompressed:
Some of my maps have uncompressed 14.5 MB in triggers (525 objects), they work just fine and have for months. I shit you not. It's unplayable for players with less than 2 GB of RAM however.
Wow, I wasn't part of this forum when this thread was created, but this is very depressing to read. So much help offered for such a big map :(
Also I wonder how everyone posting their screenshots here have this many triggers, especially when they have such a trigger heavy map that they get into size problems. I mean as far as I understand the efficiency of triggers/functions/action definitions there isn't really a reason to have more than 1 trigger for every event type (which would be <50 triggers)? If you only handle the event for specific parameters (for example Key Pressed "1") it gets inefficient as soon as you add the same event for different parameters (for example Key Pressed "2"), because every time I press a key he would check both event conditions anyway, right? So I can just outspace it into an action definition which is less clumpy than a trigger and check the conditions there with a switch or loop. Also it gets much easier to read this way from my point of view.
@OP
Ah, it's not a big deal. This is how we all learn. The best thing for you, OP, is to be humble as a programmer, you'll get a lot farther. As long as you're trying to learn, then it doesn't matter what skill level you are, you're a programmer. The biggest problem to overcome in programming is learning to treat your code like a living creature, you need to take care of it throughout the process and continually revise, enhance, and change it. If you get stuck at a certain point, instead of giving up, use it as a way to learn. I know this sounds like pseudo-garbage, but it works. By reading these posts and noticing the similarity in people's suggestions you should be able to see what your next step is. You never have to "start over", think of it as part of the modding process and also think of it as you becoming a better programmer.
Every programmer runs into a situation where they get an idea and run away with it and create something nice, but inefficient (I'm doing it right now....for the millionth time). This isn't poor programming or lack of skill, it's simply part of programming. Just refine what you have until it fits the size needed, you'll probably learn that it's a lot easier to do things the way people are suggesting and that's a good thing. Don't be afraid to learn from others and to listen.
With that said, I am sure you'll find a way to correct this and I bet it will be better than you expected since more efficient code usually makes for a better game.
Good Luck!
This is how you should handle this part. (maybe should is a strong word... use could instead) *Im assuming your skill tree triggers are for the dialog/ui and not actually creating the skills.
Pick each player {
Action Definition - Player Skill Tree
- global variable - player class (this can be defined different ways. I would make this an int variable and define your actions on a number for each class... firetrooper = 2, assassin = 1... This can be defined when players chose a class. PlayerClass[pickedPlayer])
-temporary Int - skill row = 1
-temp Int - skill column = 1
Now in the actions portion you can setup your skill tree. If you used a tier skill tree, like wow or diablo, then its easy. Have a defining trigger/action at the map initialization that puts created abilities into arrays. To setup all your rows of skills call your variable with arrays like this..
while(skill row < 4) {
while(skill column < 4) {
if(HeroSkillButton != no dialog item)
move dialog item HeroSkillButton[PlayerClass][skillrow][skill column] to offset(76*skill column, 76 * skill row);
skill column = skill column +1 }
skill row = skill row + 1 }
That should make a sufficient(if not horrible) skill window UI. BTW this is just a quick example at 3:30am. dont judge. I would definently tweak this if it were my own. (I know my variable names are different as I typed em and a lot is missing) hehe.
A few things to look at;
-The action definition makes a simple row and column button list for any class, not just specific ones. This is done by making another action definition. for assassin as an example, class 1. create button-> define button style and details. set variable HeroSkillButton[1][1][2] = last create dialog item. This will make that said ability/button in row one, at the second collumn(middle). This button will only show to players who have chosen the assassin class. This is ofcourse if youve made an array for the dialog for each player. Show/Hide SkillTreeUI[triggering player]
-The if statement will allow you to skip spots in your tree and leave that space empty.
You can replace all these "if" with only one "for" loop. The For will compare an integer setting the class of the character (1 for assassin, 2 for firetrooper, etc...) and do an action at the same time for each cases, which saves you lots of efforts (because using Ifs means you need to check manually which case happens when, to who, and with which values). Basically, instead of checking which player is of which class, you will check which class is attributed to who instead. It may look the same to you, but it's not. Don't forget to use switches, For loops, "pick each..." etc... It will save a loooooot of time and reduce your scripts at least by third, if not half. And don't forget to ask your triggers to give instructions via other triggers too. Assign a trigger per class, or a trigger per player, but not a trigger for each class for each player (this is just an example here, but judging by the number of triggers you have, you probably did this mistake more than once). You'll get exponentially more (useless) triggers if you don't automatize the tasks.
Your UI shows 120 buttons in one window? Fine! You need 2 consecutive For loops: one for checking the columns, one for checking the rows... every button will display the matching content linked to an array(integer)[columnmax][rowmax]. 3 elements, just to show 120 things... The 120 things are defined in a "map init" trigger which inserts all the values in the array. The UI actions done, depending on which button is pressed, work the exact same way... It's a bit tricky to remember which of your arrays/integers/booleans/types does what, but name them properly and it will be more obvious to you. This is precisely what I've been doing in my Smallworld map (in a smaller scale obviously), I had a trigger size problem too, but splitting the process in 3 triggers instead of 2 did the job. And I'm pretty sure I can still improve the code to make it work with only 2 triggers, as planned. In your case, despite the number of things to display, it should be easier than in my map. Because in my map, the content of the UI depends on random cards taken from a deck, while your tech tree is something permanent.
Actually, I'd like to see a screenshot or two of your triggers showing the assassin's class UI. I'd like to see how we can help and find how to improve your actual scripts. Because obviously, it needs to or you'll get stuck forever.
lol Sorry egod, but I refuse to believe its a "fail editor" just because of this.
Why are you so resistant to cropping your triggers? Evidently there are some great programmers willing to help... why not let them?... and then maybe you can release your map?... instead of bailing on all your hard work? Unless you actually just don't care anymore lol
You can continue with the project now that patch 1.2 is out and simplify almost every core feature in your maps
The bad thing is you have to remake everything? Not sure how the UI thingy works, but I would expect you dont need so many dialogs anymore...
Quoted for truth. Brainfreeze is our common friend.
ie. Restart all your work. :'(
I dont see the problem... The screenshot shows compressed size of 3.6mb. You can tripple the number of triggers and variables and still be ok for the 10 mb filesize
@PepperLoaT: Go
triggers have their own limit, which is what he reached and is making it so any new triggers get completely ignored
<<quote 234842>>@egodbout: GoYou can replace all these "if" with only one "for" loop. <</quote>>
I would have shown this but I heard for loops are broken and have a memory leak. Is this untrue? if so please tell me. ^_^
@progammer: Go Progammer speaks the truth, soon-to-come Patch 1.2 simplifies nearly all aspects of your map (making them require less or no triggers). (Example: Custom UI based on layout files, mousemove detection function, etc)
I'm pretty sure what people are saying about using for-loops is probably true. If you ever see yourself having to copy/paste the same things over again, you probably could've just used a loop of some sort, or similar structured algorithms into "functions".
There's plenty of people that wanna help you optimize your scripts if you're still interested in completing this. The trigger limit is just another hurdle, not unlike any other feature you've had to research and implement before.
i am doing diablo 2 map i am at 6.8megs for triggers and im done about 40 % of the map i would say that you are not compression it enough here are my trigger stats uncompressed:
3,471 - Action
212 - Comment
946 - Condition
24 - Custom Script
131 - Event
53 - Folder
91 - Function
4,802 - Function Call
1 - Label
189 - Parameter
2 - Preset
5 - Preset Value
18 - Record
155 - Trigger
2 - Trigger Libraries
561 - Variable
you do realize the person stopped his project about a year ago?.... lol look at the thread date.
altho i agree the issue the author is having is still an issue even now... the 2mb script size limit is ridiculous.
@Zolstice: Go
ive asked him to start it again he wont till hots comes out and thats not supposed to till 12/31/2012
@xXdRaGoNrIdDeRXx: Go
Some of my maps have uncompressed 14.5 MB in triggers (525 objects), they work just fine and have for months. I shit you not. It's unplayable for players with less than 2 GB of RAM however.
Wow, I wasn't part of this forum when this thread was created, but this is very depressing to read. So much help offered for such a big map :(
Also I wonder how everyone posting their screenshots here have this many triggers, especially when they have such a trigger heavy map that they get into size problems. I mean as far as I understand the efficiency of triggers/functions/action definitions there isn't really a reason to have more than 1 trigger for every event type (which would be <50 triggers)? If you only handle the event for specific parameters (for example Key Pressed "1") it gets inefficient as soon as you add the same event for different parameters (for example Key Pressed "2"), because every time I press a key he would check both event conditions anyway, right? So I can just outspace it into an action definition which is less clumpy than a trigger and check the conditions there with a switch or loop. Also it gets much easier to read this way from my point of view.
Or am I totally wrong with this?
From my experiance, you're wrong I'm afraid.
Triggers are incredibly stupid, and you need to be sure to cover each and every single corner.
Make six versions of one trigger in an attempt to make sure it always works? Better add four more just to make sure.