[0.16] The Blueprint Lab 0.2.4

[canisin]

PS: This is my first mod. Any comments and criticism is welcome. Thanks a lot to all mod authors and tutorial writers, from whose work I could learn to work with Factorio, this wonderful game.

Mod Portal: Click!

Enter your lab to design your blueprints.

When you go into your lab, you will leave your character behind. You cannot bring anything into the lab from the outside world and vice versa, except blueprints. While in the lab, cheat mode will be activated and you will find an infinity chest and an electric interface. Use these to design your blueprints.

Current Features:
- The lab is a 512 by 512 featureless space for designing blueprints. You can go to the lab via the lab button in the top left or via the lab hotkey (default: Shift + B).
- When you go to the lab, you leave your character and inventory behind. But if you do so while holding a blueprint or a blueprint book, you will bring a copy of it to the lab.
- In the lab, cheat mode is enabled. Also, an electric interface and an infinity chest are provided.
- In the lab, ghosts are instantly revived and items marked by the deconstruction planner are immediately destroyed.
- You can return from the lab by clicking the lab button or activating the lab hotkey again.
- You cannot bring back items from the lab. But if you return while holding a blueprint or a blueprint book you will bring it back to the world.
- When you return from the lab any non-empty blueprints or blueprint books in your inventory are dropped to the ground. All other items in your inventory are destroyed.
- The lab is persistent and in multiplayer each force has its own separate lab.

Planned Features and Known Issues:
- Bring the player back to the world if their character takes damage.
- Improve the GUI: Use a smaller and more interesting button with a stripe.
- Currently the lab has a fixed size, I would like it to have an unlimited size. But it seems difficult to fight with the world generator. The current model mimics code from [Factorissimo2](https://mods.factorio.com/mod/Factorissimo2).
- An optional (and single player only) ability to pause the game (the rest of the world, the other surfaces) while in the lab. I am not sure if this is possible.

Version History:
0.2.4 - Underground belts, splitters, and loaders are also properly cleared.
0.2.3 - Labs placed in the lab are now inactive, i.e. no research exploit.
0.2.2 - Blueprint transfers added. Russian locale (thanks to ZwerOxotnik) added. Bots and belts are now properly cleared.
0.1.2 - Fixed a bug due to needlessly recreating the interface. Added a proper migration script for 0.0.1.
0.1.1 - Fixed a nil reference bug that occurred when loading a save game from 0.0.1.
0.1.0 - Implemented lab hotkey, clear button, instant ghost revival, revival and deconstruction events, localization and tooltips.
0.0.1 - fixed setup when adding the mod to an existing game.
0.0.0 - initial release.

[mrvn]

Great. Now I can give up on my own mod doing exactly the same.

Here are some features and ideas I was working on:

1) lab sharing in MP so multiple person can work on a blueprint
2) dropping a blueprint on the lab button will open the lab with the blueprint placed and then save the result overwriting the same blueprint (thereby editing the blueprint)
3) Have a roboport with unlimited range and storage chest with every item at the outside of the map (or one in each corner). With variable size space have them move one chunk out from the furthest item placed. Constantly refill the chests when an item is used or empty when too many items are returned.
4) Bobs fusion powered bots (no recharge) for the roboport.
5) Replace labs with pseudo labs that won't do research (maybe researchspeed = 0?) and undo that when saving the blueprint.

[canisin]

Wow! It is such a great coincidence!

Let me go over your list:

1) lab sharing in MP so multiple person can work on a blueprint
> I think this should be working in my mod, as is. I just created one lab surface per force, which should ensure the desired outcome. Haven't tested it, though.

2) dropping a blueprint on the lab button will open the lab with the blueprint placed and then save the result overwriting the same blueprint (thereby editing the blueprint)
> This is a very interesting idea! I quite like it. Currently, my labs are not considered to be attached to a particular blueprint. Instead it is just an area where you can easily work on your blueprints.
The way that my mod is currently doing it, the player has to remember to add any newly created blueprint to their blueprint library. So, I quite like this idea. But I also like the idea that the lab allows you to work on multiple blueprints and have drafts lying around. But, once again, it would be cool to be able to return from the lab with a new blueprint in your "hand". An interesting implementation can be achieved by selecting whatever was around the player at the time they quit the lab. This would require some very clever logic and I don't like "clever" stuff too much, I always prefer clean and simple. Opening the lab with a particular blueprint can cause problems in multiplayer if we would like the lab to be shared by multiple players.

3) Have a roboport with unlimited range and storage chest with every item at the outside of the map (or one in each corner). With variable size space have them move one chunk out from the furthest item placed. Constantly refill the chests when an item is used or empty when too many items are returned.
4) Bobs fusion powered bots (no recharge) for the roboport.
> Instead of this I am trying to replicate "instant blueprint" and "quick deconstruct" behavior in the lab, a la creative mode. Unfortunately, this is not as straight forward as I like, but I am working on it.

