Suggestion: Can the cost of Alien

[vfinn]

Can the cost of Alien Plates escalate for each FORCE, rather than globally? I support this mod in Brave New Oarc mod, and run a server hosting Brave New Oarc with Alien Modules (Search Maroons to find it). But Oarc has each team in a separate force, with a separate spawn location. It's unfair that the first persons to join get the most amount of modules cheaply. I'd like it to be even for each force, where based on the quantity of alien ore they process the cost of the modules/plates increase as it does now, but separately for each force.

It seems that global.modulelevel, global.currentmodulelevel and global.killcount could be used as array items where global.modulelevel = {}

Then update which ever global.modulelevel[player.force.name] causes the kill.

Let me know if you have time for this, if not and you might consider incorporating a branch modification, I can make the changes.

Thank you

[vfinn]

I see that someone else asked for this and you addressed it by saying the module upgrade code would have to be rewritten. I did a review of the code and it looks pretty straight forward on doing this. I will do a pull request and work on adding "Force Name" to the modules and module updates. find_entities_filtered supports finding entities within a force for each type of entity. update_enabled_recipe would be modified to take a force as a parameter instead of enumerating each force.

For credentials - look at Brave New Oarc - to see my mod. I can make your mod work with the progression working for each force, but before I spend any more time on it, I would like to know if you would review and merge the changes into your main branch for re-release ?

on_nth_tick would loop through each force comparing global.modulelevel["Force Name"] to see if that force module level needs updating. It would then add force="Force Name" for the force that needs updating to each filter. update_recipes already takes a forceName as a parameter - so no changes there. The UI would display on each player for their force and I'm sure alot more - but I'll find it and update it.

Please agree to merging in the branch I modify and I'll do the work. If you hate what I've done - you can tell me to go blow, but I suspect the changes won't be rewrites. I've got 40 years of coding experience, and working with other peoples code.

[renoth]

Yes i would do a review, but i think there are people more experienced with LUA that made PRs previously to this repo. I would not know how to test the changes except in singleplayer so i will have to take your word that it works ;)

[vfinn]

I'd provide enough detail to you and a simple compare will show that what I think could be done with a very light touch to your code will provide us Oarc players a nice enhancement to Alien Modules. My main concern is that you re-release these changes from your normal Factorio (https://mods.factorio.com/mod/alien-module) site. I'd use 1.4.0 as the new number unless you recommend something different.

Thanks and talk soon

[vfinn]

Hi Johannes - I just wanted to send an update.  I've completed the coding and initial testing, and all is working well. I still have a fair amount of testing to complete with other players, which I will start today. I've branched your source base, and will check things in once I've got to a high confidence level that it's going to work without fail.  

Nothing major changed other than changing your three global variables into an array. Since Oarc enables changing of forces from a menu, I had to add on_player_created event again to verify the force name in update_gui since it could change after player created, and before the player joins the game and has decided on the force they are joining. I had to add the update_gui code after I put in the on_player_created, so on_player_created code is maybe not needed, but it doesn't hurt anything.

Since the update_modules code runs every 2 seconds and only when a single force modules have leveled up, the lag is spread a little more evenly over time. Not every entity is updated at once.

No issues so far.

Once done - I might want to change the on_nth_tick to run every 10 seconds instead of every 2 seconds to further help reduce lag, which on very large builds will become an issue.  Another option is to break up the calls to module updates so that calls to the updates are spread over a time period and have less impact - so instead of all of them occurring every 2 seconds, one will occur every second, but is 1/10th the time required to update all of the modules.

Let me know your thoughts on this.  I may do this as a secondary release, since I'm anxious to get a full test in - after some smaller preliminary tests.

Also if you want to monitor chatter - join my discord https://discord.gg/WbpTEpWP  Vinnie aka JustGoFly

On Wednesday, February 14, 2024 at 03:16:25 AM EST, Johannes Renoth ***@***.***> wrote:  

Yes i would do a review, but i think there are people more experienced with LUA that made PRs previously to this repo. I would not know how to test the changes except in singleplayer so i will have to take your word that it works ;)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[vfinn]

Update on testing: We did a multiplayer test - all ran, no crashes, two bugs and further testing needed. Bugs:

• Each team was notified when any team's modules were updated - fixed in pp function
• both teams modules upgraded but the second team always stayed at the first teams level - working on that.

Each team works without knowing what level any other team is at. They see their own killcount and module level, not everyone elses. Only their entities will update when they progress from one level to another.

[vfinn]

