Can be usefull

You don't say

At quick glance, this looks like you would have to create a new trigger sheet everytime you wanted a different "mount" ability.

KILLCIDE said:

At quick glance, this looks like you would have to create a new trigger sheet everytime you wanted a different "mount" ability.

Click to expand...

How exactly do you mean?

You only support a single unittype for the combined form.

Oh, I suppose that is true. I basically only posted this because I created it for Maxwell. I guess it's only useful in an altered melee map where hippos (or another single mountable unit) needs to transfer abilities or keep them upon dismounting. In general, I suppose this system is too specific.

I also noticed that I used a specific unit type lol. However, I'll try to correct both of these things shortly!

It would be much better if you supported multiple unittypes. I will keep this as Awaiting Update for now.

I've got it finished right now actually I'm just updating the description!

It would be much better if you used hashtables, but I guess this works. Would the user have to manually add the ability to the Mount Seek Target trigger?

Also, I don't see how the AbilityToRetain[] will work for multiple unittypes. All of this doesn't seem user friendly, so I recommend you make your documentation more extensive. You also don't need to use And - Conditions for the regular If - Conditions statement as they are defaulted as AND anyway. The only time you need to use And - Conditions is when you use it with Or - Conditions.

Thanks for the info!!
AbilityToRetain[] works for every unit. That is, if you put Critical Strike, then every mounting unit that has critical strike will have their newly created unit also have CriticalStrike.

As for hashtables, I heard that they are slower than using arrays, so I basically have stayed away from them

Thing_I said:

AbilityToRetain[] works for every unit. That is, if you put Critical Strike, then every mounting unit that has critical strike will have their newly created unit also have CriticalStrike.

Click to expand...

Hrmm looping through it seems extremely unnecessary, but whatevs.

Thing_I said:

As for hashtables, I heard that they are slower than using arrays

Click to expand...

You have been misinformed. Regardless if they are actually slower, it would be extremely miniscule. Given the nature of your system, hashtables is literally your best bet. I won't be basing approval on that though, just know that youre missing out on a lot of stuff by not using it. I will try to take a look at this tonight.

Thanks, I'll try to get into hastables in that case.

KILLCIDE said:

Hrmm looping through it seems extremely unnecessary, but whatevs.

Click to expand...

Is there some other way to check if a unit has the abilities in the array? If so, I don't know it

Thing_I said:

Is there some other way to check if a unit has the abilities in the array? If so, I don't know it

Click to expand...

Given you are using arrays, you don't really have a choice this is where using hashtables would become extremely handy. All you have to do is lookup the unittype as the parent key and then you have direct access to which abilities they have. It does become a little tricky given that each unittype has different abilities, but then you can use store the number of abilities they have in the childkey and go from there.

So I found two bugs just from testing the map:

• One of the Knights won't dismount when you mount the other knight the same time
• Casting the mount / unmount buttons with the Hippogryphs will evidently prevent one of the hippos from dismounting

Also, it would be great if you can find a way from stopping the Knights from being displaced when they mount

KILLCIDE said:

So I found two bugs just from testing the map:

• One of the Knights won't dismount when you mount the other knight the same time
• Casting the mount / unmount buttons with the Hippogryphs will evidently prevent one of the hippos from dismounting

Also, it would be great if you can find a way from stopping the Knights from being displaced when they mount

Click to expand...

Ah right, I forgot to address one of the issues! The problem is simply that if the mounted unit was not created by the trigger, it does not have any units to unhide. I can fix this pretty quickly You'll find that the already placed knight unit and the already placed hippo unit can not unmount - that's the issue I know to exist. Unless you are experiencing something different, in which case - that's not good lol

As for the displacement on the knight units, I'll look into it.

I'll have a new update in about an hour, thanks again!

Thing_I said:

You'll find that the already placed knight unit and the already placed hippo unit can not unmount

Click to expand...

You can just enumerate the map on initialization and register any units that are preplaced. That wouldnt fix other problems like summoning though, so it would be good to leave a note about it.

KILLCIDE said:

One of the Knights won't dismount when you mount the other knight the same time

Click to expand...

I can't reproduce this. How did you get them to simultaneously cast?