5) Replace labs with pseudo labs that won't do research (maybe researchspeed = 0?) and undo that when saving the blueprint.
> I think the idea could work, but at the end of the day, it is the player's decision to use misuse the lab to cheat research. As long as it is not something that might happen to a player inadvertently, I do not think it is something that needs fixing.

Thanks a lot for the ideas, please let me know if you would like to contribute code.

[canisin]

After reading and responding to your other thread, I got thinking about being yanked back to the real world after your character takes damage. The first case that I had thought was whether having an item in your hand when you are yanked back would allow you to cheat by bringing back items from the lab. Then I thought of actually turning that idea into a feature: If you have a blueprint in your hand as you exit the lab, you get to keep it! The same idea works both ways, if you go into the lab while holding a blueprint (i.e. you drag&drop the bp on the button, or hit a hotkey while holding it) you get a copy in the lab. Because otherwise, you have to use the blueprint library in both directions.

[mrvn]

Why not have 2 bodies for the player? One in the lab and one outside. When you get yanked back the body in the lab remains so that when he reenters he continious where he left of.

Another idea I had was to make a surface out of a blueprint book (or the library) where each blueprint is basically a factorissimo style building. The icons for the blueprint are shown over the building and hovering over them with the mouse shows the content in a subwindow. To edit a blueprint you would enter the building.

Note: For MP and the library the buildings could be colored with the players color. And editing is only allowed in your own buildings.

[canisin]

Why not have 2 bodies for the player? One in the lab and one outside. When you get yanked back the body in the lab remains so that when he reenters he continious where he left of.
> Because it works just fine without a character. Being a characterless player enables you to build as if you were building from the zoomed in map view, which is what I usually do when designing blueprints in a quiet corner of the map.

Even though I very much like to imagine my player opening a blueprint and going into the "blueprint dimension" to edit it, I think I will pass on those ideas for the time being.
I think it is more straight forward to think of the lab as a space where you can go and play with your blueprints. It keeps the mod much simpler.

[mrvn]

Right, bodyless is probably better there.

But factorissimo works without body too so that wouldn't be a problem for the blueprint library/book surface.

[tehfreek]

Version 0.1.1 blows up when loading a save with 0.1.0:

Code: Select all

Error AppManagerStates.cpp:1304: Error while running on_configuration_changed: Gui element with name BPL_Flow already present in the parent element.
stack traceback:
        __TheBlueprintLab_bud__/scripts/gui.lua:8: in function 'CreateGui'
        __TheBlueprintLab_bud__/control.lua:15: in function 'InitPlayer'
        __TheBlueprintLab_bud__/control.lua:6: in function 'InitAllPlayers'
        __TheBlueprintLab_bud__/control.lua:23: in function <__TheBlueprintLab_bud__/control.lua:22>

Downgrading back to 0.1.0 lets the save load.

[canisin]

Thanks a lot for letting me know.

That is a bug due to my inexperience in factorio modding.

In version 0.1.x I had used "TheLab" and similar for naming ui elements and surfaces. In 0.2.x I decided to use "BLP_" in my name strings. I then found out that such changes to a mod that is already included in a save cause such issues. I will work on a fix today/tonight.

[canisin]

Version 0.1.1 blows up when loading a save with 0.1.0:

Code: Select all

Error AppManagerStates.cpp:1304: Error while running on_configuration_changed: Gui element with name BPL_Flow already present in the parent element.
stack traceback:
        __TheBlueprintLab_bud__/scripts/gui.lua:8: in function 'CreateGui'
        __TheBlueprintLab_bud__/control.lua:15: in function 'InitPlayer'
        __TheBlueprintLab_bud__/control.lua:6: in function 'InitAllPlayers'
        __TheBlueprintLab_bud__/control.lua:23: in function <__TheBlueprintLab_bud__/control.lua:22>

Downgrading back to 0.1.0 lets the save load.

The issue is now hopefully solved. Please try to update and let me know.

[tehfreek]

The issue is now hopefully solved. Please try to update and let me know.

Working now, thanks.

[Peldor1]

I have used this mod in one of my other saves but ...
It seems to not play well with Pretty Fair Resources mod.

Error while running event prettyfairresources::on_chunk_generated (ID 12)
__prettyfairresources__/pfr/Resources.lua:58: attempt to index field 'autoplace_controls' (a nil value)

[orzelek]

I have used this mod in one of my other saves but ...
It seems to not play well with Pretty Fair Resources mod.

Error while running event prettyfairresources::on_chunk_generated (ID 12)
__prettyfairresources__/pfr/Resources.lua:58: attempt to index field 'autoplace_controls' (a nil value)

You should report it to author of pfr. Having no autoplace is valid and he needs to add some protection.

[victhor003]

Found an exploit, while designing a labs blueprint i found out that the labs in the Blueprint Lab actually work. I think it would be nice if you somehow get a way to stop this from happening. Thanks.

