Page 1 of 1

[0.10.0] New modding possibilities

Posted: Fri Jun 06, 2014 6:42 pm
by drs9999
Added set/get/clear filter methods to access inserter filters

Code: Select all

Name:	        getfilter(integer filterindex)
Returns:	        itemname; nil if filter is empty
Description:	returns the name of the item for the selected filter;
		        if the filter is empty it returns nil
Note:		can be called on smart-inserters only
Example:
-- selected entity has to be a smart-inserter
-- prints the itemname that was selected in the first filterslot
game.player.print(game.player.selected.getfilter(1))

Code: Select all

Name:		setfilter(string itemname, integer filterindex)
Returns:	        nothing
Description:	sets the given filterslot to the passed itemname
Note:		can be called on smart-inserters only
Example:
-- selected entity has to be a smart-inserter
-- sets the first filterslot to raw-wood
game.player.selected.setfilter("raw-wood", 1)

Code: Select all

Name:		clearfilter(integer filterindex)
Returns:	        nothing
Description:	clears the given filterslot
Note:		can be called on smart-inserters only
Example:
-- selected entity has to be a smart-inserter
-- clears the second filterslot of the inserter
game.player.selected.clearfilter(2)
Added set/get/clear requestslot to access requester chest requests

Code: Select all

Name:		getrequestslot(integer slotindex)
Returns:	        itemstack; nil if requestslot is empty
		        (itemstack = table with "name" and "count" keys that holds the relevant values) 
Description:	returns the current configuration of the passed requestslot
Note:		can be called on entities that have requestslots only
Example:
-- selected entity is a requester-chest
-- prints the configuration of requestslot 3
game.player.print(serpent.block(game.player.selected.getrequestslot(3)))

Code: Select all

Name:		setrequestslot(itemstack, integer slotindex)
Returns:	        nothing
Description:	configurate the passed requestslot
Note:		can be called on entities that have requestslots only
Example:
-- selected entity is a requester-chest
-- configurate the chest to accept 1k raw-wood (the first slot is used)
game.player.selected.setrequestslot({name="raw-wood",count=1000},1)

Code: Select all

Name:		clearrequestslot(integer slotindex)
Returns:	        nothing
Description:	clear the passed requestslot
Note:		can be called on entities that have requestslots only
Example:
-- selected entity is a requester-chest
-- clears requestslot 4
game.player.selected.clearrequestslot(4)
Added set/get/clear methods for circuit conditions.

Code: Select all

Name:		getcircuitcondition(integer circuitType)
Returns:	        table similar to itemstack, but with an additional "operator"-key
		        that contains the operator (<, >, =) as a string
		        retuns nil if entity is not part of the passed network
Description:	returns the circuitconditions of the entity
Note:		can be called on smart-inserters only
Example:
-- selected entity has to be a smart-inserter
-- the defines.lua file contains "constants" for the different circuitTypes
-- prints the red-wire circuitconditions
game.player.print(serpent.block(game.player.selected.getcircuitcondition(defines.circuitconnector.red)))

Code: Select all

Name:		setcircuitcondition(integer circuitType, table condition)
Returns:	        nothing
Description:	sets the circuitconditon for the passed circuitType
		        condition-table similar to itemstack, but with an additional "operator"-key
Note:		can be called on smart-inserters only
Example:
-- selected entity has to be a smart-inserter
-- the defines.lua file contains "constants" for the different circuitTypes
-- sets the red-wire circuitcondition
condition = {name = "raw-wood", count = 600, operator = ">"}
game.player.selected.setcircuitcondition(defines.circuitconnector.red, condition)

Code: Select all

Name:		clearcircuitcondition(integer circuitType)
Returns:	        nothing
Description:	clears the circuitcondition for the passed circuit-type
Note:		can be called on smart-inserters only
Example:
-- selected entity has to be a smart-inserter
-- the defines.lua file contains "constants" for the different circuitTypes
-- clear the green-wire & logistic circuitcondition
game.player.selected.clearcircuitcondition(defines.circuitconnector.green)
game.player.selected.clearcircuitcondition(defines.circuitconnector.logistic)
Added lua interfaces to force to get/set modifiers

Code: Select all

Name:		getammodamagemodifier(string ammo-category)
Returns:	        current value
Description:	returns the current ammo-modifier for the given ammo-category
Note:		nothing
Example:
-- prints the damagemodifier for bullet-type ammo
game.player.print(game.player.force.getammodamagemodifier("bullet"))

