Brave New OARC Scenario


This mod is a scenario that overhauls multiplayer merging Brave New World and OARC for an awesome single player / multiplayer game. Play on teams or solo in your own base, while other players do the same. Chat with players, learn from their builds. You get to do your own design. You choose to play legacy character mode, or BNO Mode where you have no body, unable to craft anything yourself (lazy bastard) and must command bots to build everything. You start with resources and a little power.

Scenarios
10 days ago
1.1 - 2.0
2.47K
Environment Logistic network

g Bumble Bots Compat

1 year, 7 months ago

By chance might there be a way to make this compatible with Bumble Bots?
Mod here: https://mods.factorio.com/mod/bumble-bots
It reskins the Roboport/Bots/Chests, and the Roboport reskin seems to clash with this mod's Roboport stuff in some way.

The startup error I get is as follows:
Failed to load mods: brave-new-oarc/prototypes/entity/roboport-main.lua:48: attempt to index field 'hr_version' (a nil value)
Stack Traceback:
brave-new-oarc/prototypes/entity/roboport-main.lua:48: in main chunk
[C]: in function 'require'
brave-new-oarc/data-final-fixes.lua:4: in main chunk

1 year, 7 months ago
(updated 1 year, 7 months ago)

What I believe is happening is bumble-bots is removing the vanilla roboport definitions rather than just changing them. This will break any mod that attempts to modify roboports AFTER bumble-bots. Bumble-bots SHOULD do this in data-final.lua. So if you rename my data-final.lua to data.lua and bumble-bots data.lua to data-final.lua it will make them run AFTER I make my changes.

My data-final.lua used to be a data.lua in 4.2.17 but Krastorio makes changes to bots in data.lua and I needed to move my changes after Krastorio's to change the bots to the way my mod offers for bot changes.

bumble-bots does this in data.lua:

-- get rid of mask for vanilla port to let the base graphics shine through
local vanillaRoboport = data.raw["roboport"]["roboport"]

for k, v in pairs({
"base", "base_animation", "door_animation_up",
"door_animation_down"
}) do table.remove(vanillaRoboport[v].layers, 2) end

Removing all definition of vanilla roboports, anyone who tries to modify a roboport after that will cause a crash.

If above makes no sense to you - join my discord and we can talk.
https://discord.gg/B9FJDndY

I may have time in 2 or 3 days to look at this and offer a more permanent solution.

1 year, 7 months ago

Thanks for the swift reply. I'd have reported it likewise to the Bumble Bots page, but it seems rather abandoned. No updates in 3 years and no replies to issues in roughly the same amount of time. If there isn't a way to fix it here, I may try forking it if I'm able given its license.

1 year, 7 months ago

Deleting the code above from the data.lua will allow other mods that also modify roboports to work. I need the base roboport to make my own larger - modified roboport. Deleting the base is just rude, and doing it in data.lua basically means - NO MOD that tries to access a roboport will work. They must have loads of reports of not working with many other mods.

Doing it in data-final, AFTER my mod runs - which would mean bumble-bots info.json would need to put

"? brave-new-oarc" in to define the load order - or I put them into my info.json. Which I can test once I fix a current issue that I'm working on.

The recommendation I made in the first note to rename some files, should work. But that would mean you would have to share those files with everyone who joined your server or they would download the old versions. If you intend to start an open server - let me know and I'll see if I can fix it in my mod.

I can play with load order to get it to run after my mod makes my large roboport. That roboport would not be modifiable by the Bumble-bots though

1 year, 7 months ago

Check here - likely MANY more mods won't work with bumble-bots
https://mods.factorio.com/mod/bumble-bots/discussion/5fe99c82740858eb42132653

1 year, 7 months ago

I'll have to try forking it then, see if I can follow your advice and move the offending changes down the line or remove them.

1 year, 7 months ago

I posted a message in bumble-bots discussion stating what needs to be done:
https://mods.factorio.com/mod/bumble-bots/discussion/65a37071ed14434fde6c2ef2