Simultaneously was not the right word. If you have them both selected, and you quickly swap you should see it happen.

Maybe I unintentionally fixed that error. I can't get it to happen Next time you're checking this, if you could make sure to try that again I'd be curious if it is fixed.

Needs Fixed

• Some of your variable names are way too generic. You should add similar prefixes between all your variables to ensure smoothness when users import it into their map
• Mount (Hidden ability) should be a configurable variable
• Something tells me you just uploaded this without reading the rules. A lot of the "errors" I'm seeing could have been avoided had you read them.

Suggestions

• I think MD_con_RiderIsPriority should be configurable for each unittype
• Unit-type of (Triggering unit) should be stored into a variable instead of calling the function it however many times it takes you to find the right one
• What is the purpose of storing MD_con_PickupRange into Temp_Real?
• Avoid repeating function calls

Status

KILLCIDE said:

Some of your variable names are way too generic. You should add similar prefixes between all your variables to ensure smoothness when users import it into their map

Click to expand...

1.) Do you mean on my Temp variables? Is this a requirement? If so, whoops

I think MD_con_RiderIsPriority should be configurable for each unittype

Click to expand...

2.) Completely agree! I'll do that as well.

What is the purpose of storing MD_con_PickupRange into Temp_Real?

Click to expand...

3.)The purpose of storing PickupRange into Temp_Real is because Temp_Real is later modified to the range of the closest unit if it is shorter than Temp_Real. Therefore, the first time Temp_Real will be the maximum range that a unit can be called from.

It's in this bit here.

Avoid repeating function calls

Click to expand...

4.) Unfortunately I'm not sure what exactly this means :/ If you could point it out, I'd probably be able to understand.
(Getting out of order here, but)

Mount (Hidden ability) should be a configurable variable

Click to expand...

5.) I thought that'd make things a big clunky originally. I think that having configurable mount/dismount abilities would be more important because they are the abilities that are actually seen (If I'm making any sense here.) If you have another reason as to why to make specifically that one configurable, I'd be interested to hear!

Something tells me you just uploaded this without reading the rules. A lot of the "errors" I'm seeing could have been avoided had you read them.

Click to expand...

6.) ... I confess.

Thanks a lot for dedicating your time to my system instead of just junking it. I know it isn't terrible useful and is probably rather broken compared to the standards of the site. But that's why I'm so glad you're putting time into helping me!

Thing_I said:

Do you mean on my Temp variables? Is this a requirement? If so, whoops

Click to expand...

Yes it is. Its one of the rules:

Thing_I said:

The purpose of storing PickupRange into Temp_Real is because Temp_Real is later modified to the range of the closest unit if it is shorter than Temp_Real.

Click to expand...

I would rename Temp_Real to something with like ClosestDistance so its more clear.

Thing_I said:

Unfortunately I'm not sure what exactly this means :/ If you could point it out, I'd probably be able to understand.

Click to expand...

Instead of calling (Triggering unit) or (Picked unit) multiple times, store it into a variable and reference the variable instead. This goes for all function calls, not just these two variables. Anytime you see parentheses, its a function call.

Thing_I said:

If you have another reason as to why to make specifically that one configurable, I'd be interested to hear!

Click to expand...

Because you have the ability hardcoded. If the user transfers the map, the ability will be replaced with whatever similar id the user has in their map. They would have to go through your code and manually replace all the wrong abilities with the right one. Having it as a single configurable variable makes it so that they only have to change that one variable from the config trigger since your code references the variable, and not the direct ability. Again, this is one of the rules:

KILLCIDE said:

Because you have the ability hardcoded. If the user transfers the map, the ability will be replaced with whatever similar id the user has in their map. They would have to go through your code and manually replace all the wrong abilities with the right one. Having it as a single configurable variable makes it so that they only have to change that one variable from the config trigger since your code references the variable, and not the direct ability. Again, this is one of the rules:

Click to expand...

Unfortunately both of them are hardcoded. Tsk tsk. I'll make these revisions tomorrow afternoon. I'm in no hurry to get this approved, so take your time with other things (I don't want to be a burden with all of the revisions I need)