Code: Select all

Name:		setammodamagemodifier(string ammo-category, number newValue)
Returns:	        nothing
Description:	sets the current ammo-modifier for the given ammo-category
Note:		nothing
Example:
-- set the damagemodifier for bullet-type ammo to 10 (10 times the normal-damage)
game.player.force.setammodamagemodifier("bullet", 10)

Code: Select all

Name:		getgunspeedmodifier(string ammo-category)
Name:		setgunspeedmodifier(string ammo-category, number newValue)
        both work similar to get/set ammodamagemodifier

Code: Select all

Name:		getturretattackmodifier(string turretname)
Returns:	        current value
Description:	returns the damage-modifier for the given turret
Note:		nothing
Example:
-- prints the modifier for laser-turrets
game.player.print(game.player.force.getturretattackmodifier("laser-turret"))

Code: Select all

Name:		setturretattackmodifier(string turretname, number newValue)
Returns:	        nothing
Description:	sets the damage-modifier for the given turret
Note:		nothing
Example:
-- doubles the modifier for laser-turrets
game.player.force.setturretattackmodifier("laser-turret", 2)
new Read/write Properties for luaForce:

Code: Select all

- laboratoryspeedmodifier
- logisticrobotspeedmodifier
- logisticrobotstoragemodifier
- inserterstacksizebonus
- numbercharacterlogisticslots (read only)
- numberquickbars
- maximumfollowingrobotscount
- ghosttimetolive (unit is gametick)
Expanded connectneighbour-method

Code: Select all

Name:		connectneighbour(entity targetentity [,integer circuitType])
Returns:	        true on success; otherwise false
Description:	creates wires between electric poles and/or valid entities
Note:		can be called on electric poles only
		        the circuitType is optional, if not used copper-wire is used
Example:
-- the start electric pole is stored in startPole
-- selected entity is another pole that is reachable
-- create copper, red-/green-wire connection between poles
startpole.connectneighbour(game.player.selected) --copper-wire
startpole.connectneighbour(game.player.selected, defines.circuitconnector.red) --red-wire
startpole.connectneighbour(game.player.selected, defines.circuitconnector.green) -- green-wire
-- selected entity is now a smart inserter
-- connects the inserter with the pole
startpole.connectneighbour(game.player.selected, defines.circuitconnector.green)
Simple API to write to disk (makefile, removepath)

Code: Select all

Name:		makefile(string path, string/number data)
Returns:	        nothing
Description:	creates file that contains the passed data
		        path is relative to the script-output-folder
Note:		user actions are restricted to the script-output-folder
Example:
-- creates a file that contains a dummytext in the root-folder
dummyText = "bar"
game.makefile("foo.txt",dummyText)
-- creates another file (and folder if needed)
dummyText2 = "apple"
dummyNumber = 3.14159265359
game.makefile("recipies/applepie.txt",dummyText2 .." "..dummyNumber)

Code: Select all

Name:		removepath(string path)
Returns:	        nothing
Description:	removes everything in the specified path
		        path is relative to the script-output-folder
Note:		user actions are restricted to the script-output-folder
Example:
-- remove the files which were created in the previous example
game.removepath("foo.txt")
game.removepath("recipies")

Re: [0.10.0] New modding possibilities

Posted: Fri Jun 06, 2014 6:43 pm
by drs9999
API to take game screenshots

Code: Select all

game.takescreenshot{TABLE}
takes a table as parameter, if an empty table is passed the default values are used, this also applies to not specified table-entries

parameters aka table-entries (default values in []-brackets) are:

Code: Select all

player = [the player/controller]
position = [the player/controller position]
resolution = [{x = 640, y = 480}]
zoom = [1]
path = ["screenshot.png"]
showGui = [false]
Examples:

Code: Select all

-- create screenshot with default parameters:
game.takescreenshot{}
-- create screenshot with higher resolution and store in "script-output/highRes"
game.takescreenshot{resolution={x=1024,y=1024},path="highRes/MyScreenshot.png"}

Re: [0.10.0] New modding possibilities

