Galaxy Editor Pitfalls

[Dan]

According to Dan: "A function of type action CAN return a value if you would like it to"

Well, This guys said so at least:

http://www.udmod.com/showthread.php?697-Basic-Trigger-Editor-Tutorial

For the Action and Condition definitions it’s almost the same thing, but an Action Definition don’t need to return a value unless you want it too.

But the editor keeps freezing up on me right now when I try.

 

[Dave312]

I'm pretty sure actions can't return a value. It is just a subroutine of commands to perform.

The reason they have separated actions and functions is so the GUI can determine how to handle them (Ie an action can just be called and nothing done with it, but something must be done with the value returned by a function, such as storing it to a variable).

What I'm not too sure about is why they have separated conditions and functions. Both can return any type of variable and they could be used interchangeably, so why have both?

 

[Dan]

What I'm not too sure about is why they have separated conditions and functions. Both can return any type of variable and they could be used interchangeably, so why have both?

conditions can only return boolean values. but if you mean that functions of TYPE condition are the same as a "new condition definition" then you would be correct. (though again both only return booleans). it's just total convenience i guess.

 

[Dave312]

conditions can only return boolean values. but if you mean that functions of TYPE condition are the same as a "new condition definition" then you would be correct. (though again both only return booleans). it's just total convenience i guess.

Well when I was making that post, I thought that conditions could only return booleans as you have said. However I decided just to double check and it turns out that I was wrong. The default return type is boolean, but you can actually change it to whatever you want. So it brings me back to my point, what is the difference except that one is labelled as a condition, and the other as a function?

 

[SerraAvenger]

Well when I was making that post, I thought that conditions could only return booleans as you have said. However I decided just to double check and it turns out that I was wrong. The default return type is boolean, but you can actually change it to whatever you want. So it brings me back to my point, what is the difference except that one is labelled as a condition, and the other as a function?

The usage in the GUI.
actions can only be used in Action places,
functions can only be used as parameters to actions, conditions, events and functions,
conditions can only be used in Condition places,
events can only be used in Event places.

Of course, if you use customscriptaction, you can use them wherever you want. This is why there is no reason for such a difference at all.

EDIT: "can determine how to handle them"
They are all handled and compiled the same. The only difference is as to whether they appear in the GUI menu or not, depending on the place you're trying to add code to.

 

[Ancanus]

Best newly-introduced pitfall: DRM (defined as The Man sticking it up to me for being a legit customer)

I can't edit maps if I do not authenticate with Battle.Net.
(Also, Battle.Net is down for maintenance.)

 

[SerraAvenger]

Wasn't that a feature?

 

[Builder Bob]

Wasn't that a feature?

It amazes me what can pass as features these days. If it's a one time thing, then it's somewhat ok I guess. However, it only makes more fuel to the piracy necessity they're trying to combat.

 

[D.V.D]

Im pretty sure they added the battle.net login to the editor because of the large group of people who were not even part of the beta that still sued the editor. Also, we don't know if its a one time login thats needed to use the editor.

 

[SerraAvenger]

It amazes me what can pass as features these days. If it's a one time thing, then it's somewhat ok I guess. However, it only makes more fuel to the piracy necessity they're trying to combat.

EDIT: Sorry, my fault. I just misread.

I read it as: "I have to make sure that I'm the creator of the map or I can't edit it"

 

[Dave312]

A new pitfall that I have only noticed with patch 16 is the model paths are now done as being dependant on the ID of the unit. So for example, the model path of the marine is Assets\Units\Terran\Marine\Marine.m3. However if you duplicate the model, its ID is automatically set to Marine2 because Marine already exists. However this means that the model path for the new marine model is automatically set to Assets\Units\Terran\Marine2\Marine2.m3. Seems a little stupid to me.


EDIT: Having a space in the search fields causes massive headaches. It took me 20 minutes to work out why the Decal item was missing from my doodad palette, despite there appearing to be no restrictions placed on the list.

 

[Builder Bob]

A new pitfall that I have only noticed with patch 16 is the model paths are now done as being dependant on the ID of the unit. So for example, the model path of the marine is Assets\Units\Terran\Marine\Marine.m3. However if you duplicate the model, its ID is automatically set to Marine2 because Marine already exists. However this means that the model path for the new marine model is automatically set to Assets\Units\Terran\Marine2\Marine2.m3. Seems a little stupid to me.


EDIT: Having a space in the search fields causes massive headaches. It took me 20 minutes to work out why the Decal item was missing from my doodad palette, despite there appearing to be no restrictions placed on the list.

If this change does what I think it does, I am actually happy about it. It was annoying when duplicating objects that some fields would keep the name of the id of the unit being duplicated. I'd rather have the fields stay as ##id## so they got their values from the id of the current object.

I may have misunderstood. In that case, please correct me.

 

[Dave312]

If this change does what I think it does, I am actually happy about it. It was annoying when duplicating objects that some fields would keep the name of the id of the unit being duplicated. I'd rather have the fields stay as ##id## so they got their values from the id of the current object.

I may have misunderstood. In that case, please correct me.

While I can see the benefits in such cases, most often people want to use the same model but for a new unit. It is here that when you change the name, it resets the models to new paths to match the new name. Which means that you need to go back and reset the paths to the ones you want. I found this to mean duplicating a model to be near pointless as I would have to go through and set the values manually anyway.

 

[Builder Bob]

While I can see the benefits in such cases, most often people want to use the same model but for a new unit. It is here that when you change the name, it resets the models to new paths to match the new name. Which means that you need to go back and reset the paths to the ones you want. I found this to mean duplicating a model to be near pointless as I would have to go through and set the values manually anyway.

Yeah, it's a good point when talking about models. While maybe not optimal, I think you could circumvent this behavior by changing the name of the model object so it isn't the same as the actor's id before you start duplicating.

 

[Strilanc]

That model one is devious. The actor/unit thing is already confusing, but then they *%&# up the model paths. The new paths even look legit if you don't pay close attention!

 

[Ancanus]

What is the use case of duplicating a model?

 

[Dave312]

I was doing it because I was using the marine model as a dummy model with which I would replace with something else in the future.

However the same thing happens with actors as well. I was trying to make a new tank which would use all the same models as a siege tank. As such I duplicated the Siege Tank actor and changed its name to Battle Tank. However it then decided to change all of the models to "Battle Tank" which did not exist. Thus I had to go through and change everything back to "Siege Tank" for it to work properly. It really defeats the purpose of duplicating the actor in the first place.

 

[Ancanus]

I was doing it because I was using the marine model as a dummy model with which I would replace with something else in the future.

However the same thing happens with actors as well. I was trying to make a new tank which would use all the same models as a siege tank. As such I duplicated the Siege Tank actor and changed its name to Battle Tank. However it then decided to change all of the models to "Battle Tank" which did not exist. Thus I had to go through and change everything back to "Siege Tank" for it to work properly. It really defeats the purpose of duplicating the actor in the first place.

Weird, I'm unable to replicate.

I duplicated the Marine actor, double-clicked it, changed the name to Battle Marine, the ID to BattleMarine, and it still uses Marine as the model.

Did you perhaps change the unitName token?

 

[Dave312]

I don't think I did, however I just tried to replicate the issue and failed. I'll keep working on it and see how it goes.

 

[Builder Bob]

I'd like to add to the list that reals are very imprecise. I'm trying to create a rigid body model, but am having a hard time doing so because of this imprecision.

Really starting to get annoyed and disappointed with the editor by now...