OK - second issue was actually not a bug. I dropped buildings in his base in editor mode - so it had my last-user - and as such followed my module level. Once we removed and replaced the modules into his building they followed his module level - all working fabulously. I'll be ready for check in tomorrow. This really improves Team Based mods !

[vfinn]

I added a "/log_am" command that dumps the tables for review :

1 Player: JustGoFly, force: JustGoFly, module level: 33, current module level: 33, kill count: 7223 2 Player: Spzi, force: Spzi, module level: 49, current module level: 49, kill count: 14534

I'll check in changes tomorrow. I want to run a few more tests with more players on more teams.

[vfinn]

I worked out the kinks with the above 2 player game. Then hosted a larger game with a group of players. This worked out very well but exposed a bug. I wasn't upgrading the modules in a players inventory properly. Players at level 5 were getting level 25 modules. I found and fixed this bug, and am planning a retest before posting the code.

1 Player: JustGoFly, force: JustGoFly, module level: 34, current module level: 34, kill count: 78872 2 Player: Trophium, force: Trophium, module level: 14, current module level: 14, kill count: 6062 3 Player: Spzi, force: Spzi, module level: 25, current module level: 25, kill count: 22084 4 Player: blue1999, force: blue1999, module level: 1, current module level: 1, kill count: 242 5 Player: eifel, force: eifel, module level: 1, current module level: 1, kill count: 69

[renoth]

Great news! Looking forward to the PR

[vfinn]

I branched 1.3.0 and modified into 1.4.0 for teams. Three separate team tests, aside from my local testing. The latest test has five players, each leveling up independently - two players on the same team: 1 Player: JustGoFly, force: JustGoFly, module level: 34, current module level: 34.472233007764, kill count: 76479 2 Player: Spzi, force: Spzi, module level: 35, current module level: 35.675460034433, kill count: 88730 3 Player: Trophium, force: Trophium, module level: 1, current module level: 0, kill count: 0 4 Player: Aeolus3165, force: Main Force, module level: 3, current module level: 3.9668780719946, kill count: 1231 5 Player: Dugler, force: Main Force, module level: 3, current module level: 3.9668780719946, kill count: 1231

All working well when running with Brave New Oarc - and will run equally well with Oarc or other team based mods.

I'm not the best with GIT - running from Visual Studio. I branched, but keep getting errors trying to push the changes: "Failed to push to the remote repository. See the Output window for more details. " and as you would expect nothing is posted in the Output window - lol

I don't use git the way you do for my mod. So please advise how I can upload these changes. They are done.

[vfinn]

I branched the code, made the changes in my branch, but am unable to perform a pull request. It does not show that I have a branch or tag.

I submitted a release with both the mod zip and the github source base as you have it, but it won't let me publish the release because I have no tag.

Is there something you must do to assign this list of comments a valid branch enabling me to check in this release. When I do a pull request it requires a branch to choose from. My branch does not show up, It shows 0 Open. I am unable to perform a pull request.

My branch is located: https://github.com/vfinn/factorio-alien-module

[renoth]

There seem to be no changes pushed to your repository so far

[renoth]

You need to commit the changes and then push them to your fork of the repository. Afterwards we can open a pull request to this repository.

If you are coming from subversion you have to be aware that git commit does not PUSH the changes to the origin (github). You not only need to commit locally but also push your commit to the respository defined as origin. (git push)

[renoth]

you can also push from the console and see if you get a usable error message.

[vfinn]

I was able to make a pull request after forking the code.

https://github.com/renoth/factorio-alien-module/pull/83

[renoth]

One question: What happens if i load a saved game from Version 1.3.0? Do i keep the Alien Module Level?

[renoth]

When i load my 1.3 save i get the following error, seems like i need to add a migration

[renoth]

Added a migration and released 1.4.0. Thank you very much for the implementation and idea!

[renoth]

There is one problem: If i play singleplayer the module level does not go up and it is caused by this line:

If i remove it, it works fine. Do you know why this is added?

[renoth]

Fixed this and released 1.4.1 without that line. If it is needed for multiplayer please provide a fix where both modes are possible.

[vfinn]

Not needed for oarc, but won't hurt it, so good catch.

[vfinn]

oarc fails with crash in control line 382 - because "player" is not initialized. Can you add this at top of control.lua?

script.on_init(function()
    initVariables()
    init_gui()
    verifyCountersForForce("player")    -- initialize single player
end)

[renoth]

Thanks for the fix, i will do this when i have the time (probably tomorrow)