XConsole 2.5.0 rc1

[UT99.org]

I am reporting that one as a bug. The way you have used Auth is user entered commands to authenticate with the services on the network. The biggest IRC variants today that have already overtaken IRC ten to one in terms of popularity, they don't use these IRC services. But will require a real login like vintage private IRC networks. At the moment you are having it send out your auth instead of a login when it should be using login parameters and before the connection is finished. If you have it listen specificially for a raw '001', 002 003 events you will know when it is connected, and this is the correct time when the authentication to irc services should be sent as well

Haven't tested the rest a whole lot but a couple things I noticed.

For some reason the timedemostats messages don't show. I thought it was postrender calls but ran some commands and saw the HUD was still changeable. open dm-codex?game=unreali.DeathmatchGame / summon unreali.invisiblity

At first I thought you may have forgotten to pass the postrender calls on to it's parent class resulting in loss of timedemo messages and some hud issues with some of the older unreal 1 pickups. Since a lot of your functions require effort to know what they are I was only throwing out an educated guess that it's the postrender you have called. My tests say it's something else

Can you please stop the console snapping back to full size, the default console's job of keeping the size it was last left on was much better. This seriously cannot be considered a feature as it is an utter annoyance. If I re-size it, press the console key to hide it, then press again to open it I am once again needing to re-size it to where I had it

[~V~]

Have found that the console autosizes when in a window. Fixed now.

I checked 'timedemo 1/0' and 'stat fps' it they seem to render fine here, although I noticed that it wasn't showing in console (fixed that now).
XC doesn't affect the normal hud rendering, so why timedemo isn't working for you I can't say.

I'll look into the IRC auth a little later and then put up an update.

[UT99.org]

Wouldv've been as simple as adding super.postrender if that's the function. But why the invis worked though I cannot explain. It's the text on the right that is meant to always be seen, it is only being shown when the console is on the screen. I'll leave it over to you as I'm fairly sure my UT is as vanilla as it gets and even changed renderer trying with and without XConsole

[~V~]

Ok, I see what you mean now. The Super.PostRender() was in the wrong place.

The problem with using UT's IRC link is that it's not possible to listen to raw events at all. I think that I will rename the 'Auth' command to 'Autocmd' or some such, as it's a bit misleading: it could be used for any command at all, not just authing with nickserv. It does check that the link is established before sending the command though, so it should be good enough for authing. The problem is that UT's IRC link doesn't support any sort of authing at all, so given that and not being able to see raw events I don't think that there's much I can do about it.

[UT99.org]

OK thanks. I understand the IRC is the newest part of your console, hope you consider making it more future orientated before the last release of this. While it is an auto command it's also an auth as far as services are concerned, only it's sending it at the wrong time. Obviously it's sending fine on servers that don't require a login but could be tweaked to send on actual connect and not the moment the server is either not sending anything and awaiting a (login) response, or sending the RAW commands to say it is connected properly. Once again I refer to my posts involving listening on sockets and the UScripted MV reporter. And I should mention the code isn't as hard to find as your postrender function or did I already point that out hehe

[~V~]

The IRC part has been around for a while now so it's not really new. The newest part is actually the coloured console textarea which has had to have a lot of tweaks to get it to work with Pure etc.

But anyway, I'll need to look at the link code to see when it connects. And to see if I can get it to send a raw command. The other thing I could do is to use my own IRC link class, but when I first did this some years back I would get kicked for it by LAS140. I don't remember if Pure kicked for it, but obviously it would mean that people need to choose which one to use based on what server they are playing on, which would be annoying to say the least. Anyway I'll take another look at the link code.

[UT99.org]

Please do! And add auto connect when game opened checkbox. Let folks know what the outcome of the UTPure and League Assault tests are and see what the consensus is. Cheers

[~V~]

Oh by the way, can you give me a few IRC servers that accept login like this? It'll give me some way of testing. At the moment I only use freenode, oftc, globalgamers and quakenet and I don't know if they accept login/auth in that way.

[UT99.org]

I don't want to tell you any irc daemons to download because theres a virused version that is quite common and one of the only viruses I know of on linux. UnrealIRCd should work on whatever distribution you have but you might need some compilers. The setup itself should let you define usernames and passwords

Here is the mIRC command I use for twitch with name and password parameters: //nick TwitchName | server irc.twitch.tv TwitchName twitchpassword -i TwitchName TwitchName TwitchName TwitchName

I believe the 4th parameter on most networks is meant to be the "realname" field and should start with a : colon and can be longer than one word. You'll have to check to see if the others are important or not


This can all be set up manually in the server section of mIRC as well

for more testing purposes:

No pass required (viewing only not typing): http://widget00.mibbit.com/?server=irc. ... n133713371

Same as above mIRC method: http://widget00.mibbit.com/?server=irc. ... TwitchName


