I comment here as it seems I can't create issues on github for this mod
I however regreat as in all your vehicle mods that any vehicle is private. I'm now working on a small api to allow keys to be used on entities (new issue/improvement request)
I noticed that when used with also the old helicopter mod, textures file names are colliding, one of the helicopters will get ugly texture as uv changed. (new issue)
modname changed and there is no compatibility layer to switch old entities (new issue)
we cannot more grab back helicopter to inventory, weird as they can fit in inventory when crafting them (same goes for all your vehicle mods). (personal taste not really an issue)
If I give a positive feedback it's really because I like it. It seems bug free now (c.f.: log out/log in old mod)
I commented mostly on point I do not like just because I initially wanted to create issues on github.
As already mentioned this mod, is forced to be packed in modpack for cdb now.
As a consequence it was over one year that all my updates were fud only, I updated the main repo. but forgot to update submodule on the proxy modpack.
I quite never play in creative mode, so the first review I made on this mod was about an inconsistency between creative and survival mode. I fixed the wrong behavior in survival without seeing it reintroduced bad behavior in creative mode. I will have a look at the bug you pointed in creative mode.
About the guards, this is in my plans but not at the top of my to do list. Got to think about group behavior first to limit time consuming path finding bomb aborted by collisions. I also got to get more familiar with damage management before, I'm a noob modder, I just feel bit more confortable in areas of the API I already explored, damage system is not one of them.
Planned things to do before this one are:
Waffle core: Automatize waffle production.
Lumberjack core: use choppy/lumberjack/chainsaw mod/tools to allow cutting tree and replanting them.
Allow stock exchange between maidroids via a shared marketplace for maidroids, accessible only if maidroid got a teleport tube.
Use maidroid as shops.
More things I eventually do before guards core. So it may take time.
This suggestion was already done on the original maidroid's bugtracker.
The link to pdisc is also available in the readme and pdisc appears as optional depend in mod.conf. The main problem remain that pdisc is not available in CDB.
I will maybe try to ask lwscratch dev if it would be possible to expose his forms as a an API, so maidroids could have new language.
Features I would like to add to this mod:
Trees: add compatibility with technic chainsaw and/or lumberjack mod to allow maidroids to harvest and regrow trees. I just need to think a bit about how to find the bottom wood block of any tree.
Shop: maidroids could sell their inventory items against some other items.
Cooperation: maintain a list of required/available so inactive maidroids can take items from other to regain job.
Place ladders climb through them and extend A* pathfinding to be able to use ladders on Y axis. (Heavy work if extending API)
Builders: build things according schematics.
Those are all only thoughts, no work done yet. I also find that the original maidroid github repository exposes a lot of ideas, like fighters and so.
Currrently I'm mostly losing all my free time playing CTF, so don't hope to see any progress soon, any bugs will be treated faster.
1/ Ah yes, I noticed it in creative mode, but didn't think about the behavior when dropping items in world. Nice to have many eyes on things.
I will have a look on it next week, the week end is dedicated to my kid. But I guess this part will be alledgely skipped
2/ The tool would also to copy "secrets" from any node with key callbacks.
Also from entities, as I plan to make maidroids shareable via keys too, with support for both modes I exposed in doors redo.
I want to switch from old helicopter mod, to APercy version but none his vehicle are shareable, I will need some keys for those vehicles too.
For entity keys, I plan to make a very small API only mod.
I will keep in touch so we can check if it's better located in doors_redo or in a standalone mod.
Saw that the protected_modes and transportable locked doors I worked on was closed on your bt.
Does it mind if I open a package approval request here ?
I added a flavor = "mazes_80" line to the mod to allow to differentiate it from your version if required at some point.
I like so much the idea of 'transporting secret' that I may make a tool to copy secrets from any type of locked things (chest, door, ...). The idea slowly maturates.
I don't use discord, but may make some feedbacks on github because the fork of maidroid I maintain is compatible with animalia.
These droid can milk cows and feed them, shear sheeps, and kill overnumerous poultries.
breeding planned: I guess for animalia breeding should be only: feed animals
Would be nice too keep me in touch if you change those parts:
breeding
feeding
milk production
There was some breaking changes in your mod when you dropped mobkit.
I'm waiting for the breed system to work again.
Cpu usage were done mostly to improve maidroid, as it supports animalia, mobs redo and petz, they were also running meanwhile. Also I wanted to change petz on my server by more lightweight mod.
Petz: 29% 15>mobs<25
Animalia: 27% 50>mobs<60
Mobs redo: 3% 10>mobs<15
Maidroid: 5% 5 mobs. -> those tests allowed to improve things
Test done in september, values may be slightly wrong as I didn't save results, this is just what I remember.
I tested new features about keys with:
* default mtg keys
* keyring mod
All seems ok about keys
I didn't test anything else but it didn't change much, just was actualized to match current mtg doors mod.
Besides all this update got rid of most luacheck complains, except unused args (they are only for prototyped funcs so not a big deal)
There was only one annoying thing with a function declared as global.
Writing this message encouraged me to update things, I'm quite finished yet.
I need to test things after, then I'll open a temporary repository on github or gitlab
I used this mod but dropped it now as it doesn't support keys:
I think the doors mod from minetest_game has been updated since a while.
Now it register a on_skeleton_key_use for any of the registered doors/trapdoors
This redo doesn't expose them.
If I begin to update I'll let you know, pls keep me informed if you do.
Locally I now used a way simpler approach, not a replacement as it does not support "protected" mode, it replaces the doors:key by a doors:plug_spinner and doors:doorslock. Plug spinner puts a needs a doorslock to switch owner, and gets back one when doors get back to no owner (if it was locked by plug spinner). You can grab artwork or anything else from my version if interested, ask access because gitlab repository is not public as not really .
When I switched back from doors_redo to doors I also noticed that the skeleton_key were different (stack does not want to merge)
P.S.: I also noticed there are two png with wrong sRGB profile
mogrify textures/doors_door_glass.png
mogrify textures/doors_door_obsidian_glass.png
should suppress those warning
I like this mod as much as its predecessor.
I comment here as it seems I can't create issues on github for this mod
If I give a positive feedback it's really because I like it. It seems bug free now (c.f.: log out/log in old mod)
I commented mostly on point I do not like just because I initially wanted to create issues on github.
As already mentioned this mod, is forced to be packed in modpack for cdb now. As a consequence it was over one year that all my updates were fud only, I updated the main repo. but forgot to update submodule on the proxy modpack.
You can take a look at my comment I already know my uv projections are really bad, and invite people to fix this.
About the 2D/3D for flames, I chose 3D because it is backward compatible with old minetest version.
Seems like mineclone2 team does not really care wether it is 2D or 3D. Also discussed in previously linked thread.
feel free to submit better graphics, models or whatever you like
This commit, should fix famage problems in creative.
If you prefer to see it land in CDB, just ask. You may also just update from git.
Thanks for testing and appreciating this mod.
I quite never play in creative mode, so the first review I made on this mod was about an inconsistency between creative and survival mode. I fixed the wrong behavior in survival without seeing it reintroduced bad behavior in creative mode. I will have a look at the bug you pointed in creative mode.
About the guards, this is in my plans but not at the top of my to do list. Got to think about group behavior first to limit time consuming path finding bomb aborted by collisions. I also got to get more familiar with damage management before, I'm a noob modder, I just feel bit more confortable in areas of the API I already explored, damage system is not one of them.
Planned things to do before this one are:
More things I eventually do before guards core. So it may take time. This suggestion was already done on the original maidroid's bugtracker.
From what I see in the readme.md:
Some dependencies are still mandatory:
The link to pdisc is also available in the readme and pdisc appears as optional depend in mod.conf. The main problem remain that pdisc is not available in CDB.
I will maybe try to ask lwscratch dev if it would be possible to expose his forms as a an API, so maidroids could have new language.
Features I would like to add to this mod:
Those are all only thoughts, no work done yet. I also find that the original maidroid github repository exposes a lot of ideas, like fighters and so. Currrently I'm mostly losing all my free time playing CTF, so don't hope to see any progress soon, any bugs will be treated faster.
1/ Ah yes, I noticed it in creative mode, but didn't think about the behavior when dropping items in world. Nice to have many eyes on things.
I will have a look on it next week, the week end is dedicated to my kid. But I guess this part will be alledgely skipped
2/ The tool would also to copy "secrets" from any node with key callbacks.
Also from entities, as I plan to make maidroids shareable via keys too, with support for both modes I exposed in doors redo. I want to switch from old helicopter mod, to APercy version but none his vehicle are shareable, I will need some keys for those vehicles too. For entity keys, I plan to make a very small API only mod.
I will keep in touch so we can check if it's better located in doors_redo or in a standalone mod.
Ice and phi doors: I read the readme and code but didn't notice.
All what I see is their textures do not have licence. I will rather make new textures.
The other variable: could be skipped, it could use "protected", "protected1", "protected2".
I guess the stack issue is in creative ? The infinite duplication of the secret leaded me to the tool I spoke about in last comment.
For now I will just disable secret cloning in creative.
Saw that the protected_modes and transportable locked doors I worked on was closed on your bt.
Does it mind if I open a package approval request here ?
I added a flavor = "mazes_80" line to the mod to allow to differentiate it from your version if required at some point.
I like so much the idea of 'transporting secret' that I may make a tool to copy secrets from any type of locked things (chest, door, ...). The idea slowly maturates.
I don't use discord, but may make some feedbacks on github because the fork of maidroid I maintain is compatible with animalia.
These droid can milk cows and feed them, shear sheeps, and kill overnumerous poultries.
breeding planned: I guess for animalia breeding should be only: feed animals
Would be nice too keep me in touch if you change those parts:
There was some breaking changes in your mod when you dropped mobkit.
I'm waiting for the breed system to work again.
Cpu usage were done mostly to improve maidroid, as it supports animalia, mobs redo and petz, they were also running meanwhile. Also I wanted to change petz on my server by more lightweight mod.
Test done in september, values may be slightly wrong as I didn't save results, this is just what I remember.
Group behavior
Awesome birds synchronized flights last time I checked.
Cpu usage
Damage
when taking damage they way mobs escape is quite weird.
A link to the branch I worked on update
I tested new features about keys with: * default mtg keys * keyring mod
All seems ok about keys
I didn't test anything else but it didn't change much, just was actualized to match current mtg doors mod.
Besides all this update got rid of most luacheck complains, except unused args (they are only for prototyped funcs so not a big deal) There was only one annoying thing with a function declared as global.
Writing this message encouraged me to update things, I'm quite finished yet. I need to test things after, then I'll open a temporary repository on github or gitlab
I used this mod but dropped it now as it doesn't support keys: I think the doors mod from minetest_game has been updated since a while. Now it register a on_skeleton_key_use for any of the registered doors/trapdoors This redo doesn't expose them. If I begin to update I'll let you know, pls keep me informed if you do.
Locally I now used a way simpler approach, not a replacement as it does not support "protected" mode, it replaces the doors:key by a doors:plug_spinner and doors:doorslock. Plug spinner puts a needs a doorslock to switch owner, and gets back one when doors get back to no owner (if it was locked by plug spinner). You can grab artwork or anything else from my version if interested, ask access because gitlab repository is not public as not really .
When I switched back from doors_redo to doors I also noticed that the skeleton_key were different (stack does not want to merge)
P.S.: I also noticed there are two png with wrong sRGB profile mogrify textures/doors_door_glass.png mogrify textures/doors_door_obsidian_glass.png should suppress those warning
I tried suggested method number 1 with submodule.
That's not an issue but I still need to configure git submodule.
It works as a charm, but if someone can provide number 2 answer it would be appreciated.
It quite bizarre to be forced to create new dummy repository to be able to update this mod
Bit problematic as during the migration mod.conf went in the root and technical name now mismatches
How to pass through this problem:
1/ create new repository with this mod included as submodule to follow modpack format ? (will skip the problem once again)
2/ cdb staff propose another long term way to skip this failure (other than changing mod name, as it will not be backward compatible anymore)
3/ hard way: suppress the other fork from cdb: unmaintained, not even the original, and with really few lines added.
Bit weird though as I can have the mod with the current name if in modpack ...
P.S.: Noticed that the import failed but mod still appears as recently updated