Thanks for implementing the action menu thing! I was looking at expanding it, but before I invest much time in it, I want to ask you this: did you try to add items that use the weird json transform stuff? For example, the flashlight. I have a feeling it will be hard to do; maybe a new json line will need to be added so the action menu can read it properly.
The weird json stuff can’t be tested for with itype::can_use.
This is because their use_functions are of type iuse_actor, which doesn’t have an equality operator defined, nor have a map from which they could be acquired by some string name.
To handle those json functions, the menu would have to look for specific items, not just actions, because json actions can’t be… “looked for”.
The item action type would have to be expanded to cover both named actions (which it does now) and named items.
This probably wouldn’t be hard - the class would need a new field describing if it’s an item or action. This field would be loaded from json and then checked just before the regular itype::can_use (and would simply check for item id rather than can_use if it’s looking for an item).
Most json actions are of transform type. It would be nice (though not necessary) to have “item action groups”, from which only the first would be picked. That way you wouldn’t have both “turn on a flashlight” and “turn off a flashlight” if you’ve got two flashlights, one of which is on. This one would be harder to implement than the one above, but still nothing requiring expert skills.
You know i’m waiting particulary your manual aiming for turret, but i’m a stranger with github and i haven’t found a way to DL these files.
Did i have missed the magic button to DL or is it only a preview of content?
Nope, those are source code repositories. If you wanted to run it, you’d have to compile them yourself. A description on how to do that is on the wiki, but it’s not all that easy.
Also, not all of them are compatible (particularly manual turrets and AI upgrade). I will fix the incompatibility when manual aiming gets in.
If I manage to clean up all the bugs, it may get into the game soon. KA101 keeps finding bugs in my manual turret aiming, but I fixed a ton already, so it should be somewhere near done because I’m running out of possible bugs. “Somewhere near done” means “2 days, I think”.
Manual turret aiming went in and AI rework (= tankbots use their big guns on your behalf) is gonna get fast-tracked once I’m through testing the spider rework.
(It’s a screencap of the AI rework in testing.)[/quote]
Actually, hacked tankbots would do this before, they were just really shy and expected the player to stand far from them to use the big guns. Far from them, but still in the field of vision.
Not sure how to handle squirrels getting blasted. Size comparison? Hostility? Meta stuff like difficulty? Function of some of those and of distance?
I think hostility + size sounds good. An angry moose is a good target for a frag, a neutral one should still eat a burst. Angry skitterbot or dog is worth a burst, while neutral one can a zap from tazer at best. Non-hostile NPCs exempt.
Basically, a cap on mode equal to monster’s m_size + 2 if hostile. Zombies would get fragged, anything bigger (including boomers) would get the rocket.
Or maybe the above with some penalty for living stuff and a bonus for metal things and/or military equipment, so that chicken walkers still get the rocket, but boomers don’t. If it can tell apart elf-a or medical from relatively pure human, it should also be able to tell apart a stick from a gun.
Say, size - 1 + 2 if hostile + 2 if metal/military.
1 (tazer) for very angry squirrels and neutral dogs, 2 (flamethrower) for dogs and kids and neutral cows, 3 (rifle) for zeds, 4 (frag) for boomers, brutes, turrets and skitterbots, 5+ (rocket) for big bots and hulks.
A simple “don’t overkill” switch wasn’t enough - otherwise a nearby cat would prevent a hacked tank drone from attacking.
I implemented a simple target prioritization function to make it work. Effective distance to stuff is now divided by its “power rating”. Bigger, meaner and more metallic stuff will get targeted before fluffy kittens. Fluffy kittens won’t get targeted by turrets unless they get hostile. Moose will get fragged if they get hostile, but neutral ones will only get burned if they come close.
I didn’t edit the generic creature AI, though. This means hacked tank drones will still chase cats around.
Why am I only seeing these posts now? I wouldn’t have bothered testing the PR if I’d seen the problem here.
(Chasing cats & other such critters around is a dealbreaker IMO. If nothing else, they should use the tazer rather than constantly trying and failing to ram.)
As for the tankbots being shy, yeah, that was an issue that I’d not had the time to really grab and work on. Would’ve been a while at it, unfortunately. I posted the screencap chiefly because I thought folks who complain about both tankbots and moose would get a kick out of the big scary R blasting the big scary M.
I’d fix it sooner, maybe even during today’s testing, but I decided to try and implement proper car picker for remote controller rather than having this ugly look_around one. I thought it would be easy - it wasn’t, because no “get all cars around point” function seems to exist.
Switching between branches that change differ even by a single letter of an important header means I have to spend an hour recompiling, so I can’t really multitask here.
EDIT: “Get all cars around point” function does actually exist and I wasted 2 fucking hours trying to reinvent it. A function that I could find with a simple `grep “get_veh” -r src". Worse - it’s in plain sight, in map.h, not even overmap, overmapbuffer or mapbuffer.
See around your vehicle w/o having to use a mirror. Thus you can have the veh totally sealed, no need for windows; works well on wide vehicles with a blind spot in the back, etc.
I tried cameras in 2569. perhaps i did something wrong but when going faster it does not displace the view forward like usual and it seemed to suck my battery dry really fast.
Cameras should work like this: When you’re sitting at a car tile that has the camera monitor (separate part, kinda rare, can be found in offices or crafted) and the cameras are on, each camera should radiate a field of vision. Relatively small one (24 tiles), but should be enough to drive at low/mid speed through fields.
It shouldn’t affect camera position, nor the car ‘X’ indicator. Should work very similarly to a mirror.
That camera draining looks like a bug, which I didn’t catch because it kinda accumulates over time. I forgot to reset camera_epower variable, meaning that it “snowballs” to some extreme values after a while. Thanks for reporting, I’m off to make a fix.
[quote=“Coolthulhu, post:19, topic:8412”]Cameras should work like this: When you’re sitting at a car tile that has the camera monitor (separate part, kinda rare, can be found in offices or crafted) and the cameras are on, each camera should radiate a field of vision. Relatively small one (24 tiles), but should be enough to drive at low/mid speed through fields.
It shouldn’t affect camera position, nor the car ‘X’ indicator. Should work very similarly to a mirror.[/quote]
Alright. So it cannot be used as a viewport.
Would it be possible to code a camera, presumably with a reduced visible angle, that would basically work like moving the player to where the camera is, except that the body is somewhere else?
.
