Jump to content
The Dark Mod Forums

Translating the TDM GUI


Tels

Recommended Posts

Brilliant! Nice work, Tels. ^_^ You've got a lot more patience for the GUI system than I do.

 

Thanx, but my patience wears thin already ;)

 

@Echelon: I have fixed the bug with the keys and the lockpicks not working, it was because the inventory category was refered by the code as "Keys", but the are now named "#str_12345" or something.

 

At the moment only one issue remains with the map in Score to Settle (and maybe in other missions). I am not sure of the extend, but it might be that some missions have either entities with "inv_category" set and it is set to "Keys" or "Maps" manually. In this case we probably need to fix this at entity spawn time, by comparing the category to the english name - if it matches, correct it on the fly to "#str_something".

 

However, for this I first need to write a translation manager which can handle more than one dictionary, D3 by default only loads the language specific one. That bug is filed under http://bugs.angua.at/view.php?id=2797 and needs to be fixed, anyway :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

@Echelon: I have fixed the bug with the keys and the lockpicks not working, it was because the inventory category was refered by the code as "Keys", but the are now named "#str_12345" or something.

 

 

 

but this fix solves the same problem even in the FM? Because I had the same problem with the mission Awaiting the storm, and I hope it's the same problem of GUI-Training (sorry, if I misunderstood).

 

--------

By chance you can send the modified files "exclusive", so that in the meantime can translate the FM without problems?

Edited by ECHELON
Link to comment
Share on other sites

but this fix solves the same problem even in the FM? Because I had the same problem with the mission Awaiting the storm, and I hope it's the same problem of GUI-Training (sorry, if I misunderstood).

 

I hope so, I had that problem in "A score to settle". But there is at least one more bug, so please be patient, you can hopefully test it soon.

 

--------

By chance you can send the modified files "exclusive", so that in the meantime can translate the FM without problems?

 

I need to prepare the package manually, this is a lot of work and it is quite big so I am hesitant to bundle and upload it only to redo it tomorrow :)

 

Sorry, but you have to wait a bit, I am not the fastest :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I need to prepare the package manually, this is a lot of work and it is quite big so I am hesitant to bundle and upload it only to redo it tomorrow :)

 

Sorry, but you have to wait a bit, I am not the fastest :)

 

Sorry Tels for my hurry. :unsure:

Edited by ECHELON
Link to comment
Share on other sites

Sorry Tels for my hurry. :unsure:

 

No problem :)

 

In related news, Diego has kindly offered to translate TDM into Portuguese. Unfortunately, in their infinite wisdom, the wise guys at ID decided that they only allow a fixed set of strings for the variable "sys_lang". Now guess which language isn't in that list? :wacko: In fact, the list contains only English, French, German, Polish and there is another list with Russion, Korean, Chinese and Japanese and nothing else :angry:

 

*throws hands up in the air*

 

Sometimes I want to strangle the guy responsible for adding a fixed limit *everywhere* even when there is nothing gained by it, but everything lost... -_-

 

...

 

Anyway, I will provide a new package to the translator soon, there are only a handful bitmaps left and the code bug (selecting keys, lockpicks and items in the inventory) has also finally fixed for good. Stay tuned!

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Tels, for the package you send us, there is a big problem. When i start a FM, appears "joint 'hips' not found for attachment position 'hip_sheat_l' on entity 'angry guy'" or "joint 'hips' not found for attachment position 'hip_sheat_l' on entity 'trainerguard2_sitting'.

Edited by ECHELON
Link to comment
Share on other sites

My apologies, I packaged all changed files, but forgot that some of them changed not due to translations. Package updated :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Mmm...

Now the FMs start, but the problem with keys remains. perhaps should i do some change in fm file.map?

 

No, it should work. Have you also copied the "tdm_game01.pk4" file?

 

Also, if you open the console, does the game say some thing?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

No, it should work. Have you also copied the "tdm_game01.pk4" file?

 

Also, if you open the console, does the game say some thing?

 

:D

 

Tels, now is a lot better.

Now all keys and lockpick work, except one: the "chest key" of training mission. : /

 

