How to force a pink (edited) data field?

[Zwiebelchen]

I fucking hate that localized hotkey thing in the object editor. Whenever I define a hotkey that just so happens to match with the original hotkey of the ability it is based off, I constantly have to deal with "broken" hotkeys in other language versions.


Is there a way to force-overwrite a black data field in the editor with a pink (= edited) entry, even if the value is the same as the default value?

 

[Dr Super Good]

Yes you can force overwrite the field, however probably not from the object editor.

In the object editor files you can declare the overwrite and it will take precedence even if the same on some locales. However I think the WorldEdit object editor lacks this, like it lacks many features.

 

[Xonok]

If you open up the field and write the value you want, it will apply even if it's the default. That's how it works for me at least.

 

[Zwiebelchen]

I found a workaround for this.
It seems that when I use LUA to set the hotkey, the field gets marked as pink even if it's the same value as the default. I guess this is because LUA writes directly into the AbilityData.slk.

Again, LUA saves the day. Damn, I wish I had learned LUA back in the days when I started mapping; could have solved SO MANY problems.

 

[Ezekiel12]

With localized hotkey you mean customkeys.txt, right?

Lets say I make a new ability (A000) based on Bladestorm (AOww).
If I do not alter the hotkey of A000 in any way, are you saying that A000 will use the localized hotkey defined in customkeys.txt for AOww?

If not please explain the problem so I can understand it.

 

[Zwiebelchen]

Lets say I make a new ability (A000) based on Bladestorm (AOww).
If I do not alter the hotkey of A000 in any way, are you saying that A000 will use the localized hotkey defined in customkeys.txt for AOww?

Correct.
And if I try to alter the hotkey, but set it to the same as before, the editor will still use the one defined in customkeys.txt.

 

[Ezekiel12]

And if I try to alter the hotkey, but set it to the same as before, the editor will still use the one defined in customkeys.txt.

Which makes sense because the object files only note down changes from the base object.

But does this mean that using localized hotkeys for newly created abilities (as in the upper example where the game uses the customkeys.txt hotkey of AOww for A000) is only possible via the object files?

Or asking the same question in another way: what would I have to write in the .slk file's hotkey field of A000 that the game uses a (to the map maker unknown) predefined localized hotkey of AOww for my new bladestorm ability A000?

 

[HerlySQR]

I found a workaround for this.
It seems that when I use LUA to set the hotkey, the field gets marked as pink even if it's the same value as the default. I guess this is because LUA writes directly into the AbilityData.slk.

Again, LUA saves the day. Damn, I wish I had learned LUA back in the days when I started mapping; could have solved SO MANY problems.

I don't get it, what did you to make them appear as pink? (I know the user is inactive, but maybe someone else can answer).

 

[Elprede]

The Object Merger tool, which came bundled with JNGP, could make the fields appear changed, even if the value is the same as default.
Refer to Lua Object Generation for more information.

 

[HerlySQR]

The Object Merger tool, which came bundled with JNGP, could make the fields appear changed, even if the value is the same as default.
Refer to Lua Object Generation for more information.

I never understood this, but even if I could, I'm using the Reforged Editor, so I don't think I can use it.

 

[Elprede]

I just found out that Wurstscript's object editing libraries are also capable of making fields appear pink, even if the value is equivalent to default.

 

[HerlySQR]

I just found out that Wurstscript's object editing libraries are also capable of making fields appear pink, even if the value is equivalent to default.

Maybe it could work.