Mount/Dismount System

[Maxwell]

Can be usefull

 

[Thing_I]

You don't say

 

[KILLCIDE]

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

 

[Thing_I]

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

How exactly do you mean?

 

[KILLCIDE]

You only support a single unittype for the combined form.

 

[Thing_I]

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!

 

[KILLCIDE]

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

 

[Thing_I]

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

 

[KILLCIDE]

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.

 

[Thing_I]

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

 

[KILLCIDE]

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.

Hrmm looping through it seems extremely unnecessary, but whatevs.

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

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.

 

[Thing_I]

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

Hrmm looping through it seems extremely unnecessary, but whatevs.

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

 

[KILLCIDE]

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

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.

 

[KILLCIDE]

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

 

[Thing_I]

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

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!

 

[KILLCIDE]

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

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.

 

[Thing_I]

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

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

 

[KILLCIDE]

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

 

[Thing_I]

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.

 

[KILLCIDE]

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

Awaiting Update​

 

[Thing_I]

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

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

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

What is the purpose of storing MD_con_PickupRange into Temp_Real?

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.

Hidden

• Unit Group - Pick every unit in (Units within MD_con_PickupRange of Temp_Point) and do (Actions)
  • Loop - Actions
    • Set Temp_Point2 = (Position of (Picked unit))
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • (Unit-type of (Picked unit)) Equal to MD_con_RiderType[Temp_Int]
        • (Distance between Temp_Point and Temp_Point2) Less than Temp_Real
      • Then - Actions
        • Set Temp_Real = (Distance between Temp_Point and Temp_Point2)
        • Set Temp_Unit = (Picked unit)
      • Else - Actions
    • Custom script: call RemoveLocation(udg_Temp_Point2)

It's in this bit here.

Avoid repeating function calls

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

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.

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!

 

[KILLCIDE]

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

Yes it is. Its one of the rules:

To avoid name collision each system is asked to define a PREFIX.

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.

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

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

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.

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

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:

Submissions must be easy to import. Strive to require as few changes as possible when importing (e.g. use variables to store object editor data such as abilities and unit-types).

 

[Thing_I]

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:

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)