Ah, another small problem. The accented letters are not seen. Honestly, I prefer the apostrophe, but if you can convert it fine too.

Link to comment
Share on other sites

:D

 

Tels, now is a lot better.

Now all keys and lockpick work, except one: the "chest key" of training mission. : /

 

Ah, ok, I'll look into this. It is probably some wierd custom-made key :)

 

Ah, another small problem. The accented letters are not seen. Honestly, I prefer the apostrophe, but if you can convert it fine too.

 

Yes, that is normal, since I did not have yet time to look into making them into the font. Don't worry, it will be done in time for v1.07, but its a lot of work. :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Tels, if it is a big job, put apostrophes. ;)

 

No worries, eventually I will create the font :)

 

In the meantime, I had only little time, and this weekend is booked, too. So there was not much progress, but I did get some things done:

 

* Some of the inventory item names are rather long, esp. things like "Vorhängeschlosschlüssel" in German :) So I added a bit of magic to the code to detect if there is more than one line, and if so, set a flag for the GUI. The GUI in turn shifts the text up by a few pixels, depending on whether there are 1 or 2 lines. That means instead of that:

 

post-144-131185611844_thumb.jpg

 

You get this:

 

post-144-131185612879_thumb.jpg

 

while original items still look like before. (I guess if we really want to go fancy we could even sep. the two lines and move them a few pixels closer together. But thats for another day)

 

* grayman poked me, and I got around to fix the bug with the chest in the training mission (or any other chest/lock for that matter). It was a silly mistake of mine, that the compiler should have warned about, :ph34r: but we did disable "unused warnings". IMO we really should turn them back on. Anyway, it is fixed now. :blush:

 

* translate two more bitmaps in the "New Mission" menu, making it finally complete. (Now only 6 bitmaps plus the headers in the Settings menu remain).

 

 

The package on bloodgate.com has NOT been updated yet. Will do this once more things have piled up as I am running out of time today.

 

Thank you for your patience! Oh, and does anybody have the new strings yet translated? ;)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Needed to take a break away from the GUI, and only loosely related is the result: To aid the translation it is nice to have pre-made entities that have already the proper names like "#str_12345" so they get translated easily. So I set out to add a few more keys, and noticed we could use a few more different key models.

 

Here is the result:

 

post-144-131185786503_thumb.jpg

 

The far left is the new "Strange Key", perhaps for some ancient temples. (Not quite happy with the model yet, and it cannot be skinned). Next to it are three new entities with the same model as "Mysterious Key".

 

Edit: I refined the shadow hull, and made a variant, too:

 

post-144-131186837197_thumb.jpg

 

This model was created as a huge model in DR, and then scaled and exported as ASE. It is high-poly (about 1600 polys), and contains a low-poly shadow model and a simply collision model.

 

Since I was abit shocked how many polys rings/rounded shapes eat, I added a low-poly version. Above that are for reference only three skinned examples of the low-poly versions of that model (about 400 polys + shadow model + CM). The entity is currently setup so that it switches from about 3m distance - even with the spyglass, it is almost impossible to spot the switch. From about 25m distance the model is hidden - that is not visible without the spyglass.

 

However, I am not really worried about the polygons, as D3 can push a lot of them, and typically you'll never have more than a few of these keys in one place, anyway. (Now someone will prove me wrong by filling a room with them :D

 

Anway, the high-poly looks quite cool even when you lean in close. There are, of ocurse, matching inventory icons.

 

Oh, and in case you want to know how it was built:

 

post-144-131185813344_thumb.jpg

 

:D

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

* Some of the inventory item names are rather long, esp. things like "Vorhängeschlosschlüssel" in German :) So I added a bit of magic to the code to detect if there is more than one line, and if so, set a flag for the GUI. The GUI in turn shifts the text up by a few pixels, depending on whether there are 1 or 2 lines. That means instead of that:

 

 

Wonderful. :o

 

I have almost finished translating the entire file italian.lang . :D

Edited by ECHELON
Link to comment
Share on other sites

Progress report:

 

