PlayerPawn input grabbing?

[Saya-chan]

Since the Console variable in the Player object has the const flag, I can't change it through uscript, so I just use:

Code: Select all

consolecommand("Set Player Console "$NewConsole);

Because this other one returns an error on compilation ("Can't assign Const variables"):

Code: Select all

PlayerPawn(Other).Player.Console = NewConsole;

That's why it wouldn't probably work well online, it would assign ALL players the same console object (Both local and remote).

Edit: Damn, I just found out how to fix it. Local player uses Viewport class and remote ones NetConnection, so I should just change the console for the Viewport. Heh, you learn something new every day.

[anth]

As in most languages, the const keyword has no meaning at runtime. That means that you CAN assign constant variables, the compiler just won't let you. Most coders just use bytehacked versions of Engine.u to get around this problem. If your bytehacked Engine.u still has the same GUID as the old engine then it will still work perfectly online. Changing the console class through a console command only works if the console hasn't been created yet. Also, a local player has no say in which consoleclass other people should use. You can change the consoleclass for Players, Viewports or Netconnections all you want, it will still only affect the local player.

[Saya-chan]

Hmmm, any clues on how to do bytehacking?

[anth]

Well, bytehacking is a pretty broad term. In your case the best solution would probably be to create a backup of your Engine.u file, then open it in a text editor, look for the variable you want to "unconst" (I'm guessing it's the console variable in your case) and then simply replace the const keyword by /*n*/. That will probably "fix" it. Don't forget to restore your Engine.u afterwards though. As an alternative you could use http://utgl.unrealadmin.org/EngineHacked.u

[Saya-chan]

Mind if I ask why the file size is so small compared to my original Engine.u? (original: 1149858B, hacked: 906599B)

PS: Anyway, instead of using that file, I did the replacement with an hex editor and came across another compile error ('LadrStatic.Static_a00' thingy), but could easily fix it (Don't know why botpack had to be recompiled, though. I've run into the same issue countless times since I started modding for UT but have no clue what causes this).

Edit: Argh! Now I have to recompile whole botpack.u every single time I reload UnrealEd. I'll use the hacked file, then.

Edit2: UnrealEd freezes whenever I compile now.

[anth]

the hacked file doesn't contain the hidden textures in Engine.u. It's only useful for compiling, you shouldn't use it for anything else.

[Max]I[muS-X]

Hmmm, I've done the hook thingy. Now I just have to find out why when I press Esc the screen just goes white, or why can't I access the console window at all.

Edit: Forget it, I fixed that. The whole thing is getting real now. Bad thing is it depends on some functions that prevent it from ever becoming net-compatible.

BUMP! I'm having this same issue! What did you do to fix it?

[Saya-chan]

Can't do anything if you don't show me your code.

[Max]I[muS-X]

Oh of course! Well like you I'm basically using the relevant (or what I know to be relevant, anyway) code in the CSHP4/UTPure code to attach the console. Here it is:

http://pastebin.com/iKnXZ87u

When I do this, the console attaches successfully. However, the console button does nothing, and the escape key just results in this:

http://img151.imageshack.us/img151/5957/escglitch.jpg

I've been trying to follow the code path from the ESC key being pressed in KeyEvent, but with no success in finding why this is occurring so far. My next step was going to be to copy ALL of the code in CSHP4's Console and see if THAT works, then filter out what's needed. But, that will take a lot of time and if I can find out exactly why I'm getting the error, it would be much better! Plus I'm not sure if that will even work.

[~V~]

Wouldn't it be easier to make (subclass) your own PlayerPawn for the game/mod you are working on and do the input grabbing there?

[Feralidragon]

Wouldn't it be easier to make (subclass) your own PlayerPawn for the game/mod you are working on and do the input grabbing there?

Subclassing a playerpawn is always a very bad idea, since many other mods already attempt to do the same (mostly security mods).
If input detection is needed, is simply better to equip the player with a custom item (inventory) with an exec function in it, and it would work flawlessly.

[~V~]

Good point

[billybill]

I couldn't compile the latest pure or CSHP source without modifying the engine.u. The "hacked" one posted here was of no use. So here is a modified Engine.u for compiling the forementioned https://anonfiles.com/file/5134f9a73e62 ... ae08706442