Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Message icon:

Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview

Topic Summary

Posted by: Wisp
« on: September 24, 2017, 11:00:45 AM »

Original post has been updated with a new build.
Posted by: Wisp
« on: June 09, 2017, 04:10:25 PM »

Setup strings are loaded before any TP2 code runs and there is no existing mechanism for having them reloaded. As such, HANDLE_CHARSETS is of no use here. Additionally, a feature for converting from UTF8 to local 8-bit encodings would be nearly obsolete as soon as the shell menus got their voyage to out behind the shed, so I'm not expending any non-trivial effort on it.
Posted by: AL|EN
« on: June 05, 2017, 02:21:21 PM »

Translated component names will not be displayed correctly unless they are encoded in something compatible with UTF8; fixes to mods will be required; the good news is that UTF8 is fully supported and will work for all platforms

To fix this issue, you have to:
1. Implement this request:,29492.msg337542.html#msg337542
I don't know if this would be an in-demand feature, but how hard would it be to create an inverted version of HANDLE_CHARSETS, i.e. distribute .tra files in UTF-8 encoding and convert at install to Windows codepages?
UTF-8 is the default encoding for many modern text editors, and when mod authors receive translations via email or PM, the translated lines will usually be in UTF-8 (unless the translated files is a CP-encoded attachment). So, this could be a handy feature.
as it will allow for having language-specific characters properly displayed at the console. And it will allow for direct modification of the files at "popular code hosting sites"
2. Ask modders/mod hosting maintainers to adapt mods.
3. If there will be complains by the Windows user, tell them to use Windows 10 Creators Update to not see strange encoding issue for text displayed during installation in the text console.
Posted by: Wisp
« on: June 03, 2017, 09:39:05 AM »

I use qmake on Linux, where you run the qmake binary to create the Makefile and then run make to build the program.
On Windows, the path of least resistance was using Creator. Creator is essentially an IDE by/for Qt. You open the .pro file and (IIRC) in the bottom left corner, there're some buttons for running the program (which will first build it).
As per the second link I posted, there's supposedly some way of creating an Xcode project, which I guess allows you to build the program that way.
Posted by: subtledoctor
« on: June 03, 2017, 09:20:28 AM »

Thanks. I have Xcode 5.1.1 installed (the most recent version that supports 10.8 ), which has support for C++ 11. And I installed Qt 5.3.2 (also the most recent which supports 10.8 ), which also installed "Qt Creator" or whatever it's called. I can open the .pro file in either app, but not sure what to do then...
Posted by: Wisp
« on: June 03, 2017, 03:56:54 AM »

I'd first check if a package manager like Homebrew has Qt.
Otherwise, you can download something from, here.

Regardless, you may also want to read this, which deals with integration with XCode and various things specific for macOS.
Posted by: subtledoctor
« on: June 01, 2017, 10:12:23 PM »

I'd love to try to build this for macOS... but I don't really know how to "build" things.  I can probably learn - I learned Weidu! - but I probably need some nudging in the right direction.

I just downloaded Xcode 5.1.1, which the interwebs tells me supports C++ 11.  I'm looking into what Qt is and whether/how I can get v5 onto my system.

Anyone want to provide some guidance?  (Feel free to PM me here or on G3 to avoid polluting this thread with my ineptitude...)
Posted by: Wisp
« on: March 25, 2017, 04:47:45 PM »

Now the component-selection view looks a bit like this: link. FORCED_SUBCOMPONENTs are handled by having the first subcomponent starting out already selected and making it impossible to deselect all subcomponents in the grouping. I shall hold off on introducing GROUPs, in favour of putting a Select-All tristate checkbox up by the Components label. AL|EN's concerns have been addressed by popping up the something-is-a-happening window that is used for component-installations for uninstallations, as well. It is also not possible to close it while things are a-happening.

Now I'm off to tame the wild beast of component requirements. I may have to resort to boolean algebra. If you don't hear from me within a month, I have most likely perished in the attempt.
Posted by: AL|EN
« on: March 19, 2017, 01:10:58 PM »

It's possible, but advised against, to close the GUI widget you need to enter input should the mod ask for some; if you do so, and the mod does, the install will block indefinitely, possibly leaving your game in an inconsistent state; maybe it should not be possible to close the widget

Definitely should be impossible, if someone doesn't want such component, installation of the components should be finished and uninstalled. People will close it in the middle, repeat installation and the whole installation will go crazy.

Maybe there should be some sort of thing happening to let the user know it's a long-running uninstall; currently it just happens transparently in the background (and will block other requests to WeiDU)

Definitely user should know that something is going on under the hood. Long uninstallation/reinstallation could take some time and who knows what people will try to do (rur the game?) before it will finish.

Posted by: Galactygon
« on: March 19, 2017, 02:17:15 AM »

Yes, I see now. I have no other qualms about radio buttons.

Do you think drop-down boxes can be used in READLN-type of commands with a fixed range of values? I get the gist READLN ought to be something we should do away with in favor of .ini files.
Posted by: Wisp
« on: March 18, 2017, 09:14:23 PM »

I'm not sold on combo boxes for this. First, there's no way of displaying the SUBCOMPONENT common name. Second, there's no natural way of not choosing one of the subcomponents (I mean, you probably can have an empty row or something, but it's a complete hack). Third, aside from probably looking eye-wateringly ugly [1], it's going to clash with the check boxes, with both very different looks and modes of interaction, whereas radio buttons blend in, in both of these regards (I'll grant you that whether this is good or bad is probably subjective). Lastly, the longer the subcomponent name, the worse the aesthetics are going to be assaulted (to say nothing of the possibility of combo boxes of different lengths).

1. Don't look without goggles or something: link; I think it's telling that it is outright difficult to find screenshots of this combination, with most of the hits you do find being horror shows from Windows XP, I mean there's your stuff of nightmares.
Posted by: Galactygon
« on: March 18, 2017, 03:14:00 PM »

I'd say yes ideally with an expandable tree menu. Atm I cannot imagine a solution for components that are part of multiple GROUPs. For subcomponents, it feels more intuitive to have drop down menus or something visually distinctive to prevent the user from confusing them with GROUPs. As most of us know subcomponents are mutually exclusive while GROUPed components aren't.
Posted by: Wisp
« on: March 18, 2017, 12:16:04 PM »

After a bit of work, the component-selection window looks a bit like this. The nested components are subcomponents. The intention is that these should use radio buttons rather than checkboxes, but that's not done yet.

Question: should GROUPed components be nested as well? Subcomponents that are also part of a GROUP would be nested one level further in, under the GROUP. I don't find scrolling the list for cdtweaks to be particularly laborious, and most mods are smaller. Nesting GROUPs could help with selecting components (since you could select the entire GROUP with one click; selecting every component of cdtweaks IS laborious), but is that something people do and is it better than some kind of "Select All" button? Given the radio-buttonness of subcomponents, not nesting GROUPs would help subcomponents stand out (selecting all components in a set that included subcomponents would select the first subcomponent of the grouping).
Posted by: Wisp
« on: March 12, 2017, 04:23:44 PM »

Current head depends on on WeiDU's devel branch.
Posted by: DavidW
« on: February 28, 2017, 01:19:37 AM »

On the basis of a quick, provisional test...: