We found the reimplementation issue and fixed it. At the end it turned out that the root cause was a simple wrong conditional branch operation in the code. We could say it was a simple typo... but it caused a lot of trouble and headaches.

Any ways. Problem is solved now. Attacks immediately returned to good old dosmax speed even at 24 FPS fastest tick rate.

Can't say that surprises me because it wouldn’t be the first time I've seen a simple typo cause mysterious issues that are hard to track down, because its not immediately apparent what the problem is as there is no error message and the only thing you have to go on is the defective in game behavior although that can in some cases at least give a clue where to start looking for the problem and then its just a case if systematically following the breadcrumbs eliminating every possibility as you go till you are left with just 1

Or in the immortal words of Sherlock Holmes: when you eliminate all other possibilities what ever remains however improbable must be the truth.

Hi

Not sure if this is a bug or deliberate design but I have noticed that alien units never seem to improve there ammo count, scan range or speed not in the original or in the port.

So I'm wondering if they are supposed to but don’t due to a bug or if the fact that they don’t is deliberate design although if this is the case I have to question why because that makes no sense.

Hello, by design only these attributes can improve based on experience gain: attack, shots, range, armor, hits.


const uint8_t UnitInfo::ExpResearchTopics[] = {RESEARCH_TOPIC_ATTACK, RESEARCH_TOPIC_SHOTS, RESEARCH_TOPIC_RANGE, RESEARCH_TOPIC_ARMOR, RESEARCH_TOPIC_HITS}

I do not know the reason or rationale behind this limitation.

Humm so it’s deliberate design then how curious I wonder why? because in a long game that would put alien units at a serious disadvantage.

Perhaps the developers didn’t consider the fact that a match could run into the thousands of turns when playing against 3 god mode computers, since on DOS such long games simply weren’t possible due to insufficient memory, memory leaks, various game defects and a faulty dos extender and while switching the faulty dos extender alleviated a lot of the crashes and allowed for such long games other defects would often end the match prematurely by for example the game refusing to change turn, or the game crashing every time you reload and end turn.

With this in mind perhaps it might be a good idea to allow alien units to upgrade all there stats, I mean while alien units might start out stronger then there human equivalents they are quickly out classed since they can't upgrade all stats and take along time to level up.

Also consider the following I once played a game where I had captured a few alien planes and one of them upgraded its shots to 15 however alien planes can only carry 10 ammo rendering the upgrade pointless, since alien units can't upgrade the amount of ammo they carry.

Additionally since alien planes have a maximum of 18 movement points and cant upgrade there speed once your opponents fighters have upgraded there movement points a few times, then again your alien planes are at a huge disadvantage as it becomes impossible to escape if attacked pretty much guaranteeing that your alien planes are going to get destroyed, which should be avoided since alien units cant be replaced.

Additionally such low movement points makes supporting your alien units a pain in the backside to.

The same applies to gunboats as well since you can't get around the movement restriction by loading them into a transporter like you can for tanks and assault guns.

Also while I'm on the subject of long games I would also suggest allowing players to set the length of the game to unlimited, such that the game will only end when the player completely destroys all opponents, at the current time what I usually do is just set the time limit to 9999 which for the DOS version of the game is fine since it is pretty unlikely you will ever get close to having a game run that long before a defect kicks in and renders it impossible to continue, but if the intention is to fix the game braking defects then it is entirely possible that a game could run for more than 9999 turns

Also I don’t know if this would be possible or not but if it is then as I have mentioned before it might be an idea to make the derelict alien buildings functional and allow players to produce alien units when those structures are linked to your base thus supplying them with power and resources.

Personally I think it would add an interesting little twist to the game since the aliens didn’t become a playable faction until M.A.X 2 and while it would be nice if the alien faction could be back ported to M.A.X 1 so they are a playable faction it would probably require a fair amount of tweaking to get that working since things like shields and the like don’t exist in M.A.X 1 and therefore would need to be removed in order to make them work the same way as every other unit / structure in M.A.X 1.

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.