[canisin]

I have used this mod in one of my other saves but ...
It seems to not play well with Pretty Fair Resources mod.

Error while running event prettyfairresources::on_chunk_generated (ID 12)
__prettyfairresources__/pfr/Resources.lua:58: attempt to index field 'autoplace_controls' (a nil value)

You should report it to author of pfr. Having no autoplace is valid and he needs to add some protection.

Not sure if I can help with this.

Found an exploit, while designing a labs blueprint i found out that the labs in the Blueprint Lab actually work. I think it would be nice if you somehow get a way to stop this from happening. Thanks.

Yes, that is a known issue, I was considering it very low priority with the reasoning that it is only possible if the player actually tries to do it. What I mean is unless it is something that can happen inadvertently or by accident, it is the player's choice to exploit it. But just as I was typing this response I realized that this could happen while experimenting with a lab layout and thus it becomes an unwanted side effect, and it gains priority.

So I have done some testing and decided that I can probably fix it by deactivating any labs that get placed while in the lab. I will add this feature and release an update soon! Thanks a lot for your feedback!

Aaand.. it is done. I have released version 0.2.3, which disables any labs placed in the lab.

[quyxkh]

Pretty sure you can fix research effects escaping the blueprint lab by switching the player's force to a dedicated blueprint_lab force and copying the research status on entry. That would also allow for things like setting specific research levels in the blueprint lab, so you can enter it and design green-science layouts then blue-science layouts etc.

For decon this avoids more (all, I think) transport-drop clutter:

instakill

Code: Select all

local function instakill_all_transport_lines(e)
    local l
    for x=1,8 do
        l=e.get_transport_line(x)
        if l then l.clear() end
        end
    end
function instakill(ev)
    local e = ev.entity
    if e.prototype.belt_speed then 
        if e.type=='transport-belt' then
            e.get_transport_line(1).clear()
            e.get_transport_line(2).clear()
        else
            pcall(instakill_all_transport_lines,e)
            end
        end
    ev.entity.destroy()
    end

I don't know how to find out how many transport lines an entity might have, and pcall is the only way I've found to do the can't-tell cases safely.

For instabuild, I use

instabuild

Code: Select all

local empty=setmetatable({},{__newindex=function() error'assigning to empty' end})
function instabuild(ev)
    if ev.created_entity.type=='entity-ghost' then
        inserts=ev.created_entity.item_requests
        if inserts then ev.created_entity.item_requests=nil end
        _,e=ev.created_entity.revive()
        for k,v in next,inserts or empty do
            e.insert{name=k,count=v}
            end
        end
    end

because afaict item requests are always modules.

[canisin]

Thanks for the suggestions. The temporary force thing can definitely be useful if I need to implement further features. Currently inactivating labs as they are placed seems to do the trick.

As for quick deconstruction and instant revival, I think I have fixed the belt items by clearing belts of items before destroying them and I have assumed that they can only have 2 transport lines. But if any new cases come up I'll use your code for inspiration.

Here are the methods that I am using:

Entities that are marked for destruction

Code: Select all

function DestroyEntity(entity, player_index)
    if entity.type == "deconstructible-tile-proxy" then
        DestroyDeconstructibleTileProxy(entity)
        return
    end

    if entity.type == "transport-belt" then
        entity.get_transport_line(1).clear()
        entity.get_transport_line(2).clear()
        entity.destroy()
    end

    script.raise_event(defines.events.on_pre_player_mined_item, 
        {player_index = player_index, entity = entity}) 

    entity.destroy()
end

function DestroyDeconstructibleTileProxy(entity)
    local hiddenTile = entity.surface.get_hidden_tile(entity.position)
    --if not hiddenTile then return end

    entity.surface.set_tiles {{name = hiddenTile, position = entity.position}}
    entity.destroy()
end

Revival

Code: Select all

function ReviveEntity(entity, player_index)
    if entity.type == "entity-ghost" then
        _, revived, request = entity.revive(true)
        if not revived then return end

        if request then
            for requestName, requestCount in pairs(request.item_requests) do
                request.proxy_target.insert {name = requestName, count = requestCount}
            end
            request.destroy()
        end

        script.raise_event(defines.events.on_built_entity, 
            {player_index = player_index, created_entity = revived})
    elseif entity.type == "tile-ghost" then
        entity.revive()
    end
end

[quyxkh]

Splitters and underneathies are the extras I was after with the instakill, generally I think checking transport-belt-speed is likely to identify anything with a transport line.

Then new third return from entity.revive() does obsolete the instabuild suggestion,I didn't notice when that happened.

[canisin]

Oh, got it, the underneathines and the splitters are also leaking. Now I understand. Thanks a lot. Will update and release soon.

Edit: Fixed in 0.2.4.

[Visione]

what a great mod! keep up the work!