Couple more unrelated to irc things I want to add. I'm getting the same crash message every time i disconnect from a server I am spec in to go to another server. It's an xconsole message I get (I'll shot it next time if you want). Both servers vanilla with default serverpackages.

Second, the majority of your rightclick menu names have localiztion counterparts for 95% of the words. Spread hroughout the game, with only a couple words I can see that you would have to manually put translations for. If you had variables set these set each time the game (console) loads and then could add support for a good 5 languages. As a bonus, have over-ride vars that the user can configure to easily add user created ones [if they feel the grammar is wrong when you run startup translations]. Actually, they would no doubt want full control re-write all the menus with new custom commands hehe

[~V~]

I will give twitch a go but like I said without access to the raw commands and input it'll be hard to see what's happening.

All the menus names are writable already. The ones I include are more for illustration purposes only, but the aren't hard written in code, they are in XConsole.ini

[UT99.org]

I will give twitch a go but like I said without access to the raw commands and input it'll be hard to see what's happening.

Sorry try this

You shouldn't have trouble setting up an ircd, unreal ircd has always been a leader. But make sure the file is from an official source or the md5 lines up with an official source md5. It will tell you the compilers and what you are missing when you install it. Been a while for me, I know you must configure it before using it, probably need to manually open and edit the config files, somewhere you will find examples on the allowing of authorised users

All the menus names are writable already. The ones I include are more for illustration purposes only, but the aren't hard written in code, they are in XConsole.ini

K that's good. I'm no expert on int files you couldn't put them in one of those? Either way, the localize function would be a really nice feature

[~V~]

I already run ngircd on my server. I will see if it supports such logins

Localized strings go in the chosen language .int files, which for Spanish, Italian etc. would be .est, .itt etc. It would mean I'd need to supply all those with correct translations. This would be a major rewrite of the menuing system so I won't be looking at until the next version.

[UT99.org]

I already run ngircd on my server. I will see if it supports such logins

You probably found this already, from http://ngircd.barton.de/doc/sample-ngircd.conf

# Global password for all users needed to connect to the server.
# (Default: not set)
;Password = abc

The below one is NOT what I was talking about, but it is all too common, it usually tells the connectin client to use a raw message to the server with AUTH RandomLettersHere, it's an added annoyance but for servers that do use it it's quite easy to copy and paste or have it auto. I'd say just leave it but hold off your nickname (services) auth until the 001 is recieved

# Normally ngIRCd doesn't send any messages to a client until it is
# registered. Enable this option to let the daemon send "NOTICE AUTH"
# messages to clients while connecting.
;NoticeAuth = no

Localized strings go in the chosen language .int files, which for Spanish, Italian etc. would be .est, .itt etc. It would mean I'd need to supply all those with correct translations. This would be a major rewrite of the menuing system so I won't be looking at until the next version.

Yes, many of the words you are using in your menus can already be translated from existing language files, I only saw one on the main rightclick menu that you would have to use your own translation files. Didn't check anywhere else but your idea would be better anyway. I'd prefer to not keep requesting features as I see it going downhill. Sounds like you don't want to make changes because it takes you twice as long to hide your code. I'll request a final one anyway, a simple ACE tab, copy the buttons from UTDC, add mutate commands. You probably won't get far trying to do anything more complex than that from client-side. And while UTDC still supports windows 95/98 it doesn't support 64bit clients. In fact if the player isn't admin all these tabs are a waste of space and shouldn't even be visible

Anyway goodluck, you probably know UWindows better than everyone else by now as well as the console class but I can't even peek at your UWindows layout so cannot be of much more help

[~V~]

I doubt it would be possible to use words from other .int files like that. Normally the particular section header has to match the [package.classname] that the strings are needed for.

For one thing the menus are made from a struct containing the name and command. Something like Menu[0]=(Name="whatever", Command="do something here"). AFAIK only strings can be localised.
So to make those localised they would need to be converted to separate string arrays, line MenuName[0]="whatever" MenuCommand[0]="do something here". And that would mean rewriting all the functions to suit... I don't really see that as a way forward. Structs are very useful for cases like this. And it is much much easier for people to edit one line with the name + command, rather than scrolling about the file looking for the corresponding other bit.

A different approach might be to make separate Menu.ini's, one for each language and ask for volunteers to make suitable inis for their language which they could send me. Then it would just be a case of including them in the zip and people would just need to rename whichever one they needed to Menu.ini (or whatever it may be called).

I was thinking of doing something like that for the help commands, which are now in a separate ini file.

About ACE: the reason why I haven't made an ACE tab is because of ACE Manager, which does a pretty good job IMO. Also it's impossible to get ACE HWIDs and MAC hashes in a purely clientside mod; it needs to be a server actor too. ACE Manager is all that. There is also a Nexgen ACE Plugin which seems pretty good.

I don't mind suggestions for new ideas/additions/improvements at all. I don't hum and har over some things without reason though. I usually have to weigh up the benefits for the average user versus making stuff too complex. If I sound reluctant then hiding code isn't the reason. I only obfuscate the code in the actual console subclass. Everything else is (or should be) human readable. So people can still read/learn from the open bits. There are 55 other classes that /aren't/ obfusctated. My build scripts auto obfuscate the packages I need obfuscating anyway. And it only takes a few seconds. It's not like I'm byte hacking it by hand.

[UT99.org]

Well, if we're going to go 'round in circles.

HALF OF YOUR MENUS ALREADY default HAVE WORDS. YOU CAN TAKE THEM FROM THE START OF THE MATCH, AND IMPLEMENT THEM

do you need screenshots?


THEREFORE, at the BEGINNING. you set a bunch of variables BASED ON THE LANGUAGE USED. YOU WILL THEN HAVE CHANGED THE MAJORITY OF THE CONSOLE INTO THAT LANGUAGE

Code: Select all

I doubt it would be possible to use words from other .int files like that. Normally the particular section header has to match the [package.classname] that the strings are needed for.

totally irrelevent excuse #1

Code: Select all

For one thing the menus are made from a struct containing the name and command. Something like Menu[0]=(Name="whatever", Command="do something here"). AFAIK only strings can be localised.

good , you made use structs and are thinking of int files. A lot of people don't do that. Now you just have to write in full and copy and paste some with a translator if you want them in another language. Although many already exists

Code: Select all

So to make those localised they would need to be converted to separate string arrays, line MenuName[0]="whatever" MenuCommand[0]="do something here". And that would mean rewriting all the functions to suit... I don't really see that as a way forward. Structs are very useful for cases like this. And it is much much easier for people to edit one line with the name + command, rather than scrolling about the file looking for the corresponding other bit.

If that's how you coded it, and I'm guessing you use the saveconfig and the order is not what you want. Example of what your config file looks like

=hello1
=hello2
=hello3
goodbye1=
goodbye2=
goodbye3=

Then use a thirdparty program to generate the config file in whatever order you want. And in a mere spend 30 seconds. And thats me on windows. (excuse #2) Don't be giving linux a bad rep

Code: Select all

A different approach might be to make separate Menu.ini's, one for each language and ask for volunteers to make suitable inis for their language which they could send me. Then it would just be a case of including them in the zip and people would just need to rename whichever one they needed to Menu.ini (or whatever it may be called).

Nobody is going to send you anything, the game is dead

Code: Select all

I was thinking of doing something like that for the help commands, which are now in a separate ini file.
About ACE: the reason why I haven't made an ACE tab is because of ACE Manager, which does a pretty good job IMO. Also it's impossible to get ACE HWIDs and MAC hashes in a purely clientside mod; it needs to be a server actor too. ACE Manager is all that. There is also a Nexgen ACE Plugin which seems pretty good.

Once again, the classes are open source. There is more than one file in that ACE pack that tells you exactly how you would go about it, that's if you can't intercept the output of the mutate commands. If you think I'm wrong on this I'll test it and give you your apologies just say so

Code: Select all

I don't mind suggestions for new ideas/additions/improvements at all. I don't hum and har over some things without reason though. I usually have to weigh up the benefits for the average user versus making stuff too complex. If I sound reluctant then hiding code isn't the reason. I only obfuscate the code in the actual console subclass. Everything else is (or should be) human readable. So people can still read/learn from the open bits. There are 55 other classes that /aren't/ obfuscated. My build scripts auto obfuscate the packages I need obfuscating anyway. And it only takes a few seconds. It's not like I'm byte hacking it by hand.

I don't believe a word of this. You are hiding the code because you are getting around Pure is my guess. Would half those windows even exist on a pure server. That's why I think you hide the code

I WAS making a program to help with making UWindows, to save myself some time as well as others. If this isn't your big untold excuse and you really are looking for new improvements.

I cancelled out my UWindows maker the moment I realized I had started in the wrong place. The tabs should've come first and then worked my way to the contents of what is on each of the tabs. Further, I'd like a glimpse into how you do the IRC styled window which would be of huge interest to me. And a couple friendly questions If I may (after this long friendly post), so Second question, what about a menubar window like at the top of the game. Is that at all achievable, you do have too many tabs which might be impeding you to make more. Not so much that, but are menubars in UWindows possible?

You see I really want to learn this UWindows stuff first so I can finish the project, I can make things that people down the line will like and use, like pseudo desktop icons in their UWindow acting much like a regular desktop, coupled with the menubar at the top. And start adding things like music players to stop that annoying background music. A cache/packages open explorer and anything else advanced the client might want to see. Thanks for listening to my advice though, I will help you through your excuses just say the word. And by the way Twitch will overwhelm ye ole IRC when the new consoles arrive, even though PCs have almost already put both the console and regular IRC completely to shame, when streaming really picks up people are going to want to be connected to the chat and issue commands and have their little external bots running it's just facts

Apologies for rambling, yelling, making assumptions and accusing people of using excuses that I didn't think were real excuses