Showing 1-20 of 182 entries
Yeah, I also ran into this, and I'd say it's a bug.
Aug 12 @ 3:15pm
In topic Is the game as hard as Shenzhen I/O ?
I'd argue that just completing the levels is significantly less laborious than in Shenzhen I/O.
You just have far more flexible tools at your disposal.

Of getting to the top percentile on the histogram is a different matter.
Aug 12 @ 1:33pm
In topic Request: Hacker Battle Tournaments
Hacker battles are great, but the current setup encourages building "simple" programs to take out specific individual opponents rather than trying to design something more involved which can deal with arbitrary situations.

It would be fantastic to have a "game-wide" tournament format.
I imagine it looking somewhat like this:
  • For each hacker battle level, you can nominate one program to participate in the tournament.
  • All participating programs are matched against each other once every set time interval (e.g. once a week), server side.
  • In the interface for the level you see the ranking of your program for the last tournament period (if you want to get fancy, with a chart of the relative position over the last several).

Obviously this isn't a trivial feature, but I think it would be awesome. And make Ghast proud.
The title says it all really. It's a good feature to have.
(And while you are at it, change the forum style engine to markdown too, it's much easier to type)
Jun 12 @ 12:29pm
In topic Undo the discord copycat
But that's what it is (an improvement to Steam chat)
Sorry to hear about your issues.

I've looked into the log and crash dump you provided, and sadly it looks completely different from everything else I've seen so far (most of which should be resolved in 1.3).

Can you please update to 1.3 and verify the integrity of the game files?
Great, thanks for the report!
Originally posted by Airk:
So far, I want to say that this resolves my issues with both the Rufus fight and Alisa's Shining Sun costume. The Rufus fight also seems to take unusually long to start, but other battles appear unaffected.
Good to hear!

This change might actually make some processes take a bit longer, especially on slower CPUs, since it introduces additional synchronization.
However, that synchronization is required to fix a potential race condition between the render thread and the main game thread that I currently assume is the primary (hopefully only!) reason for the remaining in-game crashes on some systems.
Mar 10 @ 6:41am
In topic [1.2] Crash after Duvalie
Hi, I've had a look at your crash dump and it seems similar to the issues that I am trying to resolve in the 1.3 alpha, available here: http://steamcommunity.com/app/748490/discussions/1/1698293255125396221/

Please try that and see if it resolves your issue.
We are still trying to isolate the cause of some crashes that occur on some software/hardware configurations in version 1.2.

If you are affected, please try out this alpha version of the game:
https://www.dropbox.com/s/7h2a5td9dnsvxcx/ed8_2_PC_US.exe?dl=0
and report your findings here.

To use this alpha, navigate to the game directory (properties -> local files -> browse local files in Steam), and replace the executable in the bin/Win32 folder with the one from the link above.
Originally posted by masterotaku:
The "-hdfont" command doesn't seem to be working on the GOG 1.2 version (which appeared around 11 hours ago). Neither through the GOG Galaxy command line option nor using a normal shortcut. Things like "Resume from a previous save." or normal text fonts inside the game are still low resolution. But I see the new HD textures in menus and battle. I'm using the modified ".exe" file.
I just tested it on the GoG version and it works here. Make sure that the command line option is actually passed to the game.
Mar 3 @ 10:54am
In topic Still crashing after Rufus in 1.2
Note: I've started looking into this with Airk's help, but it's not currently reproducible.
Can you please check if the behaviour changes if you revert to version 1.1?
(see the patch notes for instructions about how to do so)

Also, please include a save game and crash report if possible (see http://steamcommunity.com/app/748490/discussions/1/2860219962082309572/).
Mar 3 @ 9:10am
In topic [1.2] Crash at startup
Hi, I've looked through your crash report and sadly it doesn't really contain information that helps me pinpoint an issue.

A few questions:
- Have you tried disabling videos in the launcher and does that change anything?
- Which version of Windows are you running and what is your hardware?
Thanks for testing this!
Any other experiences?
If you are experiencing a reproducible crash in version 1.1, please try this alpha version:
https://www.dropbox.com/s/r379wpqa3k8wwux/ed8_2_PC_US.exe?dl=0
(replace the existing executable in the game installation folder/bin/Win32)

Please report here if this version fixes your issue.
(And also if it does nothing or causes some other issue)
Feb 19 @ 8:20am
In topic Extremely long load times?
Thanks for testing, we'll also do some more testing on it but the changes (and a few other ones aimed at improving loading) should be in 1.2.
Feb 18 @ 4:32am
In topic Extremely long load times?
Based on the fact that some people report this issue happening with ToCS2 but not ToCS1, I've created an ad-hoc build that does everything loading-related as close to ToCS1 as possible in terms of behaviour.

I don't want to put it up officially, since it's only tested for half an hour or so right now, but you can try it out here:
https://www.dropbox.com/s/r379wpqa3k8wwux/ed8_2_PC_US.exe?dl=0

Replace the executable in the game's install folder /bin/Win32 with the one available above.

Please let me know if it helps/hurts/does nothing.
Feb 18 @ 3:33am
In topic Extremely long load times?
It must be related to a particular hardware/software combination.
I wasn't able to reproduce it on any of my local testing systems (1 NV/Win10 PC, 1 AMD/Win10 PC, 1 NV/WIN7 PC, and 1 Intel/Win10 laptop).

If anyone has more insight based on something they observed I'd be grateful, otherwise it's hard to resolve this.

If you experience the issue please provide a description of the system you are seeing it on (hardware/OS) and the settings you are using. Maybe we can find a pattern.
Feb 18 @ 3:07am
In topic ToCS II HD Texture Pack v4.37 (4/4/2018)
Originally posted by Bighead:
The corruption is a bogus issue, it depends on the DDS format I choose. Many of the game's uncompressed textures are ARGB32 (DX10 B8G8R8A8), many others are ABGR32 (DX10 R8G8B8A8). If I use these formats for the problematic textures, the game just straight up crashes on load. If I use BC7, it will not crash but the texture is corrupted. The only thing that works is to use the original resolution, but that kinda defeats the purpose... The only reference I have to this issue is what Durante said here:

http://steamcommunity.com/app/538680/discussions/0/1471967615843483293/#c1471967615846033797

This was referring to the button textures, but I'm assuming the same is true for many textures. I'm guessing the game is reading the texture at hard coded positions, and when the resolution exceeds what it is expecting, the game crashes or shows corruption. Unless XSeed/Durante was willing to go through and fix every instance to use arbitrary positions that are calculated from resolution rather than hard coded positions, then there is probably nothing anyone else can do. Maybe the texture loading program could use some clever hacks for this specific situation, but I have no idea if that's possible.

It's strange though, considering many "multi-textures" work fine, which you would assume use hard coded positions like this one: https://i.imgur.com/EGm69nq.png

So maybe there is something else going on. I can only speculate.
What is happening is that any texture which includes button prompts is post-processed by the PC version to change those button prompts depending on the current user button bindings.
This was a more viable solution for correctly displaying the buttons of arbitrary user-defined KB/mouse/gamepad bindings than changing every use of the texture, since those are spread over a huge number of code fragments and script files.

The postprocessing should be resolution-independent, but it only works on uncompressed 32 bit textures. Probably something about the on-the-fly replacement/modding breaks when the texture processing is happening.

Edit:
I just looked into it a bit, and sadly, due to the way UI textures are packed into clusters, it's not straightforward to implement a way to natively load replacements if available.

Note that none of this should ever occur for anything but textures containing button prompts, so you should be "save" in replacing anything else.
Showing 1-20 of 182 entries