Can certain game files not be edited?

[pickleplayer]

I'm trying to edit stategraph.lua and entityscript.lua, but nothing is changing in game. I have the files in the correct mod folder (directly in the scripts folder), and I know for sure that stategraph.lua isn't edited by the RoG dlc.

 

I've tried removing a few ends and essential code stuff from them that should be instantly crashing the game when it launches, but it runs just fine.

 

Are certain essential files like these automatically overwritten by the default game files or something?

 

I know I was able to change input.lua just fine, but these two just don't do anything when I try and change them.

[Mobbstar]

As a last resort... You can edit classes post init, you know?

[pickleplayer]

As a last resort... You can edit classes post init, you know?

 

Oh yea. I forgot about that...

 

 

 

Nope.

I went and tried it just now and apparently the game doesn't even recognize it's existence. 

I can add classes postinit to input.lua just fine, but when I try to do the exact same thing to stategraph.lua, upon enabling the mod I get the error "class file path 'stategraph' doesn't seem to return a valid class".

 

This is really weird. I've been checking and checking to make sure everything is set up right, that I'm not misspelling anything and that everything is in the right folder.

 

 

Maybe it has something to do with the fact that in input.lua there is "return Input" at the bottom of the page, but neither stategraph.lua or entityscript.lua have those.

(and I tried, but adding "return StateGraph" to the bottom of stategraph.lua doesn't change anything)

[Blueberrys]

@pickleplayer See if you can access the classes in stategraph.lua through global variables? (or through GLOBAL depending on where you're trying to access it)

[pickleplayer]

@pickleplayer See if you can access the classes in stategraph.lua through global variables? (or through GLOBAL depending on where you're trying to access it)

 

 

Ahaa! It does work with the global version!

AddGlobalClassPostConstruct("stategraph", "StateGraphInstance", function(self)	function self:Printme()		print("STOP RUNNIGN AWAY")	endend)

(I think this is what you meant, right?) And the statement does print when the function is called. So I guess that's one workaround for now! Thanks!

 

That's still really weird how I can't edit those files directly, though. I haven't heard of anyone else having this problem before. Am I doing something wrong? Has anyone else ever tried editing those files with any success? 

 

 

Okay, another question;

 

How would I go about editing update.lua?

(which suffers the same un-edibility problems as stategraph and entityscript.lua, but update.lua isn't a class, so I can't use the same method)

[Blueberrys]

@pickleplayer Oh, glad that worked. Though I was talking about using something like GLOBAL.VAR. Try doing that for update.lua.

GLOBAL.Update = function(dt)    -- ...endGLOBAL.LongUpdate = function(dt, ignore_player)    -- ...endGLOBAL.WallUpdate = function(dt)    -- ...end

[pickleplayer]

 

@pickleplayer Oh, glad that worked. Though I was talking about using something like GLOBAL.VAR. Try doing that for update.lua.

GLOBAL.Update = function(dt)    -- ...endGLOBAL.LongUpdate = function(dt, ignore_player)    -- ...endGLOBAL.WallUpdate = function(dt)    -- ...end

 

 

YESSS IT WORKS!!! 

 

I just pasted the original code inside them and changed what I needed.  (to others reading this with the same problem, make sure you stuff a bunch of "GLOBAL." in front of all the variables and stuff first, assuming it's in the modmain)

 

THANK YOU SO MUCH!

I'll be sure to mention you and the other people who helped me in the credits or whatever when I finish this thing.

 

(now let's just hope it still functions the same when created within the modmain)

[Blueberrys]

@pickleplayer If I remember correctly, the GLOBAL table is available to modmain. In other scripts, you can access the game's global variables directly.

Also, if possible, it'd be better to preserve the original function. See "Tables as objects (and how to modify their functions nicely):" in this guide.

 

Edit: You won't have to refer to GLOBAL every time if you store the instances you need.

table1 = GLOBAL.table1-- Same as GLOBAL.table1.vartable1.var = 2

[pickleplayer]

@pickleplayer If I remember correctly, the GLOBAL table is available to modmain. In other scripts, you can access the game's global variables directly.

Also, if possible, it'd be better to preserve the original function. See "Tables as objects (and how to modify their functions nicely):" in this guide.

Edit: You won't have to refer to GLOBAL every time if you store the instances you need.

table1 = GLOBAL.table1-- Same as GLOBAL.table1.vartable1.var = 2

Oh, so I could do the exact same thing in another file, just without the GLOBAL. In front of everything?

Oh and don't worry. I'm changing this games genre, so I can butcher whatever game files I want because mods can't be used with this anyways

[Blueberrys]

Oh, so I could do the exact same thing in another file, just without the GLOBAL. In front of everything?

Yes, and maybe more variables than whatever is in GLOBAL.

Edit: Correction, when assigning a table to a variable, only the reference is copied/duplicated, not the entire table. So if the internal _G variable is modified, it should affect GLOBAL too.

mods.lua for reference:

function CreateEnvironment(modname, isworldgen)	local modutil = require("modutil")	require("recipe") -- for Ingredient	local env = 	{		TUNING=TUNING,		modname = modname,		pairs = pairs,		ipairs = ipairs,		print = print,		math = math,		table = table,		type = type,		string = string,		tostring = tostring,		Class = Class,		GLOBAL = _G,        -- <<--------------------		MODROOT = "../mods/"..modname.."/",		Prefab = Prefab,		Asset = Asset,		Ingredient = Ingredient,		MODCONFIG = KnownModIndex:GetModConfigurationOptions(modname) or {}, -- Direct access to the mod config table (WARNING: modifying it directly while the game is running could result in weird behavior)		GetModConfigData = GetModConfigDataFn(modname) -- Call is GetModConfigData(optionname) to fetch saved value of the specified option (name must match name field in config options table)	} 

[Mobbstar]

Correction, when assigning a table to a variable, only the reference is copied/duplicated, not the entire table. So if the internal _G variable is modified, it should affect GLOBAL too.

 

Fun Fact: Using deepcopy() returns a duplicate of the table, not a reference to the same one.

[Blueberrys]

Fun Fact: Using deepcopy() returns a duplicate of the table, not a reference to the same one.

That's immensely useful information which I wish I had known sooner.