Looking into this I noticed a new setting in the settings.ini game_data=. however adding this to the settings.ini failed to fix the issue, my next though was to just manually set game_data to c:\max port however this also failed to fix the issues.

It was only when I added the .portable file to the max directory that the game would load which strikes me as a little odd not sure why this would be necessary it never was before ?? Normally I just add

max.exe
lang_english.ini
PATCHES.RES

from the zip archive to the max directory overwriting the old ones start up the game and everything works just fine, so what's going on here because a game_data setting should be unnecessary since max has no directory structure?

Perhaps a more sensible and pragmatic approach would be to just have the port ask the user where the game files are located if it can't find them rather than failing and giving the user some obscure error message and then just add the specified directory to the settings.ini file. I'd also eliminate the .portable file since it should be unnecessary

Also the installer is still being flagged as a virus, although as I mentioned previously this is most likely a false positive caused by the use of the particular packer that you are using for the installer as this seems to be a common problem with NSIS installers.

Since the release notes say that the port now supports arbitrary map dimensions I decided to have another go at changing the games resolution and while there where no more big black borders on the main game screen as noted previously 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.

https://i.ibb.co/1KJFXp7/screen-shot-1.png

Also I'm not certain if this is deliberate or a bug but I also noticed that the game doesn't respect the specified resolution when disable_ar_correction is set to 0 and as a consequence it incorrectly stretches the main game windows to 100% wide which as you can see in this screen shot just looks weird on a wide screen monitor

https://i.ibb.co/0MbG4Vr/screen-shot-2.png

I also notice that when you change resolution the text on the buttons is not resizing as it should which makes the text on the buttons very small on high resolutions not certain if these are bugs or if you just haven't gotten round to addressing them yet, but either way its something that will need attending to.

I'm also noticing some odd behavior from the AI for example the green teams scouts making suicidal attacks on my surveyors, attacks which have precisely zero change of succeeding, I have also noticed exactly the opposite the green team scouts completely ignore my surveyors even when the green scouts can clearly see my surveyors and have ample movement points to move into attack range and destroy them with out any possibility of retaliation from me till the next turn since my units are to far away to intervene.

In addition I have also observed the computer behaving in a manor that would suggest that the computer is cheating and some how knows where my units and structures are even though it shouldn’t since they are outside of the computers radar range and I think this is in part responsible for the computers suicidal attacks on my surveyors, some how the computer can still track there location even when they are beyond the computers radar range, and therefore the computer should not know where they are and should not be able to track them.

This is not the first time I have observed this sort of cheating behavior either for example when starting a new custom game usually within the first dozen or so turns I will get attacked however if I use the max super cheat on my defense units the computer doesn't attack which tells me the computer can see my units when it shouldn’t be able to.

I have also observed this when using submerged units on occasion the computer will send bombers to where my submerged units are even though the computer can't attack them because they are submerged now I could understand this had my submerged units previously attacked one of the computers units or otherwise revealed there presence, then of course the computer is going to send units to that area to try and take me out, but this should not happen if my units remained hidden and where careful not to revel there presence and yet I have observed exactly this happening which again suggests the computer knows where my units are when it shouldn't.

I'm also noticing that the computers behavior 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.

Now maybe this perceived difference is down to the fact that previously the computer didn’t store states and the like properly so on reload queued orders and such would be lost which would of course result in the computer making different decisions based upon the available information on reload but either way it seems like something isn’t quite right with the AI and something isn’t working like it should.

I'm also noticing another little glitch where part of what looks like build tape is incorrectly appearing as you can see in this screen shot.

https://i.ibb.co/yBjB6f4/screen-shot-3.png

I also noticed an engineer incorrectly building on a patch of debris as you can see in this screen shot, which shouldn’t be possible and as far as I'm aware that should include building connectors on a patch of debris unless connectors are the one exception to the rule ??

https://i.ibb.co/jJ5fkpF/screen-shot-4.png

