Beiträge von doug

Did you ever get an answer to this? The short answer to your question is yes, it can be done. Not from within the construction file, but rather with a game script.

Sorry for responding in English to a question you asked a month ago in German. I just saw the post now.

Google Translate:

Haben Sie darauf jemals eine Antwort bekommen? Die kurze Antwort auf Ihre Frage lautet: Ja, es ist machbar. Nicht aus der Konstruktionsdatei, sondern mit einem Spielskript.

Entschuldigung, dass Sie auf eine Frage auf Englisch geantwortet haben, die Sie vor einem Monat auf Deutsch gestellt haben. Ich habe den Beitrag erst jetzt gesehen.

That's a much bigger project than I am looking to take on.

What you're proposing is perhaps possible, but it will be very complex to implement.

For starters, if a vehicle carrying freight is destroyed, the freight will be lost. This means that the train will have to be allowed to "arrive" at the station and unload before it is destroyed.

When the cargo is unloaded from the train, we would hope to see it all loaded onto the ferry. The vagaries of the TpF pathing system might, however, result in some of the freight looking to catch another train to somewhere unintended.

Similarly, when the ferry docks, it will have to transfer unload its cargo. Again, we would hope to see it all transfer the the correct platform at the adjacent train station, but there would also be no guaranties here.

As the game stands right now, you can't buy a vehicle if you are overdrawn at the bank. One would have to determine if this limitation also exists with vehicles created programmatically. It might pose a problem if it does. In any event, one would need to ensure that the process of transferring a vehicle on and then off of the ferry did not result in gains or losses simply as a result of the destruction and recreation of vehicles.

The final question that crosses my mind right now is getting the trains to stop, and wait for the ferry to dock. I would hate to have to monitor every train on every update callback.

I'm not saying that anything here is impossible, as I'm fairly certain it can all be done (with the possible exception of overcoming potential freight misdirection.)

The amount of work involved will be substantial.

There is no provision for one vehicle to carry another.

It's a fabulous idea, which is, unfortunately, simply not supported by the game.

It will work for vehicles. You just have to add a ground face entry to the construction.

PM me the model file and I'll set it up.

So I got it working.

A couple of things:

From the documentation:

Zitat

To improve performance, for simple constructions that do not contain ground faces, terrain alignments, edges or depot/station/industry/town building definitions, there is no construction placed in the game but just the seperate mdls. These can not be configured afterwards or be deleted all at once. Furthermore these types of assets do not support the labelText custom texts from constructions.

Note the last sentence.

Also, the array is zero-based, not one-based, so we need:

result.labelText[0] = {labelOptions[params.Line+1]}

Further, we need to add one of the data types mentioned in the quote above, so that we get an actual construction on the map, rather than a bare model.

Guessing here...

Maybe the "label" in their example is actually required. Maybe you want:

result.labelText = { 
 [1] = { "Label", labelOptions[params.Line+1]} 
}

I think you want something like this:

local constructionutil = require "constructionutil"

local labelOptions = { "1 Geen Dienst", "1 Garage", "1 Centraal Station"}