* ECHELON has proved to be invaluable for TDM :):wub: He has found quite a few mistakes in the translations files, and also updated the italian translation quite a bit. Thank you!

* added the russian nancy font Keeper Riff did send us

 

So after incorporating and fixing the italian changes, I worked on the idea that if we provide generic names, then even old FMs can have f.i. their inventory items properly translated w/o any changes (basically by looking up "Chest key", reversing it to "12345" and then displaying the translated result). There are two prerequisites we need for this: 1) the strings should be in their own number block, so we need only to keep a reverse dictionary of these, and also do not by accident mis-translate something and 2) there must be enough strings to make the translation (almost) complete.

 

So I moved the "keys" to a new block, and then wrote a script to filter the FM map files for inventory names, thinking I'lladd the 4 or 5 we are missing. Boy was I wrong! Even after removing lower/upper case variants, I was left with over 100 different key names. Ouch. In the end I added most of them, except the ones who have a name like "John's Key", because there would be an endless supply of these and we'd never get all of them. So these can later (if the framework is done) be added to each FM.

 

Anyway, the packages on my server have been updated. (Thanx to grayman for compiling!)

 

The missing strings are now sep. into a file for each language and under "strings/missing/". It would be cool if the other translators could find a moment to look into them and send me an update.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

* ECHELON has proved to be invaluable for TDM :):wub: He has found quite a few mistakes in the translations files, and also updated the italian translation quite a bit. Thank you!

happy to have been useful. :D

 

So after incorporating and fixing the italian changes, I worked on the idea that if we provide generic names, then even old FMs can have f.i. their inventory items properly translated w/o any changes (basically by looking up "Chest key", reversing it to "12345" and then displaying the translated result). There are two prerequisites we need for this: 1) the strings should be in their own number block, so we need only to keep a reverse dictionary of these, and also do not by accident mis-translate something and 2) there must be enough strings to make the translation (almost) complete.

 

So I moved the "keys" to a new block, and then wrote a script to filter the FM map files for inventory names, thinking I'lladd the 4 or 5 we are missing. Boy was I wrong! Even after removing lower/upper case variants, I was left with over 100 different key names. Ouch. In the end I added most of them, except the ones who have a name like "John's Key", because there would be an endless supply of these and we'd never get all of them. So these can later (if the framework is done) be added to each FM.

 

Mmm.

 

Tels, I do not understand this business of the FMs key.

 

Want you to insert strings into for example italian.lang, so that they are already translated without changing the file.map (of FM)?

 

If so, I fear it is rather useless for several reasons:

-The huge number of keys.

-the need to change also the file.map to translate the objectives. Moreover, having already translated some FMs, I can say that will be replaced also the file.xd and file.gui.

Therefore, the present state of things, is not currently possible to provide any form of FMs multi-language.

 

The only way I can think would be to "copy" the system installation of Thief 2 FMs. That is, for example, in the folder books there are various sub- folders named Italian, English, German ... etc.; when you install the FM, is installed the sub-folder of the language have you choose, for example with the DarkLoader 4.3.

 

Also, I already tested that the chests work, if you translate the keys in the FM file.map.

 

Perhaps I misunderstood what you mean. :D

 

 

p.s. However, wonderful work for the key/lockpick fixed problem. :D

Edited by ECHELON
Link to comment
Share on other sites

Mmm.

 

Tels, I do not understand this business of the FMs key.

 

Want you to insert strings into for example italian.lang, so that they are already translated without changing the file.map (of FM)?

 

If so, I fear it is rather useless for several reasons:

-The huge number of keys.

-the need to change also the file.map to translate the objectives. Moreover, having already translated some FMs, I can say that will be replaced also the file.xd and file.gui.

Therefore, the present state of things, is not currently possible to provide any form of FMs multi-language.

 

The only way I can think would be to "copy" the system installation of Thief 2 FMs. That is, for example, in the folder books there are various sub- folders named Italian, English, German ... etc.; when you install the FM, is installed the sub-folder of the language have you choose, for example with the DarkLoader 4.3.

 

Also, I already tested that the chests work, if you translate the keys in the FM file.map.

 

Perhaps I misunderstood what you mean. :D

 