Another issue I encountered is build time being reset on partly build units for example I click on the training hall and it says spy will be ready in 4 turns I then open up the build menu I don’t change anything I just click done to close it again when I then click on the training hall again it now says spy will be ready in 8 turns so the build time has been reset this also happens if you open up the build queue and add additional units the build time on partly build units will be reset.

There still seems to be an issue with cost reduction research not being correctly applied, for some reason after researching 10% cost reduction when the constructor is full it gives the incorrect value of 4 turns at a cost of 58 materials which is clearly wrong when I apply cost reduction the cost should go down not up.

More over isn’t the whole algorithm just wrong from the outset in light of the fact that when building at x4 speed the cost isn’t 4 times the base cost minus any cost reduction which it should be.

Another glitch I encountered is structures that should be within radar range of your units and targetable are invisible and can't be targeted on reload and in order to be able to make them visible and targetable you have to move your units.

As you can see in this screen shot where i have activated the [max spy] cheat the greens mine and and air plant are clearly within my scan range and yet as you can see by the cursor they are not targetable

https://i.ibb.co/stYSnWh/screen-shot-5.png

now here is the same screen shot again but this time with the [max spy] cheat switched off as you can see even though those building should be visible they aren't and in order to make them visible so i can attack them i have to move my units

https://i.ibb.co/d6KfsGb/screen-shot-6.png

if you want a copy of the save for examination let me know i made sure to make a back up.

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.

More specifically if I attempt to do a quick load during the computers turn so for example if I attempt to do a quick load but for some reason the game doesn't register the ALT + L button press this will results in my turn being ended prematurely when I hit enter if I then subsequently press ALT + L and then pressing enter again during the computers turn then that can on occasion crash the game.

Part of the scan line vanishing when ordering my bulldozer to clear site also still seems to be an issue as you can see in this screen shot.

https://i.ibb.co/bNdhLvf/screen-shot-7.png

For a bit of fun I thought I'd have a go at enabling the debug feature unfortunately it doesn't appear to work, I copy and pasted

[DEBUG]
debug=0
all_visible=0
disable_fire=0
quick_build=0
real_time=0

to the start of the settings.ini file set debug to 1 and saved now when I go to settings I see the debug pane at the bottom of the window but when I hit ALT + Z, ALT + Y to bring up the build menu on the main screen nothing happens, similarly if I go into the file menu and tap F1 F2 nothing happens i tried selecting an empty spot and tapping F1 F2 nothing so i tapped F1 F2 then selected an empty spot but again nothing so I had a look at

https://klei1984.github.io/max/2024/07/21/scenario-editor.html

To see if that could shed any light on things but again no joy, I also had a look on the github page in case there was something that’s not normally included in the release version that need to download to make this work but again no joy so what gives ?? what am I missing here ?? How come this doesn't work ??

Please read the installation guideline.

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.

I also observed this many times, but root cause is not known yet. I usually see this with fighters in late games that are difficult to analyze due to the huge number of factors. The idea that scouts at beginning of games could also be used for root cause analysis is a very good one.

I explained this several times already at various places... yes, computers cheat. This is v1.04 original behavior. 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".

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.

This is still the case. The save game format is the original MS-DOS v1.04 M.A.X. version. Computers do not save their "thought process", only the grand strategy parameters and the radar maps. You can read more on this in the save format documentation here.

This happens in original MS-DOS version as well and behavior is random. Some times the glitch is there, sometimes not. The volume of "corrupted" pixels is also random. Root cause of it is not yet known. I already looked into it a month ago or so, but could not identify the root case.

Yes, connectors are the exception to the rule. This is original M.A.X. behavior.

I think we discussed this already, its original behavior, but it surely should not work like this. I did not look into the root cause yet.

I never seen such a thing, even tired to reproduce it yesterday, but could not. Please attach your saved game file, there may be some wicked corruption there.

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.

Will look into it eventually.

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.

Here this save https://ufile.io/dnpsus8c