Posted: Fri Jun 06, 2014 7:38 pm
by muzzy
makefile and removepath have an issue which allows the mod to figure out username of the player by bruteforcing the path until a hit is found. Using a filename "../../../../../muzzy/Library/Application Support/factorio/script-output/test.txt" will only work if the current user is named "muzzy" (and he's on OSX).

This could be used to make a mod that does different things depending on who's playing. For example, if "kovarex" is playing, the mod could make the game a little harder for him "just because". :)

Edit: or can the script actually figure out if the file was created or not? Nngh, maybe it can't after all. So, nevermind...

Re: [0.10.0] New modding possibilities

Posted: Fri Jun 06, 2014 8:47 pm
by MF-
I believe that ability to create and write files basically ANYWHERE is definitely not okay

Perhaps if it wrote to some "autoexec" place?
on linux you'd usually need "+x", but for some of the MIME stuff you don't need +x
also you might not need +x for a ".desktop" file

Re: [0.10.0] New modding possibilities

Posted: Fri Jun 06, 2014 8:55 pm
by drs9999
user actions are restricted to the script-output-folder
That is what the devs told me. Just to point it out a bit clearer

EDIT: Added takescreenshot description in the second post

Re: [0.10.0] New modding possibilities

Posted: Fri Jun 06, 2014 10:54 pm
by JamesOFarrell
Is there a way an official way to check the version number in the API? I would like to start messing with filters and requester chests. I've come up with this:

Code: Select all

function getApiVersion()
	if pcall(function () game.removepath("versioncheck") end) then
		return "0.10"
	else
		return "0.9"
	end
end
It seems to work but it is a little hacky.

Edit: Also thanks for the new fun things to play with

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 6:47 am
by drs9999
If you do not want/need backward compability you can define the base-mod version in the info.json
E.g.

Code: Select all

"dependencies": ["base >= 0.10.0"]
Other than that your solution does not look that bad/hacky to me

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 7:37 am
by MF-
I guess you could abuse that to actually provide a version API?

(make a "version" mod that will have a version for each factorio version and ship the new API
Provided that adding them all to a mod list wouldn't make the game fail to load, but just skip the ""incompatible"" versions of "version")

Can't you just read the other mod's version at runtime, though?

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 10:24 pm
by JamesOFarrell
The idea they use for working with javascript, as features between browsers are inconsistent, is to test the API before you use it. So if you want to do some work with requester chests you test a logistic-container entity to see if it has getrequestslot then go to town but that is way to much work and the exception handling adds unnecessary overhead. I just worry in the future I am going to do something stupid like call a file versioncheck then spend a day trying to work out why the it keeps getting deleted.

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 10:35 pm
by drs9999
JamesOFarrell wrote:The idea they use for working with javascript, as features between browsers are inconsistent, is to test the API before you use it. So if you want to do some work with requester chests you test a logistic-container entity to see if it has getrequestslot then go to town but that is way to much work and the exception handling adds unnecessary overhead. I just worry in the future I am going to do something stupid like call a file versioncheck then spend a day trying to work out why the it keeps getting deleted.
What?!?

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 10:39 pm
by JamesOFarrell
drs9999 wrote:What?!?
Did none of that make sense?

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 10:47 pm
by drs9999
I simply did not understand anything

Re: [0.10.0] New modding possibilities

Posted: Sat Jun 07, 2014 11:01 pm
by JamesOFarrell
Honestly, it was a pretty pointless post and not really worth understanding. What I was saying was that instead of checking the version of factorio once and basing the features your mod supports on that you check the features you want to use are supported by the API as you go. So if you want to enable some requester chests features you don't see if people are using > 0.10 you see if the logistic-container has the function getrequestslot and that it returns the value you expect. If that passes you know that what ever version of factorio the user is using supports a known working getrequestslot function and you can enable the part of your mod that works with requester chests. This actually give you a little forwards compatibility as well because if the API changes the check fails. That all said, no one would ever actually do any of that because it is not worth the effort.

The thing about the versioncheck file was because in the code I posted I checked the factorio version by seeing if I could delete a file called versioncheck.

Re: [0.10.0] New modding possibilities

Posted: Sun Jun 08, 2014 8:53 am
by drs9999
Now I get it :D
But I agree that this is not worth the effort. Imo there is no really need to be backward compatible. On the other hand something like game.getversion() could be useful especially because it would be really easy to implement.

Re: [0.10.0] New modding possibilities

Posted: Sun Jun 08, 2014 9:12 am
by JamesOFarrell
drs9999 wrote:something like game.getversion()
I could get behind that idea.

Re: [0.10.0] New modding possibilities

Posted: Sun Jun 08, 2014 9:18 am
by someloser
:roll: