[MOD 0.12.18] OverBobs - Bob's mods add-on mod

[OvermindDL1]

This location is now deprecated. Please go to the new location for all updates by visiting here.


OverBobs - Bob's mods add-on mod

• Name: OverBobs
• Version: 0.0.2
• Factorio-Version: 0.12.14
• Description: Adding various 'missing' parts for Bob's mods, generally uses scripting
• License: Indeterminate as of yet, bleh
• Release: 2015-12-31
• Download-Url: Download
• Website: http://files.minecraftforge.net/Overmin ... index.html
• Dependencies: Base, soon to be Bob's mods based on what is used within it
• Category: Gameplay
• Tags:

Long description

Long description
As invariably happens with any game I play, I always make a mod of little useful things that I find missing, and now I have made one for Bob's mods.

Currently only one item:

Item Collector, looks like the radar, needs a new image sometime, I should shrink it to 2x2 sometime as well, but for now it acts as a radar however it marks nearby items that are laying on the ground to be picked up by the logistics network (construction bots) whenever it completes a full charge in a 64x64 radius. Its purpose is to replace the often-breaking Artifact Collector that I use from Natural Selection in a less 'cheaty/transporty' way, plus this one has no ontick, an energy cost, can pick up anything that lays on the ground (love keeping my ground clean), and requires construction bots, which feels far more balanced to me, although I may need to fudge with its recipe, seems too simple currently, a radar and electronic circuits. Unlocks with Automated Construction.

Pictures

Version history

Version 0.0.2 (2015-02-20):
Fixed it so it does not work on radars too (removed debugging code)... >.> (Thanks to Supercheese for noticing)
Version 0.0.1 (2015-12-31):
Initial Version
Added Item Collector

[OvermindDL1]

<Reserved>

Please post any recommendations to add, any ideas to make anything better, etc... etc...

[GameCharmer]

Is there anything in this that actually relies on a bob mod?

[OvermindDL1]

Is there anything in this that actually relies on a bob mod?

In the currently released single building no, but it will use bobs intermediates soon. The current in-dev building for 0.0.2 is requiring bobs immediately.

[GameCharmer]

Ahh, fair enough. It might be worth-while to release what you've got so far as a stand-alone mod. I'm currently using it and absolutely love it.
I've knocked together 2 additional tiers, ramping up from 32 to 64 and 128, increasing power requirements along the way. I'm using a ton of mods that add more base defenses, including supreme warfare, so I'm constantly flooded with the tiny alien artifacts. This has been a major help.

[OvermindDL1]

Ahh, fair enough. It might be worth-while to release what you've got so far as a stand-alone mod. I'm currently using it and absolutely love it.
I've knocked together 2 additional tiers, ramping up from 32 to 64 and 128, increasing power requirements along the way. I'm using a ton of mods that add more base defenses, including supreme warfare, so I'm constantly flooded with the tiny alien artifacts. This has been a major help.

Natural Evolution has been the mod that absolutely floodfills my map with enemies (plus the fact I play with enemy settings absolutely maxed out from the start) and I keep having issues with the Artifact Collector just stopping working in my long lasting games. I was considering tiers as well but I want a new graphic first, at the very least I wanted the functionality to replace the hoard of artifact collectors I used to have that stopped working on my latest world, so that was its purpose, plus it forced me to expand my logistics coverage and significantly increase my built constructor bots.

The building I am working on right now is a short range teleporter, my SO is getting a bit irritated at my huge pipe labyrinths so I am trying to come up with a good design. I do not want a GUI, it must be dead simple to use, and I want it directional, but accumulators cannot be directional it seems, so I am debating on two styles right now, either a single 'plate' that you walk on and it teleports you a short distance based on the direction you walked on to it from, or perhaps to a receiving teleporter in that direction, or I can do an accumulator based power supply for a directional teleporter that you place next to it that would either teleport a short distance in the direction it is facing or to a receiving teleporter in that direction. I am not quite happy with either style (walking direction or the facing direction of the entity) and I would prefer a linked teleporter system rather than just a flat direction, but for that I would prefer a connected graphic similar to how underground belts 'link', but for players, and using power. Thus I am fighting with engine limitations right now, and it seems that I would not get out of using an on_tick handler for this, which does truly bug the ever living tar out of me (I want to be able to either register a location callback for walking into or be able to register a callback for listening to colliding events between a player and specific entities, either would remove the need for a ticking handler easy).