function data()
return {
type = "ASSET_DEFAULT",
description = {
name = _("Trolleybus 101"),
description = _("Museum trolleybus 101 from Arnhem (The Netherlands)"),
},
availability = {yearFrom = 1944, yearTo = 1959},
buildMode = "MULTI",
categories = { "Trolleybus" },
order = 31368,
skipCollision = true,
autoRemovable = false,
params = {
{
key = "Pantographs",
name = _("Type"),
values = { _("Pantographs up"), _("Pantographs down") }
},

{

key = "Line",

name = _("Line Indicator"),

values = labelOptions

},

},

updateFn = function(params)
local result = { }
result.models = { }
if params.Pantographs == 0 then
result.models[#result.models+1] = {id = "asset/bus/Trolleybus 101 asset.mdl", transf = constructionutil.rotateTransf(params, {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, }), }
elseif params.Pantographs == 1 then
result.models[#result.models+1] = {id = "asset/bus/Trolleybus 101 asset low.mdl", transf = {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, }, }
end
result.terrainAlignmentLists = { {
type = "EQUAL",
faces = { }
} }


result.labelText = {
[1] = {labelOptions[params.Line+1]}

}
return result
end
}

end

I deleted some of the extra line breaks so the changes I made would stand out a little:

I put your line choices in a table at the top.

I added a menu option to allow the user to choose which one they want.

At the bottom, I pass the chosen value in the label.Text table. You only have one model in the construction, so the index needs to be 1

In the labelList in the model file, you will then change the label type to 'CUSTOM' to retrieve the value that you have passed in from the construction.

I've never tried this, but here is the reference to how that might work:

https://www.transportfever2.co…tructionbasics#label_list

The warehouse builds separate menu items for each five year period of time. It does this so that you will only see appropriate track types, regardless of when you access the station. This does mean that 30 lists of tracks get assembled each time you access the menu. If those lists contain a lot of calls to strings.lua, then it may be what is slowing the whole thing down.

I'll PM you a test version that forces the calls to strings.lua to take place in postRunFn. It will also allow you to change the five year period to something longer.

How the heck do you tag someone here?

The output of industries is dependent on three factors:

Demand - output will gradually rise or fall to meet the demand that our transport lines connect the industry to.

Supply - output will be limited by the raw materials available, if applicable. Again, the user controls the availability with transport lines.

Neither of these can be influenced programatically, other than by changing the supply rules.

The third factor is a hard limit, imposed by the "level" variable.

Changing the supply rules, or the level variable, requires, at a minimum, invoking the updateFunction in the industry's construction file. Changing the supply rules may require more than that - I'm not sure.

You might want to have a look at the following:

https://steamcommunity.com/sha…iledetails/?id=1967520065

https://steamcommunity.com/sha…iledetails/?id=1970151023

The first of these is doing essentially what you're looking to do - change the production level of the indstry in question. (You don't need to call the setPlayer function that this mod does.)

The second changes the number of production levels available for each industry. It does so by implementing a modified version of industryutil.lua

Glad to see that you got it working!

The vanilla files use the wretched industryutil.lua to actually define that stuff, based on the "curves" definitions in the .con or .mdl files.

You're probably better off writing a .mdl file that defines nothing more than a single cargo lane. You can use multiple instances of the same .mdl file to define all of the storage areas you want.

There is documentation here:

https://www.transportfever2.co…structiontypes#industries

This is another mod I wrote that uses a game script (see line 36):

local bookAmount = 0
local previousYear = 0
local dsdRevenueRate = -0.05


local function dsdGetRate()
    local info = debug.getinfo(1,'S')
    local filePath = string.sub(info.source, 2)
    local res =  string.find(filePath, '/res/')
    local scriptPath = string.sub(filePath, res)
    local settingsFile = string.gsub(filePath, scriptPath, '/settings.lua')

    local dsdRevenueSettings = loadfile(settingsFile) 
    if dsdRevenueSettings ~= nil then
        local settings = dsdRevenueSettings()
        local rate = dsdRevenueSettings().rate / 100
        dsdRevenueSettings = nil
        return rate
    else
        return -.05 --failsafe fallback value; 5% tax
    end
end


local revenueScript = {
    save = function ()
    end,

    load = function (state, reset)
    end,

    guiUpdate = function ()
    end,

    update = function ()
        if previousYear ~= game.interface.getGameTime().date.year then
            dsdRevenueRate = dsdGetRate()
            previousYear = game.interface.getGameTime().date.year
        end
        if bookAmount ~= 0 then
            game.interface.book(bookAmount, false)
            bookAmount = 0
        end
    end,

    handleEvent = function (src, id, name, param)
        if name == 'JOURNAL_ENTRY' then 
            if param.type == 'VEHICLE_INCOME' then
                bookAmount = bookAmount + (param.amount * dsdRevenueRate)
            end
        end    
    end,

    guiHandleEvent = function (id, name, param)
    end,
}

return revenueScript

res/config/game_script is where you need to be if you want code that is executed on an ongoing basis. Absolutely everything in mod.lua is executed at load time only, and is never touched again.

As I mentioned above, you don't need to get hung up on the save/load serialization thing - just stick to the engine thread.

The problem that is going to arise is this:

You're going to need to define a custom set of production levels for the industry(ies) in question. That you can likely do in postRunFn, although I have not tried that myself.

You will then need to trigger the updateFn from within the game_script while specifying the revised production level as one of the parameters. game.interface.getGameTime() will work here, so you can determine when you need to do this.

I'm hoping someone else can chime in here, as you have reached the end of my knowledge on this. I'm sorry, I wish I could be of more help.

Where are you running this code? Is this a construction modifier function within mod.lua? If so, it will not work, as that code is only run once, when the game loads.

Zitat von mauporte

I am also having trouble with this: I want to be able to run a loop that checks the current year and at several milestones I'd change stocks for several industries.

as far as I understand it in order to get the year, I need to write a script in the gui thread which sends data 'game.interface.getGameTime() . date.year' to a variable in 'save' using 'sendscriptevent' the whole process needs to be "handled" with handleEvent then I can save that value in "load" and the transference of information from gui thread to the engine thread will be complete. Meaning that I can finally use the value in my if statements.

Is this right? it feels like way too complicated just to get a simple value of 4 digits. also if someone could help me with some examples, as the explanations I've found haven't really told me much and I have bee running tests all day to no avail.

If you're running a game script, then you can call game.interface.getGameTime() directly in the engine thread. You don't need to call it in the gui thread to then use the horribly awkward serialization routines to get that value into the engine thread.

Have a look at my Railway Warehouse mod. I use the construction year to determine which type of platform sign to add to the station.

Specifically, on line 64 of dsd_warehouse_rail_2.script, I assign the incoming construction parameters to the local variable "params"

Then, much later, on line 436, I test params.year against the value 1950 and build the signs accordingly.

Keep in mind that this value (params.year) does not change once the particular construction is built - what you're getting is not the current year, but rather the year the station/asset/etc was first built at that particular location.