The Infamous New Game Inventory Bug

A refuge for those migrating from the fallen DXEditing.com and a place for general discussion relating to Deus Ex editing (coding, mapping, etc).
Post Reply
Cybernetic pig
Illuminati
Posts: 2284
Joined: Thu Mar 08, 2012 3:21 am

The Infamous New Game Inventory Bug

Post by Cybernetic pig »

So I thought I had fixed this shit way back, but I was wrong. Nobody has managed it, but there must be a way. Clearing the inventory once the New Game -> choose difficulty button is pressed seems to be the best way, but I'd occasionally get crashes when doing this (loop through the inventory and destroy one by one). How about just killing the existence of the inventory, period? It should be re-initialized once the new game starts anyhow. Any other ideas?
Hanfling
MJ12
Posts: 406
Joined: Sun Oct 04, 2009 6:54 pm

Re: The Infamous New Game Inventory Bug

Post by Hanfling »

Cybernetic pig wrote:Nobody has managed it, but there must be a way.
Does HX count?

However, for SinglePlayer here is the roadmap what one needs to do to properly fix it.

The basic problem is that the game does a travels with bItems and manually tries to reset all player state, which is bad and error prone. So the basic idea is to travel with bItems=False into the new game (or training) and pass the selected options when starting inside the URL.

Everything like StartNewGame, StartTrainingMission, ShowIntro, etc. calls Level.Game.SendPlayer(), which is implemented as

Code: Select all

//
// Send a player to a URL.
//
function SendPlayer( PlayerPawn aPlayer, string URL )
{
	aPlayer.ClientTravel( URL, TRAVEL_Relative, true );
}
The last parameter is bItems and specifies whether everything marked with travel should be carried over to the next map or not. We don't want to do that, so the first thing to do is to replace those Level.Game.SendPlayer( aPlayer, URL) with aPlayer.ClientTravel( URL, TRAVEL_Relative, False ).

The next thing to do is to start turning everything inside MenuScreenNewGame which directly sets properties on the player into options which get added to the URL like SkillPointsAvail, the selected skills, playername.

One classic way to grab URL params is to handle it in GameInfo's InitGame. You could save everything which is needed, so you can later initialize the playerpawn in AcceptInventory (or somewhere else). Things like the CombatDifficulty setting etc, should probably even for SP not be a playerpawn property but instead be handled by the gameinfo. You could store it there and autoappend it to the URL when travel etc. Note that the GameInfo is actually saved to the disk and gets loaded back (and not replaced) when you revisit a map.

Further notes:
- Inside event AcceptInventory( Pawn PlayerPawn ) you can check whether the PlayerPawn has a NanoKeyRing and if not start initialize him.
- There is also some weired stuff going on with the 'PlayerTraveling' flag, one probably needs to account for it.

Basically no big deal, it just can end up in quite some work walking through messy ION code. But this is the way to go for actually fixing this bug and not hacking around it.
I demand my DXE User ID back. Launcher for DeusEx, Rune, Nerf, Unreal & Botpack. HX on Mod DB. Revision on Steam.
Cybernetic pig
Illuminati
Posts: 2284
Joined: Thu Mar 08, 2012 3:21 am

Re: The Infamous New Game Inventory Bug

Post by Cybernetic pig »

"Basically no big deal"

:/

Sounds like a massive pain in the ass to me. This lazy hack works:

Code: Select all