His shine through comment on that piece of code is ...

1 year, 7 months ago
(updated 1 year, 7 months ago)

Took your advice and renamed Bumble Bots' data.lua to data-final-fixes.lua and deleted the above code piece to test, and sadly still getting the same "attempt to index field 'hr_version' (a nil value) error. I'm not a very experienced modder, if you happen to spot anything else meddling with roboports destructively within Bumble Bots, would you mind letting me know so I can strip/edit it and test until I have a compatible fork?

(Did try renaming to data-final.lua just to cover all bases, but while that did load both together without issues, none of the Bumble Bots stuff loaded)

1 year, 7 months ago

If it helps, I notice that there isn't a high-res variant for Bumble Bots reskins that I can see. Could that be the problem?

1 year, 7 months ago

No - it's that they delete the normal roboport definition. When you modify a roboport, instead of defining every single item, you copy the base vanilla roboport, and modify each item you want to change. Even if you modify EVERYTHING in the roboport, that is advised, since they could add a variable that you don't know about down the road. So copying the base, modifying it and it changes in the future, you won't break. What BumbleBots does is in data.lua - before anyone in data-final.lua has access to the roboport definition. It copies it, modifies it then DELETES IT ! So no one else can touch it. He patched some mods that people complained about to work - but still why would they do this. This is very bad, and coded such that any other mod that tries to make a variant of the roboport, either has to define it from scratch (bad programming), or force bumble-bot to run after it does. So either I modify my mod to force bumble-bot to run after I make my copy, or he fixes his code. I have not looked at what Bumble-bot does, maybe it's something I want to support, and could work on. I just finished a version I've been working on, but need to do further testing. So this has to wait. Let me know how you make out with my recommendation. It should at least get you working and would aid me in proving that what I said does fix this issue and not cause any other problems.

1 year, 7 months ago
(updated 1 year, 7 months ago)

I got bumble bots working with BNO - it was pretty much what I said above but here are specifics:

1) In info.json of Bumble-bots they must add BNO to dependencies.
Since Bumble bots removes existance of a roboport, which BNO copies and modifies, it must decide which mods will be allowed to run, and by adding BNO to it's list it decides when it runs - which adding to it's dependency list it says load this first.

    "? brave-new-oarc",

added to the list of mods in it's info.json.

2) bumble-bots must rename data.lua to data-final-fixes.lua.
This forces data-final-fixes to be run last in the data stage. This enables any other mods to run their code to copy roboports before bumble-bots destroys the existance of the roboport entity.

BNO renamed data.lua to data-final-fixes.lua to force it's modification of the bots to run after all of the mods we support - specifically Krastorio2, to over ride Krastorio's changes to bot speed (much slow).

1 year, 7 months ago

Many thanks! Haven't been on in a while, sorry for the wait. By chance, do you recall which lines specifically in Bumble Bots delete the roboport? I already removed the above offending lines in my testing, but the error was still coming through. This is what I removed:

-- get rid of mask for vanilla port to let the base graphics shine through
local vanillaRoboport = data.raw["roboport"]["roboport"]

for k, v in pairs({
"base", "base_animation", "door_animation_up",
"door_animation_down"
}) do table.remove(vanillaRoboport[v].layers, 2) end

1 year, 6 months ago
(updated 1 year, 6 months ago)

I haven't tested removing those lines. What I did was changed the order in which the Roboport is copied - allowing Brave New Oarc to copy the roboport for that special roboport, then allow Bumble Bots to do whatever it wants with the definition of the roboport. The info listed in the message prior to yours is all you need to do to get it to work. Adding support for brave-new-oarc - and renaming data.lua to data-final-fixes.lua in bumble-bots. This forces the BNO mod's data-final-fixes to run before BB's, and pushes the changes BB makes to roboports to be done after BNO loads.

Also read through the log file while testing to be sure you are running the version of BB that you modify. You should change the version number.

1 year, 6 months ago

Will do, thanks.

New response