It is not all clear in my own head, I am just making preparations and planning. But here is how it (can/is supposed to) work:

 

Right now, an FM can be translated in two ways:

 

* the author can write "My Golden Key" in the FM, and an translator "edits" the FM by creating a second FM; and replaces the hard-coded string with "Mein Goldener Schlüssel". This is the traditional way done in TDM and it is very error prone, and tiresome and it also means you cannot switch from one FM language to the next.

* the FM author can use strings like "#str_12345" and the engine replaces this with the right translation. This is how D3 worked, and how TDM should work after I am finished with this.

 

The advantage of the latter is that if you want to update the translation of an FM, you can do so without ever touching the FM by itself. There is only one FM PK$ package, but the translation can live in an additional PK4 file. It can also be updated with TDM (f.i. if there is a spelling error in a string). Huge benefits.

 

For the latter, tho, there are two problems:

 

* new FMs need to include a dictionary which contains "#str_12345" - but D3 (traditionally) supported only one dictionary file. This means that we either need to add all strings to the TDM directory (which is not feasible at all), or add support for a second dctionary. E.g. the code first refers to the FM specific dict (if it exists!), then if not found, to the TDM build-in dict, and if still not found, falls back to English. I can fix this in code, but there is still the problem that if TDM only brings the most basic strings, than each FM would need to replicate simply things like "Builder", "Dark Key", "Library" in their own FM dictionaries. That is not only error prone, but also data duplication.

* Even with code support for FM specific directories, old FMs are left out. Now, we cannot fix them completely (for instance the readables), but we can at least make a stab at the HUD and inventory names. That means TDM needs to have at least some basic strings in its dictionary. That we can can re-translate "inv_name" "Library Key" to "inv_name" "#str_12345" and display the correct "Bibliotheksschlüssel" in the HUD. It won't be complete, but even an 80% solution goes a looong way to fix the issue for non-native speakers.

 

 

So the plan is:

 

* add support for FM specific directories

* add the most basic strings to TDMas a first (but not nec. 100%) stab

* make a code stab at re-translating inventory names, weapon names and so on (e.g. things the user sees) when we find them in the TDM directory, but the FM has the English name hard-coded. (Btw, the same fix is already in place to re-translate hard-coded category names like "Keys", because otherwise the FM might break, because the code now expects "#str_12345" (ot whatever it is) instead).

 

Hope this is more clear?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

It is not all clear in my own head, I am just making preparations and planning. But here is how it (can/is supposed to) work:

 

Right now, an FM can be translated in two ways:

 

* the author can write "My Golden Key" in the FM, and an translator "edits" the FM by creating a second FM; and replaces the hard-coded string with "Mein Goldener Schlüssel". This is the traditional way done in TDM and it is very error prone, and tiresome and it also means you cannot switch from one FM language to the next.

* the FM author can use strings like "#str_12345" and the engine replaces this with the right translation. This is how D3 worked, and how TDM should work after I am finished with this.

 

The advantage of the latter is that if you want to update the translation of an FM, you can do so without ever touching the FM by itself. There is only one FM PK$ package, but the translation can live in an additional PK4 file. It can also be updated with TDM (f.i. if there is a spelling error in a string). Huge benefits.

 

For the latter, tho, there are two problems:

 

* new FMs need to include a dictionary which contains "#str_12345" - but D3 (traditionally) supported only one dictionary file. This means that we either need to add all strings to the TDM directory (which is not feasible at all), or add support for a second dctionary. E.g. the code first refers to the FM specific dict (if it exists!), then if not found, to the TDM build-in dict, and if still not found, falls back to English. I can fix this in code, but there is still the problem that if TDM only brings the most basic strings, than each FM would need to replicate simply things like "Builder", "Dark Key", "Library" in their own FM dictionaries. That is not only error prone, but also data duplication.

* Even with code support for FM specific directories, old FMs are left out. Now, we cannot fix them completely (for instance the readables), but we can at least make a stab at the HUD and inventory names. That means TDM needs to have at least some basic strings in its dictionary. That we can can re-translate "inv_name" "Library Key" to "inv_name" "#str_12345" and display the correct "Bibliotheksschlüssel" in the HUD. It won't be complete, but even an 80% solution goes a looong way to fix the issue for non-native speakers.

 

 

