Mooncat wrote:That's why error occurred when I placed a matter void pointing a matter source.
I think I have had this error crop on pointing a void at a cargo wagon also.
when i had that crash in the old version, it was because i had not only one but 6 voids at a wagon and then rotated one of them. is this problem fixed too ("pointing a void at a void") ?
can00336 wrote:
Optera wrote:Using instant research does that without the need of placing an entity.
Yes, but it does not allow you to test research timings compared to lab numbers.
just put a few item sources to a lab and they will quickly fill it. if you need this for several labs, make a blueprint.
but when i tested something related to labs, i found that the biggest problem with timing was the throughput of belts that feed the labs. most visible on some research that requires 3 or 4 science packs of each color and even a blue belt couldn't supply a long line of labs. to test such aspects, you can't use autofilling labs or similar anyway, but need a real setup with belts, inserters, labs, and item sources which fill the belts.
hansinator wrote:BTW: The reason I've got so many test setups and creative mode entities is that each time I make some changes to a design I copy it and place it next to the old version to have something like a version history ...
I imagine it would be simpler if I could just place a special flooring and make an entity or menu that allows me to blueprint what's inside such a special flooring area ...
why don't you just make normal blueprints, and store them in a book. then use some existing mod like foreman and save those blueprints or books. that would even allow you to import them back to any other testmap later.
Mooncat wrote:
Anson wrote:btw: since an item source can not only fill belts, but also can directly fill chests and wagons, i first had tried unloading a wagon too by directly placing an item sink (matter void) next to it. that didn't work.
It is already implemented. But I suppose the (intentional) inconsistent settings have confused you.
Open a matter void -> to the top left, open its settings menu -> tick "Can remove from vehicles in front".
didn't i say recently that all the options of CM are an adventure by themselves ? :-)
i simply had not seen that (after selecting an item source or a void) there is an additional menu button at the top left that serves to set lots of options for those items.
btw: i also discovered only recently that item sources offer the settings of filter inserters (eg "set filters") when connected with some wire. now i have used this in a setup to replace a creative provider chest and a requester chest (and roboport and bots, etc): just tell the item source whether and which items are needed :-)
when i deselected the item, the button and the options disappeared, and when i opened another item, the button appeared together with the options window. it's nice since i only need to open that window once and will always be presented with the additional options. is this intended? does this work for all other CM items too?
Nexela wrote:Script Crash - Using healer wand on entites that are destroyed in another mods on_built_entity
ah.... so the entities are destroyed when they are built....
Error 404: brain.exe not found...
But it will be fixed in the next version! Thanks for the detailed report.
Nexela wrote:Also while this is being fixed can you add revived=true to the event table that is passed to on_built_entity after calling revive()
I can. But I will need more time because I will have to improve the event log system so that the parameter created by myself won't produce "unrecognized parameter".
Nexela wrote:Request #21342352132412321.09
Item_stack details for modifier wand if entity is item-on-ground!
What details are you looking for? I can't put everything on the UI, so it is better if you can tell me what you want. Maybe I can also do it for other entities.
Anson wrote:when i had that crash in the old version, it was because i had not only one but 6 voids at a wagon and then rotated one of them. is this problem fixed too ("pointing a void at a void") ?
Yes. The bug was about pointing a burner entity without inventory. A Matter Void is a burner inserter, so it should be fixed.
Anson wrote:when i deselected the item, the button and the options disappeared, and when i opened another item, the button appeared together with the options window. it's nice since i only need to open that window once and will always be presented with the additional options. is this intended? does this work for all other CM items too?
Yes, intended. (Implemented in v0.2.1) And it works for all entities that have such button.
Nexela wrote:
What details are you looking for? I can't put everything on the UI, so it is better if you can tell me what you want. Maybe I can also do it for other entities.
stack.name and stack.count should be plenty
And if the item is ghost:
ghost.ghost_name, ghost.ghost_type Would be nice also
Mooncat wrote:Enjoy. Please report bugs as usual. When things go to this scale, it is very likely that fixing a bug will introduce more bugs. :P
New personal cheat: repair mined item.
i started a new map with lots of mods, and on starting it for the first time I clicked "yes" to have CM enabled, but i didn't want any cheats yet. quite a while later, i did some turret creep and was wondering why some turrets never were damaged after mining them (i "always" had repaired them first, but i think that i sometimes forgot and was wondering where to find the damaged turrets :-), while others were still damaged after mining them.
after rereading the last release notes of SM, this new cheat might be the cause?
since i didn't activate any cheats, the default should be to not repair mined turrets, right ?
I'll have to test this in more detail when i have enough time and do the next turret creep, this time carefully watching which turrets are damaged and whether some really are repaired, but here are two notes on those turrets:
- the turrets that i think were repaired were normal turrets (maybe modified by bobs or whatever, but still MK1 and thus relatively vanilla)
- the unrepaired turrets were sniper turrets, a new type from some mod, thus not vanilla
and now for some fun :
Mooncat wrote:v0.2.6 has been released.
- New entities: super beacon, 7 super modules: speed, ...
big question - how fast can a smelter do its work
electric furnace with max speed beacons (AKA Warped Electric Smelter).PNG (383.1 KiB) Viewed 9318 times
the setup for this creative experiment is the max area around one smelter entirely covered by creative beacons (total of 69x69-1 beacons), each with max number of speed modules (7 creative speed modules each, total of 33k modules). one more beacon had to be sacrificed to power the smelter since even the creative big power poles couldn't reach the center of this large area. i also needed some space to feed the smelter and to void its output. btw: when i placed this setup from a huge blueprint to an otherwise empty map, factorio went down to 3 fps for 10 seconds, and then froze for another 10 seconds while the beacons started to work. it then recovered to a stable 40 fps/ups.
you can see the resulting crafting speed in the screenshot :-) btw: did you notice the formatting of the percentage increase ? :-)
now the second big question : what is the resulting throughput/production of this smelter ?
in theory, the required time for one plate should be 3.5 seconds (= 210 ticks) divided by the crafting speed, and the production is the reciproke = almost 400 plates per tick :-)
after thinking about how to measure this, i could come up with no solution, since every measuring method would limit the throughput drastically (at least when i want to measure up to 400 plates per tick :-) and thus i had to resort to using the ingame production statistics ... result = 3600 plates per minute, or 1 plate per tick :-(
it seems that after all, we only need a much smaller setup to get max throughput of smelters, and that even the best beacon setup (also in vanilla) can not give more than 216000 plates per hour with a single smelter :-)
for comparison : i think this is the max speed for vanilla smelters, beacons and modules, with throughput/production of 16440 per hour (274 per minute, less than half a yellow belt, measured with ingame stats)
vanilla smelter with max speed.PNG (413.77 KiB) Viewed 9318 times
assignment for homework :-)
:geek: how does the smallest setup for maximum production look when using only vanilla items and loaders, plus creative beacons and speed modules? (belts may be fed and voided out of screen any way you like)
- what would the max production of such a smelter be ?
- how close to the theoretical max of 216k per hour ???
- hint: this is 3600 per minute,
or 1.5 x 2400; start with the vanilla layout above
:-)
:ugeek: same, but without loaders (this can get more complicated)
Some force modifiers like inserter_stack_size_bonus are already available in the ui which is great for testing mods at different stages of the game. It would be nice to (re)set all force modifiers separately from the ui.
Most of all I'd like being able to tweak: character_logistic_slot_count, character_trash_slot_count, worker_robots_speed_modifier, worker_robots_storage_bonus.
I could also see advantages in being able to tweak set_ammo_damage_modifier, set_gun_speed_modifier, set_turret_attack_modifier when balancing new weapons/turrets.
StickyNotes, which I'm developing, messes up when Creative Mode's Instant Blueprints are used. Is there any way I can detect if Instant Blueprints are enabled or disabled to add workarounds if they're active? I tried using your interface to check if creative mode is enabled or not... but much to my surprise, it looks like instant blueprinting remains active even if you disable creative mode.
Maybe I missed an easy way to check... but if not, would you be inclined to add an interface to allow checking of whether a setting (like instant blueprints) is enabled?
Anson wrote:i started a new map with lots of mods, and on starting it for the first time I clicked "yes" to have CM enabled, but i didn't want any cheats yet. quite a while later, i did some turret creep and was wondering why some turrets never were damaged after mining them (i "always" had repaired them first, but i think that i sometimes forgot and was wondering where to find the damaged turrets , while others were still damaged after mining them.
after rereading the last release notes of SM, this new cheat might be the cause?
since i didn't activate any cheats, the default should be to not repair mined turrets, right ?
I'll have to test this in more detail when i have enough time and do the next turret creep, this time carefully watching which turrets are damaged and whether some really are repaired, but here are two notes on those turrets:
- the turrets that i think were repaired were normal turrets (maybe modified by bobs or whatever, but still MK1 and thus relatively vanilla)
- the unrepaired turrets were sniper turrets, a new type from some mod, thus not vanilla
Yes, the new cheat can automatically repair turrets and it works only when it is turned on. I can't reproduce this bug so far but I will keep an eye on it.
Optera wrote:Some force modifiers like inserter_stack_size_bonus are already available in the ui which is great for testing mods at different stages of the game. It would be nice to (re)set all force modifiers separately from the ui.
Most of all I'd like being able to tweak: character_logistic_slot_count, character_trash_slot_count, worker_robots_speed_modifier, worker_robots_storage_bonus.
I could also see advantages in being able to tweak set_ammo_damage_modifier, set_gun_speed_modifier, set_turret_attack_modifier when balancing new weapons/turrets.
I was thinking about the same while implementing the new team cheats. But as more and more cheats are introduced, I think we need a cleaner UI to organize them. And because UI update is involved, I want to do it only after 0.15 is released.
NiftyManiac wrote:StickyNotes, which I'm developing, messes up when Creative Mode's Instant Blueprints are used. Is there any way I can detect if Instant Blueprints are enabled or disabled to add workarounds if they're active? I tried using your interface to check if creative mode is enabled or not... but much to my surprise, it looks like instant blueprinting remains active even if you disable creative mode.
Maybe I missed an easy way to check... but if not, would you be inclined to add an interface to allow checking of whether a setting (like instant blueprints) is enabled?
The current approach of "Disable CM" is simply just hide the CM menu. It doesn't disable the cheats. This will be changed in the future.
About instant blueprint, I have been busy for awhile so I haven't tried your updated StickyNotes yet. I need to investigate on the problem before coming up a proper solution. Right now I am thinking of adding remote interfaces for returning the status of Instant Blueprint/Deconstruct, and adding/removing items to be instant blueprinted/deconstructed. I will tell you when I have the answer. Sorry for the inconvenience.
NiftyManiac wrote:StickyNotes, which I'm developing, messes up when Creative Mode's Instant Blueprints are used. Is there any way I can detect if Instant Blueprints are enabled or disabled to add workarounds if they're active? I tried using your interface to check if creative mode is enabled or not... but much to my surprise, it looks like instant blueprinting remains active even if you disable creative mode.
Maybe I missed an easy way to check... but if not, would you be inclined to add an interface to allow checking of whether a setting (like instant blueprints) is enabled?
The current approach of "Disable CM" is simply just hide the CM menu. It doesn't disable the cheats. This will be changed in the future.
About instant blueprint, I have been busy for awhile so I haven't tried your updated StickyNotes yet. I need to investigate on the problem before coming up a proper solution. Right now I am thinking of adding remote interfaces for returning the status of Instant Blueprint/Deconstruct, and adding/removing items to be instant blueprinted/deconstructed. I will tell you when I have the answer. Sorry for the inconvenience.
I guess Sticky Notes uses multiple entities that need to be linked during on_create. Depending on the entity list, instant blueprint might build entities first that are meant to be created by script only. At least that's why I had to add specific checks against this in my Logistic Train Network.
To prevent every mod with multiple entities to check for Instant Blueprint, CM instead should check if an entity has a recipe and only build those which do.
Optera wrote:I guess Sticky Notes uses multiple entities that need to be linked during on_create. Depending on the entity list, instant blueprint might build entities first that are meant to be created by script only.
Sort of; the entities can be placed fine, but they look for surrounding ghosts when placed to link with. Normally when a blueprint is placed everything is ghosts, so StickyNotes knows what's been newly placed. With instant blueprints, ghosts get placed and revived on the same tick, which make it problematic if my on_creation is sometimes called before and sometimes after the revival.
A better solution, I think, would be to have instant blueprints allow ghosts to exist for one tick, and revive them on the next if the ghost is still there. That way all mods can reasonably expect the standard behavior of "here's a ghost that may get revived in the future" when listening to on_creation.
Optera wrote:I guess Sticky Notes uses multiple entities that need to be linked during on_create. Depending on the entity list, instant blueprint might build entities first that are meant to be created by script only.
Sort of; the entities can be placed fine, but they look for surrounding ghosts when placed to link with. Normally when a blueprint is placed everything is ghosts, so StickyNotes knows what's been newly placed. With instant blueprints, ghosts get placed and revived on the same tick, which make it problematic if my on_creation is sometimes called before and sometimes after the revival.
A better solution, I think, would be to have instant blueprints allow ghosts to exist for one tick, and revive them on the next if the ghost is still there. That way all mods can reasonably expect the standard behavior of "here's a ghost that may get revived in the future" when listening to on_creation.
I was trying to make changes on your code to fix the issue, but then I found another issue that happened even when instant blueprint and CM were both disabled (i.e. global.instant_blueprints_enabled is false):
Blueprint a Sticky Note + Note Data
Place the blueprint. The Note Data is revived and shown as expected
When the Sticky Note is built by a robot, another Note Data is created, which is the issue.
This doesn't happen if the entity is not a Sticky Note or Sticky Sign.
Then, I further investigated and found the problem: after an entity is revived, its unit number is changed. Therefore, your original line 616
local note = global.notes_by_target[ent.unit_number]
can never find the expected note.
I think I have solved this issue. Tested with and without instant blueprint. Tho I can't reproduce issue #10.
And for the original problem, I have refactored your code to make it works without the need for knowing instant blueprint. (The commit comments say another thing, because I thought a part of the code is not needed.)
Would you mind inviting me to your repo so I can create pull request?
I don't like people relying on the status of instant blueprint (even if I will provide it), because you never know whether there will be another mod that has this function.
But I love your idea of delaying a tick before reviving the entities. I will check on it.
About your code, is there any reason why you do a 20x20 search for "invis-note" when a non-ghost entity is created? I worry this will affect performance if many entities are built within a short time.
Nice, thanks for fixing the bugs I should have dealt with . I'll add you to the repo, though the standard way of contributing would be forking it and pull-requesting from your fork.
Mooncat wrote:This doesn't happen if the entity is not a Sticky Note or Sticky Sign.
Yeah the notes and sign entities really aren't as tested as they should have been, they're a bit broken atm. I mostly just add notes to existing entities. I think I'll just get rid of most of the old custom note/sign code and let them act just like all other entities with respect to adding notes.
Mooncat wrote: is there any reason why you do a 20x20 search for "invis-note" when a non-ghost entity is created
Yeah. Basically, there's a big problem in figuring out when a ghost has been deleted, since there's no corresponding event. So if I place a blueprint with notes, and then an unrelated building is placed overlapping the existing ghost, the ghost disappears but I have no way of knowing. So the ghost's note sticks around. My hacky solution was to re-validate every nearby note on every non-ghost on_construction. It's not generally a performance issue... but with instant blueprints it could become one. I could probably buffer on_creation events and trigger a cleanup in their neighborhood every so often it it's an issue. If a ghost is removed via deconstruction planner, I have even less idea of how to check, since no events get fired on deconstruction commands. Best I can think of is a periodic validation of all notes on the map.
NiftyManiac wrote:though the standard way of contributing would be forking it and pull-requesting from your fork.
woops I'm still new to git. It was my first time to fork a repo and make a pull request. Please check.
NiftyManiac wrote:Best I can think of is a periodic validation of all notes on the map.
I think this idea is good! I would implement it like this:
Whenever a invis-note is placed, check its linked target. If it is a ghost entity, put the invis-note into an array for further check...
It will be a nested array. The first layer has a fixed size. Maybe 60x10. Each cell is an array of invis-notes to be checked at the current tick.
By dividing the invis-notes into 60x10 arrays, you can separate the workload into 600 ticks (10 seconds). I.e. Each invis-note will be checked for every 10 seconds.
(This idea came from FFF #161)
If the target is still a ghost entity, nothing will done, so it will be checked again later.
If the target is not a ghost anymore, the invis-note will be removed from the array.
If the target is invalid, remove the invis-note.
I will leave the actual implementation to you.
If you kill a spawner and then try to place rails over it with a blueprint, the rails are marked red and not placed. This Problem does not occure in vanila and as fas as i tried only applies for rails.
If you kill a spawner and then try to place rails over it with a blueprint, the rails are marked red and not placed. This Problem does not occure in vanila and as fas as i tried only applies for rails.
Sorry for the late reply, a bit busy these days.
Thanks for the report. I will check it soon.
Edit: I have verified it. The bug is caused by the additional items that can build the spawners. I don't know why this makes their corpses collide with blueprint.
But I think I can fix this by creating additional spawner entities, so the natural ones will remain the same as vanilla.
New options on the modifier popup: to be looted, revive.
New remote function for registering your entities so they will be ignored by the instant-blueprint cheat: remote.call("creative-mode", "exclude_from_instant_blueprint", "<entity-name>")
Also the same for the instant-deconstruction cheat: remote.call("creative-mode", "exclude_from_instant_deconstruction", "<entity-name>")
A remote function for deregistering your entities from the blacklist of the instant-blueprint cheat: remote.call("creative-mode", "add_back_to_instant_blueprint", "<entity-name>")
Same for the instant-deconstruction cheat: remote.call("creative-mode", "add_back_to_instant_deconstruction", "<entity-name>")
And a remote function checking whether your entities have been ignored by the instant-blueprint cheat: remote.call("creative-mode", "has_excluded_from_instant_blueprint", "<entity-name>")
Same for the instant-deconstruction cheat: remote.call("creative-mode", "has_excluded_from_instant_deconstruction", "<entity-name>")
- Changes:
Modding: entity revival casued by instant blueprint or the Healer magic wand now raises on_robot_built_entity and on_robot_built_tile instead of on_built_entity and on_player_built_tile respectively.
the "robot" parameter will be nil
the index of player who triggered the revival will still be stored in the "player_index" parameter
- Improvements:
Clicking "Yes" from the initial popup will also unhide the recipe category of creative tools.
Delayed the effect of instant blueprint by 1 tick to increase mod compatibility. This leads to the following improvement.
This makes instant blueprint doesn't work on the text plates that are placed with blueprints if your Text Plates mod version is below 0.1.16. Please update to v0.1.16 to fix this issue.
When both instant deconstruction and instant blueprint are turned on, shift-placing a blueprint can now revive the ghosts that collide with other deconstructable entities, e.g. trees.
Modding: the events from entity revival (on_robot_built_entity, on_robot_built_tile) now contains an additional boolean parameter "revival" with the value true.
Modding: all events raised from this mod now contains an additional string parameter "mod" with the value "creative-mode", which is the ID of this mod.
Event logging now supports undocumented parameters and will show their data types. For boolean, number or string parameters, their values will also be shown.
A pair of double quotes are added outside the values of string parameters in event logs.
Event logs now also show the ghost_name, stack and unit_number of entity parameters if they support such values.
The modifer popup now shows more info about the selected objects. If the objects in the same have different values, e.g. unit number, only 10 values will be shown in maximum.
The super logistic robot and super construction robot now have absolute resistances, i.e. 100% resistance to all damange type.
The enemy spawners and worms provided by this mod are now minable, repairable, blueprintable, and deconstructible. The natural spawners and worms remain unchanged.
The suffix "(Creative Mdoe)" is added to their names to distinguish them from the natural ones.
New option in config.lua, creative_mode_config.enemy_spawners_and_worms.add_name_suffix, for disabling the suffix.
- Fixes:
Fixed the bug that instant blueprint removed the item requests of ghosts even though they cannot be revived due to collision with other entities.
Fixed error when reviving text plates from the Text Plates mod using the Healer magic wand.
The alien attractor marker will not move anymore after spawned.
The corpses of destroyed enemy spawners and worms should no longer be a problem when you place blueprinted entities over them.
While I'm working on the supportive turrets mod, I realized I can apply some turret mechanisms to other weapons, thus I turned it into supportive weapons mod. But then, I will need to spend more time to finish it. So, I decided to update CM first and here comes the new version.
As 0.15 is coming, I think it is a good idea to talk about my plan here. Once 0.15 is released, I will make some quick updates for all of my mods (that worth) to make them work in 0.15. During this period, no big features will be introduced.
After that, I'm thinking about a complete rework on the CM mod. But at the meantime, I'm quite busy and cannot guarantee whether I can do that. But I will still try my best to implement the planned features, especially the programmable enemy spawner.
The on_robot events you are raising should send robot=game.players[index] (the player object) and not nil. The event itself returns robot as non optional and if another mod does "if robot.valid" (even though robot should be valid sense it is sent from an event) it will error on nil robot causing a script crash.
This will also allow the "player" to be treated as a robot in instances where scripts might change/remove the item from the "robot/players" inventory.
Nexela wrote:The on_robot events you are raising should send robot=game.players[index] (the player object) and not nil. The event itself returns robot as non optional and if another mod does "if robot.valid" (even though robot should be valid sense it is sent from an event) it will error on nil robot causing a script crash.
This will also allow the "player" to be treated as a robot in instances where scripts might change/remove the item from the "robot/players" inventory.
I was aware that some APIs may only be usable on robots but not players. If such APIs are used on players, the game will still crash. But after a quick search, it seems not be the case.
However, I don't think the player should be treated as a robot, because it is Creative Mod. The player is god. ( )
In vanilla games, when a on_robot_built_entity/tile event is invoked, the robot is always at the same position of the entity/tile. But it is not the case for the player in CM. The player can be at very far away from the revived entities/tiles. It would be weird if a mod alter the player's inventory.
If I send the player as "robot", mods will need an additional check to see whether "robot" is actually a robot. Compared to this, I think it would be better to just keep "robot" nil.
I admit this is not a perfect solution, but I have 153 mods (Angle's, Bob's, Yuoki's, AAIs and many others) in my testing environment and have no issue so far. Hope this helps.
Edit: just added the 12 5dim mods. No issue when I placed down a blueprint with instant-blueprint turned on. But I may have missed something. Please feel free to report any bug.
Mooncat wrote:But it is not the case for the player in CM. The player can be at very far away from the revived entities/tiles. It would be weird if a mod alter the player's inventory.
This has more to do with on_robot_mined but is equally valid in on_robot_built
It doesn't matter where the player is. And there are mods that do make use of changing the robots picked up item. It hurts nothing to pass the player object as the robot. I agree the majority of the mods don't need this but on_robot passes a robot in all cases, By you raising on_robot with a nil robot you are forcing other mod authors to add additional un-needed checks to their on_robot_built if they expect a robot.
Mooncat wrote:But it is not the case for the player in CM. The player can be at very far away from the revived entities/tiles. It would be weird if a mod alter the player's inventory.
This has more to do with on_robot_mined but is equally valid in on_robot_built
It doesn't matter where the player is. And there are mods that do make use of changing the robots picked up item. It hurts nothing to pass the player object as the robot. I agree the majority of the mods don't need this but on_robot passes a robot in all cases, By you raising on_robot with a nil robot you are forcing other mod authors to add additional un-needed checks to their on_robot_built if they expect a robot.
Dang it. How can I forget aubergine's solution: https://github.com/aubergine10/lifecycl ... events.lua
Just send {valid = false} and problem is solved. I will also send type = "player" and name = "player", in case some modders like to check the entity type and name before checking valid. Should have bookmarked this repo.