Ciuine

Thanks Duvodas, can probably make new action slots or a pin menu off of this info.

The object.AddToProjected function has always been only available to objects that are recognized by the Detectors. These include astral monsters (look at the add-on AMIT), quest/vendor NPCs, group/raid members, detected devices, so on.. This function has never included enemy/friendly players. This is due to the projectedInfo being usable to check real ranges. As for your 2d/3d widget problem, it would seem there is some invisible panel in the way. Perhaps some priority adjustments might fix this?

Like DoTTimer?

Use AddonManager to hide or turn off the add-on. This will hide the sword. You could also download NCT instead which is an "upgraded" form of CT_Total that I developed and no longer has the sword. It instead uses ConfigWindow and the /cw slash command as a means to change configuration.

You can get the local zone = cartographer.GetCurrentZone().sysZoneName for all of the allods you want and then plug them into local zonesMapId = cartographer.GetZonesMapId(zone) to get their dynamic Id numbers for that client run supposing that they only change once a client load.

Yeh, I've been working on mapping out instances for my FullMap add-on. Here's how you get the names. Code: local allod = userMods.FromWString(cartographer.GetCurrentZone().allod)local zone = cartographer.GetCurrentZone().sysZoneName The allod is not a system string, so it will be different in each languaged client of the game. However places like the Gipat dungeon do not have a sysZoneName in certain versions of the game. The zone is going to be a system string and will remain the same throughout clients so long as it is used. This will give you things like Inst_Empire1End or other things. You'll have to note simple distinct differences in these names. Like Laguna Boil is ZomeEmpire3 note the m instead of n; don't ask me why that's the case, it just is. Sadly, in certain versions of the game Oreshek and Darkblood Citadel share the same sysName, so the only difference is the non-standard allod name and the dynamic mapId.

That's odd. Try changing the Refetch() function to this; Code: function Refetch() TIMER = TIMER + 1 if TIMER >= 5 then if unit.GetTransport(avatar.GetId()) then local trans = unit.GetTransport(avatar.GetId()) if transport.CanDrawInterface(trans) then GetShipData(trans) else mainForm:Show(false) end else mainForm:Show(false) end common.UnRegisterEventHandler(Refetch, "EVENT_SECOND_TIMER") end end

RaidPlates Просмотреть файл EN: Replaces the standard raid plates display. RU: Заменяет стандартный интерфейс рейда. Последняя проверенная версия работы аддона: 2.0.08.14 Автор Lafayette Добавлен 07.12.2018 Категория Старые аддоны (от игры 1.0 - 3.0)  

Edit: Done, feel free to correct translation errors in the discussion forum for this add-on.

This add-on is not set-up for the previous 2.0.06 buff changes from unit to object related events, this might cause errors in the RU client. I'll try and update it to get it up to the current 2.0.08 version of the game while remaining backwards compatible. Edit: Test this, modified to work with 2.0.08. File: RaidPlates.zip

Type /shuddnd when ShipHUD is open.

I mean the Visor, the "viewing device" on the second floor. If you look at your ship through that, you'll notice the same bug in that state managed and default in-game add-on.

Can you take a screenshot of the visor for those same two cannons? I don't know what would cause the devices to stop showing properly. Probably an id change caused by some issue.

Most of these bugs are actually out of my hands. The cannon problem seems to come about from two like named cannons being put on the bottom deck next to each other. The game then treats these two cannons as if they are in the exact same slot due to bad codes. (The state managed visor add-on shows the exact same bug. If this is incorrect, inform me of such and I'll see what is wrong and if it is fixable.) The when going on to ship and it doesn't load all devices is a table sending "problem" from the client. When the ship is facing the wrong direction in the hangar the player can no longer "see" the rear devices so these devices are not sent as transport devices when requested via transport.GetDevices(); the same is true of some occasions when the player dies/teleports and loads the transport too slowly, this results in zero devices loading. I will try and put in a second timer that activates after a player boards a ship that attempts to "re-fetch" the data after five seconds and then deactivates. For the battle problems, could you explain in more details? What stops changing information and at what percentage? I know that the game tends to sometimes "ignore" 90%+ to 100% changes.

Could either of you test this fix? I don't have a RU astral ship to test this on myself. File: ShipHUD.zip

Don't mind me.

Thank you, this error makes more sense. I'll correct the issue for the RU client. They have changed the transport health functions. So I will have to make adjustments according to that. I do not have the new functions in front of me at the moment so it might take a few days for me to get this up.

I don't understand the question. The bordering? SLA posted up this table a while back. Code: Global( "ItemQualityColors", { [ ITEM_QUALITY_JUNK ] = "0xFF9C9C9C", -- Gray [ ITEM_QUALITY_GOODS ] = "0xFFDDDDDD", -- White [ ITEM_QUALITY_COMMON ] = "0xFF00E629", -- Green [ ITEM_QUALITY_UNCOMMON ] = "0xFF2384FF", -- Blue [ ITEM_QUALITY_RARE ] = "0xFFC244FF", -- Magenta [ ITEM_QUALITY_EPIC ] = "0xFFFF8400", -- Orange [ ITEM_QUALITY_LEGENDARY ] = "0xFF00FF9A", -- Mint [ ITEM_QUALITY_RELIC ] = "0xFFE1FF44", -- Lemon } ) Just convert them to RGBA for background colors.

For Cursed items, you take the name of the item's class value and add "Cursed". So for ITEM_QUALITY_RARE it is "RareCursed". There are examples of this made by Duvodas in my WhisperWindow add-on.

I'll look into the bug when I get the time, KAEUral.

Make an add-on with a (UIRelatedTextures).xdb referencing the texture you want then use w:SetBackgroundTexture(common.GetAddonRelatedTexture("NameofTexture")) in addition to what icreator posted.

This puts a lot of faith in the server to produce an exact 1000 millisecond duration. I think it is better off shooting for values less than 2000 milliseconds; to correct for a "hopefully unattainable" maximum of 1000 millisecond server delay.

Yes, but that would be pretty heavy work on the part of the addon developer. I think a shell with just names/qualities and where they drop would be complex enough.

Due to the dynamic ID system that Allods has, retrieving stat info for items would be impossible without having seen the item each time the client is started. However, it would be very possible to do the old school AtlasLoot that had no stat info and only displayed boss drops, if y'all can remember that.