ID:272694
 
I have a run() procedure, which I DON'T want to slow down with stupid for() loops.

There has to be a better way to do this :

for(var/obj/O in mob.EquippedStuff) 
if(istype(O,/obj/items/equippable/Sword)) mob.icon_state="run with sword"
else mob.icon_state="run"


It loops through the mob's equipped stuff to find a sword, and if it finds one, it changes the state to run with sword.

If it doesn't it changes to normal run. I want my run() to be accurate, and I'm pretty sure a for() would slow it down a bit, if I had a few stuff equipped.
How many swords / weapons can a player equip at once?
how about using a variable when he starts to wear it and then check if it's true on the Move() proc?
In response to Stephen001
One.
In response to Danny Kenobi
That would make a check every time I press the arrow keys, which wouldn't be much efficient either.

Right now the for() only runs when it HAS to change the icon states. But I'm looking for an alternative to for().

I thought about something like this ;

var/obj/S = locate(/obj/items/equippable/Sword) in mob.EquippedStuff


But I think the above does exactly the same, since it's searching the whole list for the sword object.
In response to Andre-g1
Andre-g1 wrote:
That would make a check every time I press the arrow keys, which wouldn't be much efficient either.

Right now the for() only runs when it HAS to change the icon states. But I'm looking for an alternative to for().

Use the idea Danny had with the code you have.

if(mob.sword) // set mob.sword = 0/1 when un/equipping the sword
mob.icon_state="run with sword"


[Or a switch, if you have multiple weapons that can be equipped]
In response to Schnitzelnagler
The idea Danny had, will make Move() change the icon state regardless of what it is currently, and Move() is called a lot. It'll do multiple checks per Move() and multiple changes which are not necessary nor efficient.
In response to Andre-g1
Reading my posting, you can see that I did not recommend the event hook he suggested, but I said you should replace the code.

Replace this:
for(var/obj/O in mob.EquippedStuff) 
if(istype(O,/obj/items/equippable/Sword)) mob.icon_state="run with sword"
else mob.icon_state="run"

though
if(mob.sword) // set mob.sword = 0/1 when un/equipping the sword
mob.icon_state="run with sword"
else
mob.icon_state="run"


By which, I entrusted you have have selected a high performance event hook.
In response to Schnitzelnagler
Though, that will only work temporarily..

I plan on adding other weapons and states to run with. And having a variable for all of the weapons seems a little iffy.
thats pretty easy to do you just need to modify your icon states. So what i would do is say you just have two states that are different when carrying a sword (standing and running). Then what youll do is name those states something like "withsword" so if you only have those two states you would have a total of four states, 1 standing and 1 motion, for each with and without a sword.

Then once you equipped/unequipped a sword you would just change your icon_state to/from "withsword". Since the icons work with motion to where if you have two icon states one that is motion and one that isnt if will uses them properly.

Obviously with this method if you had other icon states the you changed to you would have to add in checks there to make sure it goes back to the right icon state after wards (unless you just use flick).

This way you would only change your icon state once when you equip it and dont bother with moving
In response to Andre-g1
At most you'd use one variable*, but I don't see why you're not just using locate().
*: Obviously you'd just set the var to a value depending on what is equipped. A derivation of this would be to change your equipment list to slot-based, or provide a separate variable for the weapon, to hold its reference.
In response to Andre-g1
Andre-g1 wrote:
Though, that will only work temporarily..

Why?
Whenever you had the for loop run, you could check for the boolean instead.
There is no difference other than in performance.

Andre-g1 wrote:
I plan on adding other weapons and states to run with. And having a variable for all of the weapons seems a little iffy.

Why do people never read what I write?

Schnitzelnagler wrote:
[Or a switch, if you have multiple weapons that can be equipped]

switch(mob.weapon)
if(1) mob.icon_state="run with sword"
if(2) mob.icon_state="run with mace"
else mob.icon_state="run"


You can even use define if you prefer that...

#define SWORD 1
#define MACE 2

switch(mob.weapon)
if(SWORD) mob.icon_state="run with sword"
if(MACE) mob.icon_state="run with mace"
else mob.icon_state="run"
In response to Kaioken
I thought locate() would do the same, since it's searching the list for the object.([link])
In response to Schnitzelnagler
I see, sorry for the misunderstanding.

And thanks.
In response to Andre-g1
Which there isn't really a problem with. Using a separate variable to flag an equipped weapon type is pretty silly; try one of the alternatives I mentioned in my previous post, as an equipment system should be able to tell what and which is equipped, and as what (slot).
In response to Kaioken
Yes, I am currently using a method similar to my mission system.

Example;

Missions = list(0,0,0,0,0) 

//The zeros are in order, S_RANK, A_RANK, B_RANK, C_RANK\
D_RANK and ERRAND


//I can easily check how many missions a person has made by using Missions[S_RANK] \
(used #define to make them the list index like: )


#define S_RANK 1
#define A_RANK 2
// (...)


I did the same for the equipment list now. By order the numbers represent HEAD, TORSO, ARMS, HAND, WAIST, LEGS and FEET.

I don't know if that's a good way of doing it. But that's what made more sense to me.
In response to Andre-g1
This doesn't seem terribly object-oriented. Presuming your weapons all inherit from one tree (for the sake of argument, obj/weapon), you might as well attach a variable to the mob that is the equipped weapon:

mob
var/obj/weapon/equipped_weapon

proc/run()
if (src.equipped_weapon != null) // Have a weapon
do_weapon_running_stuff()
else
default_running_thingy()


This also solves a potential design flaw, which is that the equipment list allows you to equip multiple weapons at once (who knows what hilarious bugs could come out of that), unless it happens to be associative, using a key for weapon.
In response to Stephen001
Why use !=? Also, I've suggested that already anyway. >_>
In response to Kaioken
Why not use !=

I have this feeling you are splitting hairs.
In response to Stephen001
Stephen001 wrote:
Why not use !=

Perhaps because it is entirely unrequired, and adding it only introduces slight loss of robustness and efficiency. Heard of boolean checking?
Page: 1 2