Additionally while continuing to play ran in to another couple of issues

Engineers using the path ability are still becoming bugged upon reload.

Also the group movement seems to have an issue as well as you can see in this screen shot

https://i.ibb.co/qmf1bNz/screen-shot-1.png

After hitting ignore I got the thing where air units get nearly unlimited movement points so clearly this one isn’t fixed.

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.

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.

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.

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.

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.

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.

I cannot reproduce this whatever I try. I experienced it a lot too, but have no means to reproduce it reliably to analyze the failure case. If you have some more details or ideas I would be interested in them.

This is now fixed on the master branch and the assertion test is also removed as it is not required anymore. This is defect 136.

Good find, it should not be active in release builds. I will disable it.

Starting from v0.7 the port satisfies the XDG Base Directory Specification on Linux systems and adheres to the standard Program Files and Roaming User Profiles requirements of Windows. End Users on Windows are encouraged to use the provided installer packages. The NSIS installers are not infected by viruses, if you get such warnings those are false alarms. The portable use case is not documented on purpose for OS compliance.

In case of portable mode on Windows you need the .portable file as you found. This instructs the game to look for the user writable files (logs, save files, screenshots, configuration files) in the same folder where the game executable is found. In this case the game must not be placed under the Program Files standard folder(s) of Windows. The game searches for all read only original game data files at the location that is configured in the ini configuration file.

The NSIS installer asks for this location and sets up the ini file as per user input. On Linux shell scripts prompt the users to configure this via a text GUI interface. In both cases the user gets help to figure out how to set up the game.

I will add a configuration option to disable all v1.04 original hacks restoring the v1.03 behavior if the option is enabled. That way the computers will fight each other, they will not see the map or get to know the location of mining stations and eco-spheres on all game reloads. But Master and God tiers will still get the production bonuses.

Note that the scout horde computer strategy will still be a valid strategy regardless of the above and Master / God tier computers will prefer to select it more than lower difficulty levels. If you set starting credits high enough, such computers will buy like 18 scouts and spend all remaining credits to upgrade those at mission load out phase and 3 scouts will immediately start to "scout" or discover the entire map. This scouting or discovery is standard tactic of all computers, its not limited to scout horde. Best defense strategy against scout horde with 250 starting credits is mass fast point defense construction around the base. Select Axis Inc. clan, buy 10 engineers in total, fill all of them with 40 raw materials. Buy a scanner or two scouts, spend remaining credits on raw materials filling up constructors. Build gun turrets with all engineers at x2 speed. You will have 20 gun turrets by turn 4 and enough raw materials to start with 1-2 engineers as if the game would just have started. Mission accomplished. Gun turret default attack range is bigger than scout horde scout upgraded attack range. The same works against tank horse tactic too as their range is inferior to gun turrets too.

The game uses the free and open source GNU GCC compiler toolchain. On Windows this does not have the capability to create crash dumps. Crash mini dumps that the Windows operating system creates are also useless as those cannot be understood by GNU GCC, GDB and similar tools. Others use Microsoft Visual C/C++ or a game engine like Unity that have built in support on Windows or integrate third party libraries. There are various gcc compatible libraries that could be used to produce a call trace or even to save a context, but that is mostly useless. Just consider that if I cannot fix an issue even if I am using a debugger and see the entire context, how much help a crash dump of 1% of the full context I would normally see in the debugger would be.

Best way to diagnose reoccurring crashes is to provide a save game file and explain how to reproduce the issue. I dare to say that I am well aware of 99% of crash to desktops already, but I simply cannot fix them without weeks or months of work.

Problem itself is late initialization of computer instances. But any ways... The issue can be fixed. It just needs a lot of time and as I already failed this twice by jumping on the topic without much planning using rapid application development methods, next time I will need to do proper planning, actual architectural design rework, and a lot of lot of code refactoring...

In order to verify how you go about triggering this bug I just deliberately triggered this and bugged one of my engineers and created a save let me know if you like the save for analysis.