function ShowIntro(optional bool bStartNewGame)
{
    local Inventory anItem;
	
	if (IsInState('Dying')) GotoState('PlayerWalking');

	if (DeusExRootWindow(rootWindow) != None)
		{
	      ForEach AllActors(class'Inventory',anItem)
	      {
	          anItem.Destroy();
              DeleteInventory(anItem);
	      }
         DeusExRootWindow(rootWindow).ClearWindowStack();
		  DeusExRootWindow(rootWindow).hud.belt.ClearBelt();
        }
Tried many different hack attempts, probably took just as long as it would to tackle the problem at its core as you did. In the end I thought fuck it, just delete every inventory item in existence before Level.Game.SendPlayer() is called when starting a new game.
Cybernetic pig
Illuminati
Posts: 2284
Joined: Thu Mar 08, 2012 3:21 am

Re: The Infamous New Game Inventory Bug

Post by Cybernetic pig »

Of course this would probably be looked down upon in a professional environment, but on the players end they won't even be able to tell a damn thing except that it is fixed, and the user experience is all I really give a crap about.
Hanfling
MJ12
Posts: 406
Joined: Sun Oct 04, 2009 6:54 pm

Re: The Infamous New Game Inventory Bug

Post by Hanfling »

Cybernetic pig wrote:Of course this would probably be looked down upon in a professional environment, but on the players end they won't even be able to tell a damn thing except that it is fixed, and the user experience is all I really give a crap about.
Development of HX really changed the way I approach progamming. I started it with trying to work/hackfix around ION code and thought I would get away with it, though underestimating the complexity of the whole thing, I ended up with mostly sort of hack fixed ION code. As complexity got bigger and bigger this started to didn't really work, one gets close to sth., but usually you always have some issues left which pop up and more important these are hard to pin down because of a messed up codebase which is hard to understand.

So over the time I started to rewrite/refactore more stuff and especially the threshold for doing this got fairly low and all I can say about it that it might be a lot of extra work in the first place, but it totally pays out in the long run and you won't run into any stalls because you cannot further bend the already messed up codebase.

As a rule of thumb, I basically stick too: If code looks messy and hard to understand, it's usually worth to either rewrite it from scratch or dissect it an reassemble it piece by piece. I usually clean up code starting off with the existing code and cleaning it up step by step, though sometimes I take some quite large leaps if some major design changes to the codebase are required and end up having a project which won't compile for a couple of days or even a week. Also when rewritting/overhauling something I try to make it more flexible/general in the first place so I won't run into any problems I would either need to hack around or rewrite it when adding things. Also if you add things to some parts of the code there is general a certain time where you should refactore it to account for the increased complexity as you notice the design can't handle it anymore. But all I can say about it is, I enjoy doing it and ending up with a clean codebase which you can work with instead of it working against you.

My timesplit for working on rendering is basically like 60% figuring out the best way to handle things, especially 'translating' stuff to linear rendering is awful time consuming, 35% of the times is about cleaning up code, refactoring code or moving it inside the shaders and probably not even 5% of the time is about adding new features or sth. Especially I took the first 1 1/2 year basically just cleaning up the ut436opengldrvsrc without even adding shaders or anything. It was just about adding editor support, cleaning up and refacturing the codebase, but in the end this allowed me too move on at a faster increasing pace and not just get at stall.

For editing related tools I usually spend 70% of the time writing new code, 20% maintaining existing code, and like 10% figuring out how do things. The key reason why I spent most time here on new code is plain that most parts are usually isolated from each other and it sort of works more like on a per commandlet/factory/exporter/etc. basis, so there are nearly no interdependencies and the commandlets are usually just a low three digit number of code lines. For my build commandlet on the other hand at least a large share of time went into refactoring as it got more and more complex and greatly expanded the scope it initially had.

Just my 2c.
I demand my DXE User ID back. Launcher for DeusEx, Rune, Nerf, Unreal & Botpack. HX on Mod DB. Revision on Steam.
Cybernetic pig
Illuminati
Posts: 2284
Joined: Thu Mar 08, 2012 3:21 am

Re: The Infamous New Game Inventory Bug

Post by Cybernetic pig »

Yeah, I get you...I usually do try to avoid hackjobs when possible, but ShowIntro() for example is a simple function called very rarely and if any errors occur they should be easy to pinpoint. Hopefully. It's bad practice but I spend too much time on the game as it is and I'm not paid enough to be a clean code perfectionist.

You being an engineer it is extra important to be perfect, as any fuckups can have a big chain effect on upper level scripting/all child code.
Post Reply