So the plan is:

 

* add support for FM specific directories

* add the most basic strings to TDMas a first (but not nec. 100%) stab

* make a code stab at re-translating inventory names, weapon names and so on (e.g. things the user sees) when we find them in the TDM directory, but the FM has the English name hard-coded. (Btw, the same fix is already in place to re-translate hard-coded category names like "Keys", because otherwise the FM might break, because the code now expects "#str_12345" (ot whatever it is) instead).

 

Hope this is more clear?

 

yes, i understood that.

But there is a big problem: though with this system simply translate the file.lang, the fan mission also HAVE to change to translate the mission objectives, the names of the bodies, books, briefings, etc. ...

In any case, the fan missions will be changed REGARDLESS.

Edited by ECHELON
Link to comment
Share on other sites

yes, i understood that.

But there is a big problem: though with this system simply translate the file.lang, the fan mission also HAVE to change to translate the mission objectives, the names of the bodies, the names of objectives, books, briefings, etc. ...

In any case, the fan missions will be changed REGARDLESS.

 

I know. :) But that doesn't mean we can help the existing missions a bit. (the whole "get 80% done with only 20% of the energy spent" thing)

 

Also, the plan is that you need to change the mission only once, and then afterwards each additional language requires no longer an FM change.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

But there is a big problem: though with this system simply translate the file.lang, the fan mission also HAVE to change to translate the mission objectives,

 

Yes, this is exactly what I don't understand. Not understanding the objectives and mission briefing are the most significant barriers to playing a mission...whether or not you know the name of a key seems pretty trivial by comparison (you've already got a picture to show you what it is). Why do all this work to automate the latter when the former is going to require manual changes anyway?

Link to comment
Share on other sites

Yes, this is exactly what I don't understand. Not understanding the objectives and mission briefing are the most significant barriers to playing a mission...whether or not you know the name of a key seems pretty trivial by comparison (you've already got a picture to show you what it is). Why do all this work to automate the latter when the former is going to require manual changes anyway?

 

Because automating the latter is an 1h job that _I_ already did, while the latter is a huge task that _I_ cannot do? ;)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Maybe I should explain a bit better, my last post might come across as snarky. :blush:

 

We need a translation of all things - even simple things as key names, because as funny as it sounds, I wouldn't have known what a "Porch Key" is a few days ago.. while I am perfectly capable of understanding almost all objectives :) Plus it is just to make the translation complete.

 

So this means we need a list of key names and their translations, anyway. Now when we had the FM translation framework ready, we might add them to *each* FM. Or we can add the basic ones to TDM *now*, check that they are correct, shown correct etc. and then the FM translators only have to worry about the non-standard, specific strings.

 

So in the end we do not more work, but less (because we translate things like "Library Key" only once).

 

Also, as I allued to eaarlier, the "old" model of translating an FM by copying it is not sustainable with 45+ FMs and 5+ different languages, because it means among other things that the mirrors will need to hold 5 times as much data. It also means that whenever an FM is updated, each language would have to be updated, too (which generally nobody does). That is why I want to sep. the FM and the translation itself.

 

Anyway, I hope I find some more time this week to hammer out the code - atm I spent all the time on the GUI and strings itself and pushed only the nec. code changes. Once the TranslationManager code is in the mod, you'll see what I mean by all this and how easy it will be usable for mappers.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Also, as I allued to eaarlier, the "old" model of translating an FM by copying it is not sustainable with 45+ FMs and 5+ different languages,

 

Yes, I would agree with you. But if the old method isn't sustainable, then what is the point of translating the inventory? There is not going to be any way to automate the translation of briefings and objectives, which are the major barrier to playing a mission. If a player can't understand the objectives, what difference does it make if they know what kind of key they have?

 

To me it seems like lowering the door-handle so someone in a wheelchair can reach it, when the door is at the top of a flight of stairs. Maybe I'm missing something.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...