Cursed-Ghost: For a bit of fun I thought I'd have a go at enabling the debug feature unfortunately it doesn't appear to work
klei1984: The debug features only work in Debug builds. On the GitHub release pages you can only find Release builds that do not contain most of the debug features. The debug features are not intended for end users as they are error prone (not end user friendly).
To get a debug build from the GitHub Actions build server you need a free GitHub account. Alternatively you could build the game yourself following the
build instructions. For Windows XP you would need to set up an Ubuntu Linux computer. I uploaded the latest Windows XP 32 bit Debug build
here for reference.
Makes sense I figured it would be something like that I'm actually surprised that the debug menu on settings pane worked since this is something that for the time being at least is not really supposed to be available on the release build, well at least till it's more stable anyway, might be an idea to update the wording on the debug feature, to make it clear that this is not available on release builds just in case other people wanted to play around with it and are wondering why they can't get it working.
Cursed-Ghost: Ok so giving version 0.7.0 a look and one of the first issues I ran into is the port telling me it failed to obtain application user directory.
klei1984: Please read the
installation guideline.
I actually did already but that doesn't really address the issue I already have max installed using the dos installer since that still works on xp and then I usually just copy the
max.exe
lang_english.ini
PATCHES.RES
from the port archive and normally everything works just fine, the .portable file is not necessary because max is already portable by design since it stores its setting in the settings.ini file and not in the registry.
As for the aforementioned game_data= this shouldn’t be necessary either since max has no directory structure and therefore the port should just be looking for the game files in the same folder where the executable is, the only time this would be necessary is if the files from the port are in I folder that is different from the one where the game files are in which case then yes you would need to add a setting to tell the port where it can find the game files, I suppose for testing this can be helpful since I can just create a new folder in the max folder 0.70 and then just drop the files from the port archive there and then just set game_data= to c:\max port although really the port should actually ask the user where the game files are when they try to run the port and it can't find them rather than just giving some obscure error message, now while I can usually deal with minor issues like that manually, not everyone is necessarily as computer literate so hence the suggestion.
Cursed-Ghost: ... there are several screens that are not being resized to fit there new resolution which cause a lot of visual weirdness as you can see in this screen shot.
klei1984: These are not defects nor glitches. Menus are not scaled, fonts are not DPI aware. None of these aspects are in scope as long as work package 7 is incomplete. You can check the
roadmap where that work package stands now.
Makes sense I figure that was probably the case, I just assumed with you working on scaling that you may have taken care of the text and the other game screens while you where at it.
Cursed-Ghost: ... the computer is cheating ...
klei1984: I explained this several times already at various places... yes, computers cheat. This is v1.04 original behaviour. E.g. computers average and above learn the location of all eco-speheres and mining stations on all game reload. Master and God tier computers always see the entire map and all units there is. The original developers did these hacks in v1.04 to "make computers more aggressive".
Don’t get me wrong I get it, having said that the computer should still have to obey the same rules as the player and should not be able to see things that is out side of its radar range, otherwise what is the point of having the fog of war in the first place you may as well just get rid of it to even the playing field.
I mean right now in order to make things a bit fairer I usually play with the max spy cheat on because if the computer can see things out side its radar range then it's only fair for the player to be able to as well.
What I'm wondering is if there is a way to adjust this so that the computer has to obey the same rules as the player, with out making the higher level computer opponents stupid, I mean there has to be a better way to go about this that doesn't involve allowing the computer to cheat, which in of its self has unintended consequences like making the computer attempt suicide attacks that have no chance of succeeding, another unintended consequence is in late game when the computer can't figure out how to get past my defence grid, it just sits there doing nothing and doesn't even try, where a human might decide to use sacrificial units to draw the fire from defence turrets and only when the turrets can't fire any more do they send in the attack units to take out the turrets but I guess even god mode computers aren't smart enough to figure that out, and even if they are they aren't smart enough to pull it off.
More over give the fact that the computer does cheat this naturally leads to the player turning the computers own cheating behaviour against it and using said cheating behaviour to manipulate the computer, I do this all the time to discourage the computer from launching rush attacks against me at the start of the game by applying the max super cheat to my defence force as this is a cowardly and frustrating tactic against which there is no defence and I should know because I have tried any number of ways to stop it fair and square and I get destroyed every time since scouts can move and fire and my units can't.
which is why now I just take a dozen or so scouts and then apply the max super cheat, of course I don’t actually attack with them there just there to deter rush attacks, and usually I'll reset there stats a bit later on when I have a fair chance of defending my self by sending them to the depo and upgrading them
Unfortunately it seems in the original dev's zeal to make the higher level computer players tougher they failed to provide a proper counter to scout rushes, so what I would perhaps do to address this is make it so tanks can move and fire as well.
Cursed-Ghost: I'm also noticing that the computers behaviour seems less dynamic maybe, I'm not really sure how to describe it its like previously if I reloaded the same game from turn 1 and then play out say the first dozen or so turns each time I did the computer would make different decisions, but now the computers decision making seem more repetitive maybe so if you reload the same game from turn 1 play out the first dozen or so turns they will nearly always play out the same way. ...
klei1984: The game logic did not change, but now Computer players have much more time to think compared to MS-DOS era. There are computer algorithms that seek for best decisions to make until available time for thinking runs out or best decision is found (we are talking about milliseconds here). Note that most computer decisions are spiced up by "rolling dices", using a pseudo random number generator. But as the random number generator is a pseudo random number generator this means that as long as the seed value is the same, on reload the generated sequence of numbers will always be exactly the same. So difference in decisions will come from human input or running out of available time for thinking instead of reaching best decision. As long as computers have sufficient time in both MS-DOS and modern OS, the game will play out always100% deterministically the same way for same human input in both versions. The seed value of the random number generator is saved with the save game file when a new game is started.
Perhaps the way to address this then is to make the seed value random as well the reason I say this is because if you want to create a random number generator not only do you have to randomise the number that is generated but you also have to randomise the sequence in which those numbers are generated or your random number generator isn’t really random at all.
This way each time the dice are rolled the starting seed value will always be different thus the sequence of decisions will be different each time so you wont end up with the situation that I'm seeing where exactly the same structure get put in exactly the same place each time, and the computer makes almost identical moves each time which makes the computers actions predictable and open to manipulation by the player, making the computers actions and decisions more random/dynamic would also make playing the computer feel more like playing another human.
Cursed-Ghost: I've also had the game crash a few times as well although I don’t see any crash log in the game folder, nor do I see any error message, typically this seems to happen on reload.
klei1984: The game does not create crash dumps and most debug features are disabled in Release builds as end users have no just in time debuggers to attach the running and crashing process to. So in case of crashes there will be no logs whatsoever.
I know about the reload crashes, i even know the root cause for it, but I cannot fix it without a massive rewrite of the architecture that I attempted like 3 times already and failed.
The root case is a nasty design flaw in original MS-DOS M.A.X. (all versions). The root cause is responsible for a bunch of crashes and anomalies that were found in the past. Basically computer players are initialized not as RAII, but once they take their turns or if the uninitialized computer player data is required by another computer player.
The faults occur in the ad-hoc initialization case as this can happen in the middle of another (computer) player's turn in the middle of AI task processing... This ad-hoc init instantiates a ton of tasks that execute their begin task routine that potentially kills or cancels a lot of other already scheduled or even currently running tasks. In short this is concurrent tampering with task object states in forbidden ways.
Ok so how is it that other applications produce crash logs for end users to post to support forums when they are having issues because none of those applications have debuggers attached, but they still dump everything to a text file so that support staff can see what went wrong and hopefully provide a means to fix the issue, because I would think that something like that could be quite helpful when you are trying to identify what is going wrong since no two computers are alike.
As for the design flaw you mentioned that sounds really nasty, though my knowledge of programming is limited even I know that messing with stuff that has already been initialised and queued is a bad move, I have to wonder why the original dev's would ever design things that way in the first place surly they must of known better.
Is there no way to prevent tampering once initialisation has occurred? So that if you try to tamper with something that is initialised and queued already you will simply get an error that the requested action is not allowed, and when said error happens do something else instead.
I know this might seem like a stupid suggestion and maybe I have no idea what I'm talking about here but did you ever consider trying to address this issue by instituting a team name check? because in theory by checking the team name before conducting a given operation it should be impossible for one team to interfere with another.
So let's say green team takes its turn and sets a bunch of stuff now blue team takes its turn, and wants to mess with stuff that was set-up by green team now obviously that's bad and we can't have one team interfering with another team like that, so how do we stop it? by running a team name check, first we check the name of the team that is making the request, then we check to see which team set the thing that the requesting team wants to change and if the team names are different then you reject the request and do something else instead while this may not fully solve the problem it should at the very least elevate it since it would no longer be possible for one team to interfere with another.
Another possible way to handle this could be to separate everything out so that each team has its own area to write to so again it becomes impossible for one team to interfere with another because each team is writing its orders and such to separate areas now maybe this is a crude and inefficient way to address the issue and again maybe I have no idea what I'm talking about but assuming I've understood correctly then doing things that way should be effective since there would be no possibility for one team to overwrite something set by another team if each team is doing so in its own dedicated area.