In any event if you want to try and recreate this for your self here is how to trigger your engineers to become bugged when using the path ability.

First make sure your engineer has materials enough to build several sections of road or connector set your engineer to build several sections of road or connector using the path ability next end turn on the next turn your engineer should move to the next space and continue to build at this point if you reload the auto save a few times eventually the engineer should become bugged and will fail to move to the next square.

Here is what it should look like once you trigger the bug as you can see in this screen shot I set the builder to build a road however it's building a road on a square that already had a road on it which should be impossible which of course indicates that the bug has triggered

https://i.ibb.co/xHtqpCH/screen-shot-3.png

Oh is this fix not already implemented in 0.7.0? I though it was.

With regards to this I would recommend the following the computer should not know where the players base is or where the players units are at the start of a game nor should the computer be made aware of anything outside of its radar range on load, and just like the player the computer should not be able to see anything that is outside of its radar range.

This I think would help to put a stop to the most irritating behaviour I see from the computer like getting jumped within just a few turns of starting a new game, having the computer continually pester my surveyors and other none combat units like bulldozers that it shouldn't even know about in the first place, and dancing around the firing range of my turrets and units even when the computer shouldn't be able to see what there range is because the computers scan range is to short, this would make things the same for the computer as it is for the player so if you click on a unit or turret that is out side you scan range you can't see what the unit or turrets scan range is, it would also put a stop the computer being able to see your spies and subs when it shouldn’t be able to, of course you would still have to be careful how you use stealth units because as soon as they attack / disable / steal then they reveal there presence and of course the computer is going to come looking for them just as the player would.

I actually already tried this and still got flattened, because the issue with this is even if you manage to get enough turrets up the computer will just continually hover around just out side the range of your turrets the result of which is you end up completely pined down and unable to do anything, so ultimately the end result is the same game over, although usually I'm unable to get enough turrets up quick enough and they just target my builders and that’s that game over, or they just waste my turrets when they can't fire and again that’s game over.

I could assuming I can get enough turrets up of course try slowly witlings the computers units down but by the time I have maybe 50 to 100 turns have passed because my build speed is so slow when I have only a single mine and by that point I'm stuffed anyway because the computer is so far ahead that I simply don’t have a chance although to be honest I don’t even get that far normally I wont usually last 20 turns not against 3 god mode computers launching rush attacks.

This I think is in part down to the fact that the computer just attacks to quickly due to the fact that the computer can see your base and your units from the very start which results in getting jumped almost immediately so you only have as long as it takes for the computers units to get to your base to put up defences and in most cases that’s just not enough time but of course this is only possible due to the fact the computer is a cheat if the computer had to obey the same rules as the player and search like the player does and couldn't see stuff outside it's scan range then in all likelihood this wouldn't happen or at the very least there would be a longer time lag before the computer figurers out where you are and comes in full force to take you out.

Ok so came across another couple of bugs firstly as you can see in this screen shot it looks as though a mobile anti aircraft and engineer are occupying the same space square.

https://i.ibb.co/mv4fRfH/screen-shot-1.png

Now from what I can tell from watching from the end of the previous turn it seems as though the issue might be with the computers air transport incorrectly dropping the mobile anti aircraft on a square that’s already occupied, although it happens so quick its tough to catch it also it doesn't always happen, although I have had it happen about 3 or 4 times now if I just reload to the previous turn and then end turn again a few times.

I made a save where the glitch has happened already and I made a back up of the save from the previous turn so let me know if you want them for analysis.

This next bug triggered when was disabling the computers mine and I got the following error

https://i.ibb.co/YR1jftR/screen-shot-2.png

Additionally I noticed that the spies disable ability still isn’t working correctly because when I click on the computers mine it says its disable for 2 turns but comes back on line as soon as I end the turn and the greys take there turn and then at the start of the next turn when I disable it again I get the error.

Again I made a save both before and after the glitch so let me know if you'd like them for analysis.