Modding talk:Player Guide/Troubleshooting - Revision history

imported>Margotbean at 16:21, 15 June 2025

2025-06-15T16:21:01Z

← Older revision		Revision as of 16:21, 15 June 2025
Line 46:		Line 46:

	I dont have the authority to remove the link but currently it goes to some gambling site [[User:Cvrcek\|Cvrcek]] ([[User talk:Cvrcek\|talk]]) 16:14, 15 June 2025 (UTC)		I dont have the authority to remove the link but currently it goes to some gambling site [[User:Cvrcek\|Cvrcek]] ([[User talk:Cvrcek\|talk]]) 16:14, 15 June 2025 (UTC)
			:I've updated the link to inputmapper, thanks for the comment! [[User:Margotbean\|margotbean]] ([[User talk:Margotbean\|talk]]) 16:21, 15 June 2025 (UTC)

imported>Cvrcek: /* Input mapper (under topic: SMAPI doesn't recognize controller (Steam only)) links to a scam website */ new section

2025-06-15T16:14:16Z

Input mapper (under topic: SMAPI doesn't recognize controller (Steam only)) links to a scam website: new section

← Older revision		Revision as of 16:14, 15 June 2025
Line 42:		Line 42:
	All of this information was from tgodiamond in the SDV Discord. Having it in the wiki makes it easier to locate from a search term rather than needing to join a discord to locate a fix.		All of this information was from tgodiamond in the SDV Discord. Having it in the wiki makes it easier to locate from a search term rather than needing to join a discord to locate a fix.
	<span style="background:linear-gradient(90deg,rgb(215,0,0)0%,rgb(111,111,216)65%,rgb(56,182,241)100%);-webkit-background-clip:text;-webkit-text-fill-color:transparent;background-clip:none">[[User:Lividjava\|LividJava]]</span> ([[User Talk:Lividjava\|talk]]) 20:03, 25 March 2025 (UTC)		<span style="background:linear-gradient(90deg,rgb(215,0,0)0%,rgb(111,111,216)65%,rgb(56,182,241)100%);-webkit-background-clip:text;-webkit-text-fill-color:transparent;background-clip:none">[[User:Lividjava\|LividJava]]</span> ([[User Talk:Lividjava\|talk]]) 20:03, 25 March 2025 (UTC)

			== Input mapper (under topic: SMAPI doesn't recognize controller (Steam only)) links to a scam website ==

			I dont have the authority to remove the link but currently it goes to some gambling site [[User:Cvrcek\|Cvrcek]] ([[User talk:Cvrcek\|talk]]) 16:14, 15 June 2025 (UTC)

imported>Lividjava: Proposing GalaxyAPI fix to be added

2025-03-25T20:04:18Z

Proposing GalaxyAPI fix to be added

← Older revision		Revision as of 20:04, 25 March 2025
Line 28:		Line 28:

	::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>		::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>

			==Add fixes for GalaxyAPI on Linux system to page==
			Had to join the Discord to find this fix, it was pretty quick and easy. I see no reason it shouldn't be on the wiki. I can't post links because of the New User policy but i'll add the Message ID from the SDV Discord here: 137344473976799233/1340356392607027251


			Fix boils down to this:

			Due to an update in glibc 2.41, Executable Stacks are now disallowed for security reasons. The libraries required for multiplayer are marked as requiring executable stacks, although they are not required to function. To fix, the tool execstack is required to disable the flag.
			# Install <code>execstack</code> via your system's Package Manager
			# Navigate to <code>~/.steam/steam/steamapps/common/Stardew Valley</code> (Or Equivalent Install Path)
			# Run <code>execstack -c ./libGalaxyCSharpGlue.so && execstack -c ./libGalaxy64.so</code>

			All of this information was from tgodiamond in the SDV Discord. Having it in the wiki makes it easier to locate from a search term rather than needing to join a discord to locate a fix.
			<span style="background:linear-gradient(90deg,rgb(215,0,0)0%,rgb(111,111,216)65%,rgb(56,182,241)100%);-webkit-background-clip:text;-webkit-text-fill-color:transparent;background-clip:none">[[User:Lividjava\|LividJava]]</span> ([[User Talk:Lividjava\|talk]]) 20:03, 25 March 2025 (UTC)

imported>Milarqui: Deleting section - it was just a matter of not noticing it was in a different slot

2024-03-26T13:01:23Z

Deleting section - it was just a matter of not noticing it was in a different slot

← Older revision		Revision as of 13:01, 26 March 2024
Line 28:		Line 28:

	::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>		::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>

	~~==Can't link to start.bat file==~~
	I've been following the instructions to make mods work in the GOG Galaxy version of Stardew Valley, but either I have some configuration wrong or there's some problem with the instructions. When I try to do step 5 ("In the menu that appears, enable the "Custom executables / arguments" checkbox."), I find a menu where everything below the auto-updates check doesn't show up. And, yes, the game is installed. Any ideas on why this is happening? [[User:Milarqui\|Milarqui]] ([[User talk:Milarqui\|talk]]) 12:58, 26 March 2024 (UTC)

imported>Milarqui: New discussion section

2024-03-26T12:59:18Z

New discussion section

← Older revision		Revision as of 12:59, 26 March 2024
Line 28:		Line 28:

	::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>		::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>

			==Can't link to start.bat file==
			I've been following the instructions to make mods work in the GOG Galaxy version of Stardew Valley, but either I have some configuration wrong or there's some problem with the instructions. When I try to do step 5 ("In the menu that appears, enable the "Custom executables / arguments" checkbox."), I find a menu where everything below the auto-updates check doesn't show up. And, yes, the game is installed. Any ideas on why this is happening? [[User:Milarqui\|Milarqui]] ([[User talk:Milarqui\|talk]]) 12:58, 26 March 2024 (UTC)

imported>Margotbean: Text replacement - "tt>" to "samp>"

2021-11-04T18:49:13Z

Text replacement - "tt>" to "samp>"

← Older revision		Revision as of 18:49, 4 November 2021
Line 13:		Line 13:
	[[User:Pepoluan\|Pepoluan]] ([[User talk:Pepoluan\|talk]]) 14:15, 28 May 2021 (UTC)		[[User:Pepoluan\|Pepoluan]] ([[User talk:Pepoluan\|talk]]) 14:15, 28 May 2021 (UTC)

	: We only care about 64-bit Windows here, since players on 32-bit Windows can't use this. Both <tt>Stardew Valley.exe</tt> and <tt>StardewModdingAPI.exe</tt> are marked <tt>LARGEADDRESSAWARE</tt>, so in theory they should have access to a full 4GB of memory space. It'd be great to provide a more accurate explanation on the page, but do you know why players often report <tt>OutOfMemoryException</tt> errors with 1–3GB memory used despite having plenty of available system memory? For example, here's [https://github.com/Pathoschild/SMAPI/issues/749 an <tt>OutOfMemoryException</tt> crash on a system with 32GB of memory with 1.2GB in use by the game]. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 15:26, 29 May 2021 (UTC)</small>		: We only care about 64-bit Windows here, since players on 32-bit Windows can't use this. Both <samp>Stardew Valley.exe</samp> and <samp>StardewModdingAPI.exe</samp> are marked <samp>LARGEADDRESSAWARE</samp>, so in theory they should have access to a full 4GB of memory space. It'd be great to provide a more accurate explanation on the page, but do you know why players often report <samp>OutOfMemoryException</samp> errors with 1–3GB memory used despite having plenty of available system memory? For example, here's [https://github.com/Pathoschild/SMAPI/issues/749 an <samp>OutOfMemoryException</samp> crash on a system with 32GB of memory with 1.2GB in use by the game]. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 15:26, 29 May 2021 (UTC)</small>

	:: I would say that it isn't true in _any_ situation.		:: I would say that it isn't true in _any_ situation.
Line 23:		Line 23:
	:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has ''never'' operated this way.		:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has ''never'' operated this way.

	:: The reason players still see <tt>OutOfMemoryException</tt> is that the process is exhausting its logical address space. Simple as that. You can exhaust it without ever committing physical pages.		:: The reason players still see <samp>OutOfMemoryException</samp> is that the process is exhausting its logical address space. Simple as that. You can exhaust it without ever committing physical pages.

	:: [[User:Ameisen\|Ameisen]] ([[User talk:Ameisen\|talk]]) 23:22, 10 October 2021 (UTC)		:: [[User:Ameisen\|Ameisen]] ([[User talk:Ameisen\|talk]]) 23:22, 10 October 2021 (UTC)

	::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>		::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>

imported>Pathoschild: /* Wrong explanation on 32-bit memory space */ re: rewrote to be vague instead

2021-10-10T23:32:37Z

Wrong explanation on 32-bit memory space: re: rewrote to be vague instead

← Older revision		Revision as of 23:32, 10 October 2021
Line 26:		Line 26:

	:: [[User:Ameisen\|Ameisen]] ([[User talk:Ameisen\|talk]]) 23:22, 10 October 2021 (UTC)		:: [[User:Ameisen\|Ameisen]] ([[User talk:Ameisen\|talk]]) 23:22, 10 October 2021 (UTC)

			::: I rewrote that part to be vague instead: "''That means your game ran out of available memory mid-session, which can happen even if your computer has plenty of physical memory available due to 32-bit limitations.''" It'll be a moot point soon, since all modded players will have 64-bit in Stardew Valley 1.5.5. —<small>[[User:Pathoschild\|Pathoschild]] ([[User talk:Pathoschild\|talk]]) 23:32, 10 October 2021 (UTC)</small>

imported>Ameisen at 23:26, 10 October 2021

2021-10-10T23:26:54Z

← Older revision		Revision as of 23:26, 10 October 2021
Line 17:		Line 17:
	:: I would say that it isn't true in _any_ situation.		:: I would say that it isn't true in _any_ situation.

	:: *On 32-bit Windows, it isn't true as far as I have ever been aware. <code>increaseuserva</code> specifies that you want processes to have 3 GiB of virtual address space available instead of the default 2 GiB. The default was specified as many much older programs assumed that logical addresses wouldn't be larger than that and would fail.		::* On 32-bit Windows, it isn't true as far as I have ever been aware. <code>increaseuserva</code> specifies that you want processes to have 3 GiB of virtual address space available instead of the default 2 GiB. The default was specified as many much older programs assumed that logical addresses wouldn't be larger than that and would fail.
	:: *Process logical address space ''is not shared between processes''. ''Physical'' memory is, but that is mapped to processes (into their logical address space). Even 32-bit NT can address more than 4 GiB of physical RAM via PAE. If you have two 32-bit processes, they do not share a 2 GiB logical address space. Or a 3 GiB logical address space. They have their own logical address spaces. They compete for ''physical'' memory, but that's true of any system.		::* Process logical address space ''is not shared between processes''. ''Physical'' memory is, but that is mapped to processes (into their logical address space). Even 32-bit NT can address more than 4 GiB of physical RAM via PAE. If you have two 32-bit processes, they do not share a 2 GiB logical address space. Or a 3 GiB logical address space. They have their own logical address spaces. They compete for ''physical'' memory, but that's true of any system.
	:: *On 64-bit Windows, obviously the same applies. Except that if a process is flagged as <code>LARGEADDRESSAWARE</code>, it gets access to the full 4 GiB address space instead of 3, as the kernel does not need to be mapped within the 4 GiB address space (during an interrupt, the processor switches back to long mode and the kernel can access its own memory which is mapped outside of what the process is aware of).		::* On 64-bit Windows, obviously the same applies. Except that if a process is flagged as <code>LARGEADDRESSAWARE</code>, it gets access to the full 4 GiB address space instead of 3, as the kernel does not need to be mapped within the 4 GiB address space (during an interrupt, the processor switches back to long mode and the kernel can access its own memory which is mapped outside of what the process is aware of).

	:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has ''never'' operated this way.		:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has ''never'' operated this way.

imported>Ameisen: /* Wrong explanation on 32-bit memory space */

2021-10-10T23:26:35Z

Wrong explanation on 32-bit memory space

← Older revision		Revision as of 23:26, 10 October 2021
Line 18:		Line 18:

	:: *On 32-bit Windows, it isn't true as far as I have ever been aware. <code>increaseuserva</code> specifies that you want processes to have 3 GiB of virtual address space available instead of the default 2 GiB. The default was specified as many much older programs assumed that logical addresses wouldn't be larger than that and would fail.		:: *On 32-bit Windows, it isn't true as far as I have ever been aware. <code>increaseuserva</code> specifies that you want processes to have 3 GiB of virtual address space available instead of the default 2 GiB. The default was specified as many much older programs assumed that logical addresses wouldn't be larger than that and would fail.
	:: *Process logical address space ~~_is~~ not shared between ~~processes_~~. ''Physical'' memory is, but that is mapped to processes (into their logical address space). Even 32-bit NT can address more than 4 GiB of physical RAM via PAE. If you have two 32-bit processes, they do not share a 2 GiB logical address space. Or a 3 GiB logical address space. They have their own logical address spaces. They compete for ~~_physical_~~ memory, but that's true of any system.		:: *Process logical address space ''is not shared between processes''. ''Physical'' memory is, but that is mapped to processes (into their logical address space). Even 32-bit NT can address more than 4 GiB of physical RAM via PAE. If you have two 32-bit processes, they do not share a 2 GiB logical address space. Or a 3 GiB logical address space. They have their own logical address spaces. They compete for ''physical'' memory, but that's true of any system.
	:: *On 64-bit Windows, obviously the same applies. Except that if a process is flagged as <code>LARGEADDRESSAWARE</code>, it gets access to the full 4 GiB address space instead of 3, as the kernel does not need to be mapped within the 4 GiB address space (during an interrupt, the processor switches back to long mode and the kernel can access its own memory which is mapped outside of what the process is aware of).		:: *On 64-bit Windows, obviously the same applies. Except that if a process is flagged as <code>LARGEADDRESSAWARE</code>, it gets access to the full 4 GiB address space instead of 3, as the kernel does not need to be mapped within the 4 GiB address space (during an interrupt, the processor switches back to long mode and the kernel can access its own memory which is mapped outside of what the process is aware of).

	:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has ~~_never_~~ operated this way.		:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has ''never'' operated this way.

	:: The reason players still see <tt>OutOfMemoryException</tt> is that the process is exhausting its logical address space. Simple as that. You can exhaust it without ever committing physical pages.		:: The reason players still see <tt>OutOfMemoryException</tt> is that the process is exhausting its logical address space. Simple as that. You can exhaust it without ever committing physical pages.

	:: [[User:Ameisen\|Ameisen]] ([[User talk:Ameisen\|talk]]) 23:22, 10 October 2021 (UTC)		:: [[User:Ameisen\|Ameisen]] ([[User talk:Ameisen\|talk]]) 23:22, 10 October 2021 (UTC)

imported>Ameisen at 23:26, 10 October 2021

2021-10-10T23:26:07Z

← Older revision		Revision as of 23:26, 10 October 2021
Line 17:		Line 17:
	:: I would say that it isn't true in _any_ situation.		:: I would say that it isn't true in _any_ situation.

	:: * On 32-bit Windows, it isn't true as far as I have ever been aware. `increaseuserva` specifies that you want processes to have 3 GiB of virtual address space available instead of the default 2 GiB. The default was specified as many much older programs assumed that logical addresses wouldn't be larger than that and would fail.		:: *On 32-bit Windows, it isn't true as far as I have ever been aware. <code>increaseuserva</code> specifies that you want processes to have 3 GiB of virtual address space available instead of the default 2 GiB. The default was specified as many much older programs assumed that logical addresses wouldn't be larger than that and would fail.
	:: * Process logical address space _is not shared between processes_. ~~_Physical_~~ memory is, but that is mapped to processes (into their logical address space). Even 32-bit NT can address more than 4 GiB of physical RAM via PAE. If you have two 32-bit processes, they do not share a 2 GiB logical address space. Or a 3 GiB logical address space. They have their own logical address spaces. They compete for _physical_ memory, but that's true of any system.		:: *Process logical address space _is not shared between processes_. ''Physical'' memory is, but that is mapped to processes (into their logical address space). Even 32-bit NT can address more than 4 GiB of physical RAM via PAE. If you have two 32-bit processes, they do not share a 2 GiB logical address space. Or a 3 GiB logical address space. They have their own logical address spaces. They compete for _physical_ memory, but that's true of any system.
	:: * On 64-bit Windows, obviously the same applies. Except that if a process is flagged as `LARGEADDRESSAWARE`, it gets access to the full 4 GiB address space instead of 3, as the kernel does not need to be mapped within the 4 GiB address space (during an interrupt, the processor switches back to long mode and the kernel can access its own memory which is mapped outside of what the process is aware of).		:: *On 64-bit Windows, obviously the same applies. Except that if a process is flagged as <code>LARGEADDRESSAWARE</code>, it gets access to the full 4 GiB address space instead of 3, as the kernel does not need to be mapped within the 4 GiB address space (during an interrupt, the processor switches back to long mode and the kernel can access its own memory which is mapped outside of what the process is aware of).

	:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has _never_ operated this way.		:: I mean, unless we're talking about Windows 9x. Those could and would operate weirdly... but Windows NT has _never_ operated this way.