15 replies to this topic

[Maxxxel]

-buff.type returns wrong values

 

[Aristo]

Warning for "normal users":

This is not the place to post stuff why your game doesn't work.

If you need help post here:

http://gamingonstero...um/159-support/

[iSaga]

This is not the place to post stuff why your game doesn't work.
If you need help post here:
http://gamingonstero...um/159-support/

Its a developer issue for fere to see. Most scripts are broken because of buff.type

[AnhDuc]

This is not the place to post stuff why your game doesn't work.

If you need help post here:

http://gamingonstero...um/159-support/

[RMAN]

Its a developer issue for fere to see. Most scripts are broken because of buff.type

 

Omg you two 

Aristo wasnt saying that to Maxxxel, he was leaving that as a warning so users dont start to flood like they did here.
----------------

Some bugs:

• Anyway, [.dir] always returns Vector(0,0,0) 
• It seems that EXT suddenly closing issue is related to the process running out of memory.

[iSaga]

<p>

Omg you two
Aristo wasnt saying that to Maxxxel, he was leaving that as a warning so users dont start to flood like they did here.
----------------
Some bugs:

• Anyway, [.dir] always returns Vector(0,0,0)
• It seems that EXT suddenly closing issue is related to the process running out of memory.

Lol hard to see that with no context lol.

[Aristo]

Lol hard to see that with no context lol.

I already deleted some posts And i sent a post about that.

 

Warning for "normal users":

 

This is not the place to post stuff why your game doesn't work.

If you need help post here:

http://gamingonstero...um/159-support/

[Feretorix]

Noted, I will see if I can solve this.

[iSaga]

Buff.type is broken.
.dir is broken
Trinkets/wards are broken.(or have a different item id) returns 0.
Getping still broken

[LastLuaBender]

missileData.owner and missileData.target are returning numbers instead of GameObjects

[sikaka]

missileData.owner and missileData.target are returning numbers instead of GameObjects

 

 

That's how it's always been. You then have to pair them up by iterating through the various heroes/minions you might be associating them with.

 

Here's a snippet from Alpha for example - just showing how I've been handling missileData in previous patches without API issues.  

function __DamageManager:OnAutoAttackMissile(missile)
	local owner = ObjectManager:GetObjectByHandle(missile.data.missileData.owner)
	local target = ObjectManager:GetHeroByHandle(missile.data.missileData.target)
	if owner and target then
		--Damage tracking logic snipped out
	end
end

function __ObjectManager:GetObjectByHandle(handle)
	for i = 1, LocalGameHeroCount() do
		local target = LocalGameHero(i)
		if target and target.handle == handle then
			return target
		end
	end
	for i = 1, LocalGameMinionCount() do
		local target = LocalGameMinion(i)
		if target and target.handle == handle then
			return target
		end
	end
	for i = 1, LocalGameTurretCount() do
		local target = LocalGameTurret(i)
		if target and target.handle == handle then
			return target
		end
	end
end

[iSaga]

That's how it's always been. You then have to pair them up by iterating through the various heroes/minions you might be associating them with.

Here's a snippet from Alpha for example - just showing how I've been handling missileData in previous patches without API issues.

function __DamageManager:OnAutoAttackMissile(missile)
	local owner = ObjectManager:GetObjectByHandle(missile.data.missileData.owner)
	local target = ObjectManager:GetHeroByHandle(missile.data.missileData.target)
	if owner and target then
		--Damage tracking logic snipped out
	end
end

function __ObjectManager:GetObjectByHandle(handle)
	for i = 1, LocalGameHeroCount() do
		local target = LocalGameHero(i)
		if target and target.handle == handle then
			return target
		end
	end
	for i = 1, LocalGameMinionCount() do
		local target = LocalGameMinion(i)
		if target and target.handle == handle then
			return target
		end
	end
	for i = 1, LocalGameTurretCount() do
		local target = LocalGameTurret(i)
		if target and target.handle == handle then
			return target
		end
	end
end

+1

[Deftsu]

That's how it's always been. You then have to pair them up by iterating through the various heroes/minions you might be associating them with.
 
Here's a snippet from Alpha for example - just showing how I've been handling missileData in previous patches without API issues.  

function __DamageManager:OnAutoAttackMissile(missile)
	local owner = ObjectManager:GetObjectByHandle(missile.data.missileData.owner)
	local target = ObjectManager:GetHeroByHandle(missile.data.missileData.target)
	if owner and target then
		--Damage tracking logic snipped out
	end
end

function __ObjectManager:GetObjectByHandle(handle)
	for i = 1, LocalGameHeroCount() do
		local target = LocalGameHero(i)
		if target and target.handle == handle then
			return target
		end
	end
	for i = 1, LocalGameMinionCount() do
		local target = LocalGameMinion(i)
		if target and target.handle == handle then
			return target
		end
	end
	for i = 1, LocalGameTurretCount() do
		local target = LocalGameTurret(i)
		if target and target.handle == handle then
			return target
		end
	end
end

this actually drops performance quite a lot, handle is basically index to use with the objectManager (the 10000 size one), you didn't even have to iterate to get the object, will talk with fere about that ^^

[LastLuaBender]

this actually drops performance quite a lot, handle is basically index to use with the objectManager (the 10000 size one), you didn't even have to iterate to get the object, will talk with fere about that ^^

 

I think there is a much larger performance issue here. Since there are no object callbacks, instead of looping the objects once in the api and having a bunch of callbacks for different events, all scripts will loop them seperatly. I don't pretend to know exactly how things like Object() and ObjectCount() are implemented but I'm pretty sure there is quite the performance improvement to be gained here. Simple create/remove events would already handle most use cases.

[sikaka]

this actually drops performance quite a lot, handle is basically index to use with the objectManager (the 10000 size one), you didn't even have to iterate to get the object, will talk with fere about that ^^

 

 

Holy god I wish that had been documented. it would have saved me SO MUCH TIME and improved performance a lot. Thanks will re-write that soon.

 

 

I think there is a much larger performance issue here. Since there are no object callbacks, instead of looping the objects once in the api and having a bunch of callbacks for different events, all scripts will loop them seperatly. I don't pretend to know exactly how things like Object() and ObjectCount() are implemented but I'm pretty sure there is quite the performance improvement to be gained here. Simple create/remove events would already handle most use cases.

 

Rito spaghetti code is mostly to blame. I agree that there should be a central way to get object related callbacks (emulated from the api, even if not 100% reliable) but I think that's unlikely to happen - a central script can be made to do that as a fallback though.  

 

I would settle for (and have requested a couple times) something as simple as an OnRecache(Minion/Hero/Etc) event that triggers when lets say the minion cache has been updated in memory...

[iSaga]

The gos overlay seems to not match actual position. Drawing, mouse clicks and spell cast range is off slightly. It will either misclick or not activate spells according to actual range


Will test further

Tested on a few resolutions. Also I have been developing on the same computer with no settings changed. Will show screenies when I can.