Factorio's LUA API is just not a component based design much as that would simplify things as well, instead we have these hardcoded types like "accumulator" and "belt" instead of composable pieces we could put on a custom type like "power" or "collision_callback" and so forth. I would love to be able to specify my own new entity type by doing something like:

Code: Select all

{
	name = "teleporter-linked-mk1",
	icon = "blah",
	max_health = 150,
	etc...,
	accumulator = {whatever_settings=...}
}

Where basically you would have a set of variables that are required for all entites, like name, and anything else, like collision_box, would actually be a component assigned to the entity. Internally the component 'collision_box' would actually be in the physics handling system and the assigned entity is just a UUID of some form. This pattern allows for extremely efficient handling in the engine while allowing for any style of mixing of components that you would want. A component is just a data container, and the systems operate over 0-to-N components and all entities associated with them, such as the rendering system would be iterating over an efficient quadtree structure of position components and whatever component defines the images for the entity. The engine having a defined type for every different functionality is extremely limiting and is no doubt internally to the engine leading to a class-splosion where you have a handler per type iterating over the entire bulk list of all of those objects as necessary for those types, efficient for sure, but extremely restrictive.

Would continue ranting about the lua API, but have to go....

[Supercheese]

The item collection feature is great, it definitely beats the other item-collector mods in terms of performance, since this mod doesn't rely on the "on_tick" method.

However, in your control.lua I noticed:

Code: Select all

script.on_event(defines.events.on_sector_scanned, function(event)
	if true or event.radar.name == "collector-grounditems" then
...

Note the "if true or ..." which means that the item collection triggers whenever any radar scans a sector, not just the special item collection radars. You probably had this in there for testing purposes or some such, and I believe you'll want to fix it for your next release.

[OvermindDL1]

The item collection feature is great, it definitely beats the other item-collector mods in terms of performance, since this mod doesn't rely on the "on_tick" method.

However, in your control.lua I noticed:

Code: Select all

script.on_event(defines.events.on_sector_scanned, function(event)
	if true or event.radar.name == "collector-grounditems" then
...

Note the "if true or ..." which means that the item collection triggers whenever any radar scans a sector, not just the special item collection radars. You probably had this in there for testing purposes or some such, and I believe you'll want to fix it for your next release.

Fixed, sorry about that miss. ^.^

0.13, so close...

[Timeslice]

The building I am working on right now is a short range teleporter, my SO is getting a bit irritated at my huge pipe labyrinths so I am trying to come up with a good design. I do not want a GUI, it must be dead simple to use, and I want it directional, but accumulators cannot be directional it seems, so I am debating on two styles right now, either a single 'plate' that you walk on and it teleports you a short distance based on the direction you walked on to it from, or perhaps to a receiving teleporter in that direction, or I can do an accumulator based power supply for a directional teleporter that you place next to it that would either teleport a short distance in the direction it is facing or to a receiving teleporter in that direction. I am not quite happy with either style (walking direction or the facing direction of the entity) and I would prefer a linked teleporter system rather than just a flat direction, but for that I would prefer a connected graphic similar to how underground belts 'link', but for players, and using power. Thus I am fighting with engine limitations right now, and it seems that I would not get out of using an on_tick handler for this, which does truly bug the ever living tar out of me (I want to be able to either register a location callback for walking into or be able to register a callback for listening to colliding events between a player and specific entities, either would remove the need for a ticking handler easy).

As a temporary workaround she could just use an obscene amount of high tier exo's in her suit, as they basically let you walk through walls...

On that note, can you control entity collision? It seems like a good solution might be a suit module (jet boots? hoverboard?) that disables collision with non-moving entities and has a constant drain on suit power. If at all possible then it would be alot less fiddly than teleporter pads.