Just gonna say this now, but setting up a whole system for programmable AI is a ton of work for (at least as I see it) not too much of a gain. It’s not necessarily something I’m opposed to, but it’s way way over the work/reward threshold I personally use to decide if anything is actually worth working on.
You mean AI as in custom creature behavior, or just small conditional trees that control electronics? I’d definitely agree with the former.
I’m guessing he means anything that constitutes an agent that can take action on its own. it doesn’t matter if you’re programming a ‘monster’ or your car, it’s just as complicated either way.
Apparently i wasn’t the only one with this idea…
[
{
“id”: “smartphone_main”,
“type”: “TOOL”,
“symbol”: “,”,
“color”: “blue”,
“name”: “Smartphone”,
“description”: “An average smartphone, codeveloped by Orange and Cyborg. It has been loaded with a variety of apps, providing all kinds of functionality.”,
“price”: 3500,
“material”: [“plastic”, “aluminum”],
“weight”: 141,
“flags”: [“WATCH”, “ALARMCLOCK”],
“volume”: 1,
“bashing”: 0,
“cutting”: 0,
“to_hit”: 0,
“max_charges”: 500,
“initial_charges”: 500,
“charges_per_use”: 1,
“turns_per_charge”: 0,
“ammo”: “battery”,
“revert_to”: “null”, “//” : "Idea-- MP3 (iuse.cpp), ",
“use_action”: [“CAMERA”, {
“type”: “transform”,
“menu_option_text”: “E-Ink App”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You select the E-Ink app.”,
“target”: “smartphone_EInk”
},
{
“type”: “transform”,
“menu_option_text”: “Game List”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You open the list of games.”,
“target”: “smartphone_Game”
},
{
“type”: “transform”,
“menu_option_text”: “hackPRO”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You select the hackPRO app.”,
“target”: “smartphone_Game”
},
{
“type”: “transform”,
“menu_option_text”: “Flashlight”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You turn on the flashlight.”,
“target”: “smartphone_flashlight”,
“active”: true
}
]
},
{
“id”: “smartphone_EInk”,
“type”: “TOOL”,
“symbol”: “,”,
“color”: “blue”,
“name”: “Smartphone - E-Ink”,
“name_plural”: “Smartphone - E-Ink’s”,
“description”: “An average smartphone, codeveloped by Orange and Cyborg. It has been loaded with a variety of apps, with the E-Ink app currently in use.”,
“price”: 3500,
“material”: [“plastic”, “aluminum”],
“weight”: 141,
“flags”: [“WATCH”, “ALARMCLOCK”],
“volume”: 1,
“bashing”: 0,
“cutting”: 0,
“to_hit”: 0,
“max_charges”: 500,
“initial_charges”: 500,
“charges_per_use”: 1,
“turns_per_charge”: 125,
“ammo”: “battery”,
“revert_to”: “smartphone_main”,
“use_action”: [“EINKTABLETPC”, {
“type”: “auto_transform”,
“msg”: “The smartphone shows the main menu before the screen goes blank.”,
“target”: “smartphone_main”,
“menu_option_text”: “Main Menu”
},
{
“type”: “transform”,
“menu_option_text”: “Game List”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You open the list of games.”,
“target”: “smartphone_Game”
},
{
“type”: “transform”,
“menu_option_text”: “hackPRO”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You switch to the hackPRO app.”,
“target”: “smartphone_Game”
},
{
“type”: “transform”,
“menu_option_text”: “Flashlight”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You turn on the flashlight.”,
“target”: “smartphone_flashlight”,
“active”: true
}
]
},
{
“id”: “smartphone_Game”,
“type”: “TOOL”,
“symbol”: “,”,
“color”: “blue”,
“name”: “Smartphone - Games”,
“name_plural”: “Smartphone - Games”,
“description”: “An average smartphone, codeveloped by Orange and Cyborg. It has been loaded with a variety of apps, with the game list currently open.”,
“price”: 3500,
“material”: [“plastic”, “aluminum”],
“weight”: 141,
“flags”: [“WATCH”, “ALARMCLOCK”],
“volume”: 1,
“bashing”: 0,
“cutting”: 0,
“to_hit”: 0,
“max_charges”: 500,
“initial_charges”: 500,
“charges_per_use”: 1,
“turns_per_charge”: 0,
“ammo”: “battery”,
“revert_to”: “smartphone_main”,
“use_action”: [“PORTABLE_GAME”, {
“type”: “auto_transform”,
“msg”: “The smartphone shows the main menu before the screen goes blank.”,
“target”: “smartphone_main”,
“menu_option_text”: “Main Menu”
},
{
“type”: “transform”,
“menu_option_text”: “E-Ink App”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You select the E-Ink app.”,
“target”: “smartphone_EInk”
},
{
“type”: “transform”,
“menu_option_text”: “hackPRO”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You switch to the hackPRO app.”,
“target”: “smartphone_Game”
},
{
“type”: “transform”,
“menu_option_text”: “Flashlight”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You turn on the flashlight.”,
“target”: “smartphone_flashlight”,
“active”: true
}
]
},
{
“id”: “smartphone_Hack”,
“type”: “TOOL”,
“symbol”: “,”,
“color”: “blue”,
“name”: “Smartphone - hackPRO”,
“name_plural”: “Smartphone - hackPROs”,
“description”: “An average smartphone, codeveloped by Orange and Cyborg. It has been loaded with a variety of apps, with the hackPRO app currently in use.”,
“price”: 3500,
“material”: [“plastic”, “aluminum”],
“weight”: 141,
“flags”: [“WATCH”, “ALARMCLOCK”],
“volume”: 1,
“bashing”: 0,
“cutting”: 0,
“to_hit”: 0,
“max_charges”: 500,
“initial_charges”: 500,
“charges_per_use”: 1,
“turns_per_charge”: 0,
“ammo”: “battery”,
“revert_to”: “smartphone_main”,
“use_action”: [“ROBOTCONTROL”, {
“type”: “auto_transform”,
“msg”: “The smartphone shows the main menu before the screen goes blank.”,
“target”: “smartphone_main”,
“menu_option_text”: “Main Menu”
},
{
“type”: “transform”,
“menu_option_text”: “E-Ink App”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You select the E-Ink app.”,
“target”: “smartphone_EInk”
},
{
“type”: “transform”,
“menu_option_text”: “Game List”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You open the list of games.”,
“target”: “smartphone_Game”
},
{
“type”: “transform”,
“menu_option_text”: “Flashlight”,
“need_charges”: 1,
“need_charges_msg”: “The smartphones’s batteries are dead.”,
“msg”: “You turn on the flashlight.”,
“target”: “smartphone_flashlight”,
“active”: true
}
]
},
{
“id”: “smartphone_flashlight”,
“type”: “TOOL”,
“symbol”: “,”,
“color”: “blue”,
“name”: “Smartphone - Flashlight”,
“name_plural”: “Smartphone - Flashlights”,
“description”: “An average smartphone, codeveloped by Orange and Cyborg. It has been loaded with a variety of apps, providing all kinds of functionality. The flashlight is currently on. Use it to turn it off.”,
“price”: 3500,
“material”: [“plastic”, “aluminum”],
“weight”: 141,
“flags”: [“WATCH”, “ALARMCLOCK”, “LIGHT_10”],
“volume”: 1,
“bashing”: 0,
“cutting”: 0,
“to_hit”: 0,
“max_charges”: 500,
“initial_charges”: 500,
“charges_per_use”: 1,
“turns_per_charge”: 35,
“ammo”: “battery”,
“revert_to”: “smartphone_main”,
“use_action”: {
“type”: “auto_transform”,
“msg”: “The smartphone shows the main menu before the screen goes blank and the light goes out.”,
“target”: “smartphone_main”,
“menu_option_text”: “Turn off”
}
}
]
Idea would be like a real phone, able to switch to different apps easily. Only problem is, no matter what option you choose, it always goes by the first transformation coded.
My problem with the expanded coding thing is that I just can’t see enough cases where automating things would be all that useful. I could write a program in-game that turns on the heater when it gets cold, or I could just… turn on a heater when it gets cold. Same goes with lights, cars, any kind of mechanically-operated gate, etc. It’s a really interesting idea, but it seems like something that needs to have a game built from the ground up with it in mind. As it is, all the possible uses are either things that are simple to do manually or horrendously complicated.
Simple, defined, 1-liners like “turn on the heater when it gets cold” are easy enough. The problem with the idea isn’t necessarily that, but the exponential nature that occurs when you start to want to allow the player to mix and match programmable “chips” among a variety of different “objects”.
Take, for example, an “open” chip. While it might seem like a simple thing to code, in reality it would have to have several different meanings depending on what you put it on. If it was on a gate, then it might open the gates, on a car it might open a door, or maybe the trunk, and on a strongbox it might open a lock, all of which require totally different backend code to work. And what about multiple things? A car might have several doors, and what if I have a built-in strongbox in my vehicle? You’d need to add a modifier to allow it to determine which thing it was supposed to open, or which things. Meaning then you also need to write code that handles the selection of what thing is supposed to open. And then what if whatever it was supposed to open is destroyed? We need code to handle that as well.
And that’s 1 “chip” with 3 different objects. Add a second chip like “close” and you’d need to double the size of most of the code you wrote. Add another object in after that? You’ve now got to add 2 more chunks of code to every single block to handle the “close” and “open” chips for that object. While it’s limited by the fact that you can “catch-all” a significant portion of things with a “this chip doesn’t work in this object”, it’s still essentially an exponentially expanding tree.
Don’t get me wrong, it’s still totally a possible (even easy) idea to do if you’ve got your programming structure set up right (a duck typing setup is great for this kind of thing), and you’re working in the right language to allow you to do that (Python and Ruby use duck typing almost all the time, and Common Lisp uses it sometimes. The C++ that we use is a great example of a bad language choice, which doesn’t mean it’s impossible, just a lot more work.) But it’s definitely the type of idea that you want to take into account at the start of development and essentially build around as you go (like Carnage Heart did), than a feature that you easily add to a game in progress (at least not without potentially having to throw away and rewrite possibly huge chunks of code from the ground up).
On the other hand doing an “app-based” transformation style thing is totally possible to do, since each app can be coded individually in a single location, works nicely as a static definition that doesn’t change on the fly, and doesn’t have the exponential problem (though it doesn’t allow anywhere near to the same level of freedom either). Here’s the basic outline of what we would need to do to do that:
- Code a new method that lets an item switch between multiple defined IUSEs through a swap menu. This gets you out of the transform method and removes the exponential problem that that currently would have (where every single app would need its own item definition, and would have to link to every single other app definition).
- Create any app iuses in the iuse.cpp file.
- Optionally, allow for further modification of an already existing device, this could be as simple as having an optional “app uses” area in the item definition (which would normally just be left blank, with “doesn’t exist” = “no app uses” to save memory space), that would get loaded out/in on saves/loads to ensure that it doesn’t get lost. You could also have another item (such as an sd card), with an iuse that lets it transfer its listed “app uses” to another matching device, thus letting you start with some basic apps on every device, then be able to add more to it as you go.
I think the item transformation route is a really ugly way to go about it. In my mind, you would have a device with an iuse that brings up a menu that you can select things from, and it will perform the action associated, rather than transforming into a device that does whatever. The problem with supporting either of these is how you add and remove items from the menu.
One idea is to have USB drives contain software, and when you activate your laptop, it searches for USB drives in your inventory with software and adds a menu item for each, and then you can do whatever based on whatever software you have. This is pretty silly because it’s like your laptop has no internal storage, which we all know is not the case. Although, it does allow for some interchangeability if we wanted to have the computer terrain feature use this same software somehow, and it would be relatively easy to do.
Another idea building off of the above is instead of having to keep a set of USB drives on you at all times, there would be some mechanism for transferring the contents of USB drives onto a laptop or other device. I believe USB drives right now are implemented as “containers” for software, and we could implement something similar for laptops, with the exception that laptops are able to contain multiple other items, and then just having the laptop go through its contents when you activate it. Laptops could have a few basic functions that every laptop has, like copy to/from USB drive, delete from USB drive, etc.
As far as in-game scripting goes, it probably has to be super limited to avoid exploding in scope. Things like creating a series of wirelessly triggered floodlights and having them trigger on channel 1, and then rigging up a motion sensor to emit a signal to channel 1, or having a home security app that sends a signal to channel 1 might be fairly reasonable, but expanding it much more beyond that and it can get really complicated really fast.
Thanks for all the feedback all.
So in all its not impossible as such just 's hit ton of work…when really there is other things in need of more attention first?
Pretty much, and when the amount of time needed to implement all the desired features >> number of hours available developers have, then more low lying features tend to get hit up first. That said there is always the chance that someone would go do them despite them being difficult (such as how Coolthulhu has accomplished some huge steps towards Z-levels), and it’s something that the current bounty system helps to encourage farther by letting people put money up for whoever completes their desired features (though we usually want to at least take a look and see if it’s something we want in the game first :P).
So yeah, a fully programable computer would be awesome, and I know I’ve certainly added it to my to-do list of things, but given the amount of work that it would take ATM and the ever growing supply of “cool ideas to implement” it’s a bit too far down for me to have much hope of reaching it any time soon. 
Though of course every single developer has their own criteria so one of them might think differently, and hey, in a worse case you can always take a year or two and pick up some basic programming (I have a few neat links and pieces of advice that can help if you decide to go that route, and seriously, it’s nowhere near as hard as it looks) and then take some steps to implement it yourself, which is the best part about open source projects like this. 
Thanks for the reply
I wish I could programme I have tried for a very long time to learn it won’t happen I’m more 3d artist so stick to that tbh.
Yeah coolthulhu is doing awesome work and can’t wait to have full z level stuff in cdda 
It’s cool that u have added it to your list of possible implementations it would be neat to see computers like this in cdda.
Any way thanks
I’m in favor of GPS, but not so much the tracking animals. I just don’t see the point. It’s neat, and I like the idea of having this kind of flexibility, but if the features get in the way of the users that might not use them(me), then I’m not a fan.
That being said, programmable vehicles, hell yeah. That means that if my PR with farming equipment lands, then I can have an automated farm.
Finally after a hard day (months) scavenging my survivor can return to his home and find his fields plowed, planted, and eventually harvested.
Also flowchart based programming isn’t worth it imho because it takes away so much power from the programmer, and makes a lot of things very inconvenient and inefficient. Especially variables. Variables are very annoying in any flowchart language that I’ve seen.
We could also build mobile turrets.
We kind of can now I think place a turret on casters and have remote controls and camera on it but its not automates.
My thinking is we could programmes it to just move x squares then turn then move x squares to patrol a certian area etc.
We could also you this to make sure all out little robot manhack buddies don’t go sacrificing themselves because they saw a bear miles away in the other direction and decide it’s a threat to your safety…
RIP Adren…
The only thing about my code that doesn’t currently work is the fact that the game doesn’t allow multiple “transformation” type use actions in the items .json coding. If it did, then this would totally work (i tested it with fewer transforms)
You actually have to have separate items for each action, otherwise any item set as “active” constantly goes through every coded action every turn.
[quote=“Kevin Granade, post:4, topic:10431”]I’m in favor of expanded functionality for this kind of thing, but let’s be realistic.
You’re not going to be doing any hacking from a phone, controlling things once you’ve done hacking elsewhere sure, but phones just aren’t set up for breaking in to systems. (you basically touched on this, just being clear)[/quote]
You say that, but a man once used his phone to hack traffic lights. And if you’re thinking Watch_Dogs, you’ed be partially right, but actually that traffic light hacking in Watch_Dogs was inspired by a real event, done by a man who did it to prove he could. And you may be thinking, their just lights, but those lights are controlled by software, like all electronics, and with good enough software loaded on the phone, and proper skill, it can be done. I recommend watching Game Theorists more often, and if you don’t know what that is, they do a kind of reality check on video games, along with all the other things, backed up to the arse with facts and examples.
[quote=“SioxGWolf, post:35, topic:10431”][quote=“Kevin Granade, post:4, topic:10431”]I’m in favor of expanded functionality for this kind of thing, but let’s be realistic.
You’re not going to be doing any hacking from a phone, controlling things once you’ve done hacking elsewhere sure, but phones just aren’t set up for breaking in to systems. (you basically touched on this, just being clear)[/quote]
You say that, but a man once used his phone to hack traffic lights.[/quote]
“Someone did this once” does not equate to “this is a reasonable thing to do”. Also I’m deeply skeptical that said hacker did the whole thing from their phone. Most likely they researched and developed an exploit using normal tools, then just deployed it using a phone, which is a fairly reasonable thing to do, see
controlling things once you’ve done hacking elsewhere sure
Sounds interesting, but I’ll pass, I probably don’t play enough games to have a good hit rate on the ones I do play, and as far as programming and security, I do that for a living, so I’m fairly up to date on it.
ok I like where this is going. Definitely in favor of features such as:
1: craft-able (but otherwise rare?) tracker ammo that can be fired from various weapons, especially for grenade launcher and tranquilizer capable weapons. Can be located on map & tags hoards. Small chance of falling out (unfortunate brushed against something RNG claims) advanced version that notifies you it has fallen out and stops tracking? (untill you want to find that tracker you spent ALL DAY working on!!!) 
knowing where tracker is (embedded in zombie or on ground) on map screen requires having phone or tablet with “app?” or something.
2: nameable short-ranged tracker capable of giving EXACT location of target via Bluetooth etc to phone (doesn’t reveal tile but shows location? (when out of vis, square is yellow instead of black or shows wifi blip in same fashion as sound but constantly) or maybe just reveals tile at all times. I say nameable because it would be nice if you go in shooting a bunch of them to know which is which when you (
look at them.
-
[hack capable] tag for phones and tablets that shows they have app for operating hostile systems when within small distance of and/or manually plugged into with phone and tablets.
-
some/modded phones capable of short distance nv/infrared imaging (styled like nighttime car vis?)[prob not] can be attached to weapons??? with various results, including cornershot™ knockoff (so you can finally shoot while peeking) and even solo can give increase nv range while equipped to hand
-
ability to operate per-setup systems such as turrets and cameras from limited distance
-
motion trackers/cameras that when within range of phone can trigger alarm and (glance at phone to see what it is)and show noise/area within camera vis for appropriate triggered device.
-
craft-able Bluetooth planes/cars with optional camera(s) explosives, gas canisters/remotely triggered grenades mines & other explosives etc… (also alarm capable?)
7. craft-able Bluetooth planes/cars with optional camera(s) explosives, gas canisters/remotely triggered grenades mines & other explosives etc.. (also alarm capable?)Bluetooth would actually be pretty aweful for it, given its range limitations.
Bluetooth is short ranged, but its not like there are functioning cell towers anymore. So RC would be best but if you want to make cellphones more versatile that would be a good way to do it. True if its simulated “Bluetooth” the range would be a lot shorter, especially in a mobile form like with a RC car, but walls would not be much of a hindrance. Without some sort of self-built tower relay system or something like you might do at your base, Bluetooth would probably be the best option for making use of equipment your phone might have.
No, bluetooth would still suck compared to commercial RC cars you can buy in stores.
Afaik, most bluetooth appliances you’d put your hands on would likely have a maximum range of only 10m or so.
Given that it uses the same wavelength as IEEE 802.11 stuff, you’d likely go for regular WiFi instead due to better range and data transfer capacity. Which also means that walls will produce similar attenuation, although less of an issue with 802.11 appliances due to higher signal strengths.