Author Topic: Command Shortcutting  (Read 13139 times)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: Command Shortcutting
« Reply #15 on: April 04, 2015, 02:47:54 PM »
You see, Im a person who solidly hates Lua. Its just not really very simple or understandable to me

Wow, you're so wrong haha :P  Lua is one of the most elegant languages I've ever come across, because it's managed to create a very expressive language from a very simple set of rules, and it embeds very cleanly in other code.  I was thinking as a long finger project there could be a version of Lua for the DNA language (over, say, Python) because it maps pretty well to things like codules.

What don't you like about Lua?  Just syntax around how you define tables and metatables?  Or something more foundational?

...

For DRY, it's about repetition (or rather, the lack of it), not simplicity or primitiveness or whatever else.  The choice of language is completely orthogonal to not repeating yourself, so I'm not sure what you're getting at around binary.  (Also, no one programs binary, that's so 1952.  You'd program in Hex.  Way more compact :P)

Quote
Finally to my statement that not all of the organisation things can/are implemented in DB2/DB3 is quite clear because we can't make an external file which is referenced to store X part of data, a bit like how you have a seperate CSS in HTML.

You mean like #include or Import or etc. that other languages have?  Sure, we could add that.  I'll think through what makes the most sense and set up a todo item on it.

Offline spike43884

  • Bot Overlord
  • ****
  • Posts: 656
    • View Profile
Re: Command Shortcutting
« Reply #16 on: April 05, 2015, 08:06:25 AM »
You see, Im a person who solidly hates Lua. Its just not really very simple or understandable to me

Wow, you're so wrong haha :P  Lua is one of the most elegant languages I've ever come across, because it's managed to create a very expressive language from a very simple set of rules, and it embeds very cleanly in other code.  I was thinking as a long finger project there could be a version of Lua for the DNA language (over, say, Python) because it maps pretty well to things like codules.

What don't you like about Lua?  Just syntax around how you define tables and metatables?  Or something more foundational?

...

For DRY, it's about repetition (or rather, the lack of it), not simplicity or primitiveness or whatever else.  The choice of language is completely orthogonal to not repeating yourself, so I'm not sure what you're getting at around binary.  (Also, no one programs binary, that's so 1952.  You'd program in Hex.  Way more compact :P)

Quote
Finally to my statement that not all of the organisation things can/are implemented in DB2/DB3 is quite clear because we can't make an external file which is referenced to store X part of data, a bit like how you have a seperate CSS in HTML.

You mean like #include or Import or etc. that other languages have?  Sure, we could add that.  I'll think through what makes the most sense and set up a todo item on it.

See you see Lua as nice to program in, for me its overcomplicated. >PROOF< of my point. And im talking about binary because if were going to take DRY really seriously, lets start programming in binary again, nothings wrong with it. Its fast and efficient. I mean DRY wants you to only have one way to do something, so in binary you could make a big 'A' but instead you choose to use a second system by using C# to make a big 'A' appear on the screen, or maybe you'll use Lua to make a big 'A' on the screen...But thats using a 2nd, or 3rd method and not the original. Thus, you are violating the principles of DRY.

DRY is just a mere little idealism which only works if all humans were completely, to a genetic level identical and experienced exactly identical experiences. Currently cloning technology for humans is unavailable, so DRY isn't going to be at all successful yet. Theres over 2000 different programming languages (ONLY INCLUDING HIGH LEVEL ONES). Its complete proof of my point, stop being like a politician and throwing silly little puns and jokes to skirt around that you are merely, and completely wrong. DRY, does not work - at least in the present day. Now we wouldn't need many alternatives, maybe one full set of alternatives.

Heres some even more major proof of how majorly wrong DRY is, now don't get me wrong im not the biggest fan apple macs but this is just proof that DRY is wrong. Apple has become one of the biggest computer manufacturers, and apple macs sell incredibly fast...Yet they don't use your standard shortcuts that are tried and tested, for example on an apple mac i've used theres a ctrl key, but for shortcuts you need to use the cmd key instead.

How many more hundred examples do I have to give you before you give up.
Autism can allow so much joy, and at the same time sadness to be seen. Our world is weird, and full of contradiction everywhere, yet somehow at moments seems to come together, and make near perfect sense.

Offline Shadowgod2

  • Bot Destroyer
  • ***
  • Posts: 387
    • View Profile
Re: Command Shortcutting
« Reply #17 on: April 05, 2015, 07:55:56 PM »
ok so i've read the DRY link just enough to understand what's going on with it. now i'm going to ask, what in your own mind does DRY mean?

can you both do this without using any links nor in any way target one another in your descriptions please.

i only ask this because there is a misconception or miscommunication somewhere and often times there needs a 3rd neutral party to help solve the issue.
« Last Edit: April 06, 2015, 12:01:54 AM by Shadowgod2 »

Offline spike43884

  • Bot Overlord
  • ****
  • Posts: 656
    • View Profile
Re: Command Shortcutting
« Reply #18 on: April 06, 2015, 06:43:16 AM »
ok so i've read the DRY link just enough to understand what's going on with it. now i'm going to ask, what in your own mind does DRY mean?

can you both do this without using any links nor in any way target one another in your descriptions please.

i only ask this because there is a misconception or miscommunication somewhere and often times there needs a 3rd neutral party to help solve the issue.

DRY, to me from the link and from numsigl's description is pretty much, there should only be one way to do something.

Im just arguing with many examples showing that virtually nobody in the world actually uses DRY properly. Because to the very core level, then we should always be doing every bit of programming in binary, because using various programming languages is secondary, and tertiary methods of doing these things, especially high level languages. And thus my point that multiple methods is better, even if it be a few methods its much better. And with my point of command shortcutting, alternative commands aren't a different system, just a different...domain? Whereas the current alternative which DB2 uses which is inline conditioning is an alternative, certainly harder to read and write, yet its still used. Plus, he's pointing out that it'll be harder to read, but im not suggesting completely ridiculous alternatives which you really need lots of technical knowledge to understand like those in inline conditioning, you'd just have to quickly check which name its partnered with in the wiki. Reading thus stays the same difficulty as without alternative commands, and writing becomes easier...and quicker.

Heres another example, im a keen player of "minecraft" which you may have heard of, its got many plugins to add commands...and one of these plugins lets you use colours in chat and signs and names, but the standard command to access the infomation on the colours is /info colors which is the american way of spelling it, but when im typing I generally use my native language, which is UK english...so I kept typing /info colours by accident, and so did some other people on the server...Now this was only a few people making the mistake, in a over 200 player network, but the owner still introduced the shortcut /info colours...both are understandable when you read it, whatever version of english you use, but yet the /info colours is much easier for us british people and the /info colors was much easier for the americans...Its a simple example, which is very relevant and proves my point.
Autism can allow so much joy, and at the same time sadness to be seen. Our world is weird, and full of contradiction everywhere, yet somehow at moments seems to come together, and make near perfect sense.

Offline Panda

  • Global Moderator
  • Bot Destroyer
  • *****
  • Posts: 476
  • Computer Science Undergraduate (nerd)
    • View Profile
Re: Command Shortcutting
« Reply #19 on: April 06, 2015, 08:07:54 AM »
And im talking about binary because if were going to take DRY really seriously, lets start programming in binary again, nothings wrong with it. Its fast and efficient.
It can be fast and efficient (but not always) to run the code but not to write it. This is one of reasons you have different languages.

whatever version of english you use, but yet the /info colours is much easier for us british people and the /info colors was much easier for the americans...Its a simple example, which is very relevant and proves my point.
This argument is relying on the new commands making sense. I would argue that this is something that with the command "colour", it is something which is a lot more instinctive for users and is "built in" for them (and would probably just give a piece of mind to the server admin because people would have been complaining about it). However, once you learnt that "color" is correct, you can just learn to use it.

In the case of DarwinBots3, having multiple commands for the same thing would create a lot of extra work for the developers, us. It may be easier for you but it requires extra documentation and code. This increases the cost of development and maintenance and gives a higher probability for mistakes (e.g. dx representing 31 and aimdx representing 32, accidentally), as two examples of problems with doing this. If there's fewer commands, there's fewer things to look up for people who understand the original system, making it difficult for them to learn the code. If the documentation is good (which it hopefully will be) then you can just read the documentation.

Developers have to weigh up the usability for different users; what you're suggesting decreases usability for most other users, especially newer ones, and would likely only improve your experience.
« Last Edit: April 06, 2015, 08:34:27 AM by Panda »

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
Re: Command Shortcutting
« Reply #20 on: April 06, 2015, 04:16:58 PM »
In machine language you would repeat yourself quite often, often more efficient to duplicate a method than referencing it with a pointer. It's all about not having to do those steps yourself. Read the link about DRY again.
Oh my god, who the hell cares.

Offline Panda

  • Global Moderator
  • Bot Destroyer
  • *****
  • Posts: 476
  • Computer Science Undergraduate (nerd)
    • View Profile
Re: Command Shortcutting
« Reply #21 on: April 07, 2015, 01:56:23 PM »
In machine language you would repeat yourself quite often, often more efficient to duplicate a method than referencing it with a pointer. It's all about not having to do those steps yourself. Read the link about DRY again.
Who is this aimed towards?

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
Re: Command Shortcutting
« Reply #22 on: April 07, 2015, 04:06:33 PM »
Sorry, aimed at spike.
Oh my god, who the hell cares.

Offline spike43884

  • Bot Overlord
  • ****
  • Posts: 656
    • View Profile
Re: Command Shortcutting
« Reply #23 on: April 08, 2015, 05:34:27 AM »
I know it takes extra typing, but only one set of alternatives won't be that hard. Anyway, im not sure how your currently linking commands to memory address's but in a .txt file you could fit in alternatives dead easy, along with standard commands then just reference a line on the txt file.

Command,Alternative Command
Command,Alternative Command


each line just responding to the memory address of the same number...you could even do
Address,Command,Alternative Command
Address,Command,Alternative Command

to make it easier to remember. So writing the actual code shouldn't  be much harder, especially with only 1 set of alternatives.
My point about color and colour is very relevant actually, its naturally built in. To people who have mastered DB as a language, then things like .dx and .aimdx and .sx and .aimsx are built in, you could recall it off the top. But for example, I haven't a clue which way .dx turns and which way .sx turns, Im just able to comprehend that they turn. sx and dx make no relevance to what I already know, or what most people already know. But lets give an example, in the format of that .txt list of commands I was talking about, (without using address in the actual file yet):

.dx,.left
.sx,.right


Now if your still really concerned about it taking longer to write, just send me a link to the current DB3 commands and just a quick link to the definitions of them and I'd personally write it.
Before you start moaning over its harder to read, it can be harder to read if we chose ridiculous ones, yes...But it can also be much easier to read, and lets use the .dx .left example here, Now normally you'd have a paragraph blabbering on about the function of .dx and you could keep that in for further referencing, but you could also have at the top of the page ".dx does the same as .left" which I'd more likely remember than a whole paragraph.
Then I'll give a quick simple example with animal_minimalis using current code, and just some off the top of my head alternatives:

Standard Commands:
Code: [Select]
'Animal_Minimalis
'By Nums
'Good For newbies to base bots off or learn DNA from


'Gene 1 Find Food
cond
 *.eye5 0 >
 *.refeye *.myeye !=
 start
 *.refveldx .dx store
 *.refvelup 30 add .up store
 stop


'Gene 2 Eat Food
 cond
 *.eye5 50 >
 *.refeye *.myeye !=
 start
 -1 .shoot store
 *.refvelup .up store
 stop


'Gene 3 Avoid Family
cond
*.eye5 0 =
*.refeye *.myeye = or
start
314 rnd .aimdx store
stop


'Gene 4 Reproduce
cond
*.nrg 20000 >
start
10 .repro store
stop

end

Alternative Commands:
Code: [Select]
'Animal_Minimalis
'By Nums
'Good For newbies to base bots off or learn DNA from


'Gene 1 Find Food
condition
 *.eyemiddle 0 >
 *.enemyeye *.myeye !=
 startcode
 *.enemyvelocityleft .left store
 *.enemyvelocityforward 30 sum .forward store
 stopcode


'Gene 2 Eat Food
 condition
 *.eyemiddle 50 >
 *.enemyeye *.myeye !=
 startcode
 -1 .attack store
 *.enemyvelocityforward .forward store
 stopcode


'Gene 3 Avoid Family
condition
*.eyemiddle 0 =
*.enemyeye *.myeye = either
startcode
314 random .left store
stopcode


'Gene 4 Reproduce
condition
*.energy 20000 >
startcode
10 .reproduce store
stopcode

enddna

Most of those alternatives are longer, but reading it...Most of them make quite a bit of sense don't they. The commands are much closer to english... Yet someone new to DB wouldn't have a clue what "NRG" was, is it some sort of sound the bots make?? But oh yeah, "energy" that stuff, I know that! and when they see that "NRG" is the same as "ENERGY" they don't need to read an entire paragraph do they? Now I might not use all of these personally, but .left i'd certainly use, expanding rnd to random I'd use...ABS you could call REDUCE because it reduces it to one of 3 values. Try to put yourself in the shoes of 'imbecile' thats never touched DB before. I know for certain when I started, the first 4 weeks or so that when I first glanced at the language it was so weirdly done, with weird names for simple things that I just stuck to putting random bots in evolution sims (Sidenote: can you bring back ebola to DB2 please, its amazing for evolution sims)
Autism can allow so much joy, and at the same time sadness to be seen. Our world is weird, and full of contradiction everywhere, yet somehow at moments seems to come together, and make near perfect sense.

Offline Panda

  • Global Moderator
  • Bot Destroyer
  • *****
  • Posts: 476
  • Computer Science Undergraduate (nerd)
    • View Profile
Re: Command Shortcutting
« Reply #24 on: April 08, 2015, 06:44:35 AM »
Quote
I know it takes extra typing, but only one set of alternatives won't be that hard.
Quote
Now if your still really concerned about it taking longer to write, just send me a link to the current DB3 commands and just a quick link to the definitions of them and I'd personally write it.
These both require future maintenance and can increase the number of locations in the code that errors can appear. If you decide that once you've put them in that you're no longer going to maintain them, it's up to somebody else to do it. What difference is there for you by doing this compared to

Quote
I know it takes extra typing, but only one set of alternatives won't be that hard.
Quote
.attack
Well, rather than the original shoot, I want shot instead but Numsgil wants strike. Which ones do we include?

Quote
Try to put yourself in the shoes of 'imbecile' thats never touched DB before. I know for certain when I started, the first 4 weeks or so that when I first glanced at the language it was so weirdly done, with weird names for simple things that I just stuck to putting random bots in evolution sims
By adding more variable names, new DBers are going to be further confused. There can be two bots written in 2 different ways that does the exactly same thing (especially in terms of stack manipulation, etc.), it doesn't make it easier for them at all.

Your concerns are not irrelevant or invalid; the variable names can be very obscure at times and I guess this will be something considered in DB3. Since it's completely separate to DB2, no variable names are required to be carried over from DB2. In the end, the

Despite this, a design decision has been made and it's not going to change. One of the biggest problems with DB2, in my opinion, was the amalgamation of different design decisions without communication between the start and the end. The concepts of DRY are being used despite your disagreements and it's clear that a large proportion of this community (currently 3 against 1 in this thread) agrees with this decision.

I'm going to put two points that will hopefully end this argument: it really is Numsgil's decision and we can only offer our opinions and discussions towards features (since he has been the developer for how many years); the feature you have requested is within DB3 (somewhat) and you have to compromise somewhere.
« Last Edit: April 08, 2015, 01:08:56 PM by Numsgil »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: Command Shortcutting
« Reply #25 on: April 08, 2015, 01:45:41 PM »
You can see all the current Sunweaver commands here: commands.  Note that's a pretty short list.  I'll probably add cos to it, but otherwise it's pretty close to a final draft.

For .sx and .dx, they're abbreviations from Italian (sinastra is left, destra is right).  Because the original author of Darwinbots is from Italy.  If you don't speak Italian that's pretty confusing.  But if you speak Italian it makes sense (presumably :P).  Ah you say, that's your point.  But we can't make it not confusing to everyone.  If everything was in plain English that isn't going to help the guy that speaks Japanese.  They might know English well enough for most things but I'm sure they don't know the word for venom or reproduction off the top of their head.  Ah, but what if we just add all the japenese words/characteres for things in there too?  We could do something like:

Code: [Select]
5 .毒を作る

But now if you come across a bot that looks like that as an English speaker you're going to have to go look stuff up.  I certainly don't speak Japanese.  So it doesn't help reading other people's bots.

Ah you say, but it's the bot writing that I want to make easier.  But trying to make the language suit itself to everyone is an impossible challenge.  Ask 10 different people what their ideal language would look like and you'll get back 12 different answers.  By accepting that some things are going to be a little shitty for everyone we can at least work towards making the single way of doing things less shitty.

Is there an American bias going on here?  Yes, absolutely.  I happen to be American.  But most programming languages have an American bias.  Not even just an English one, but an American one.  That's why it's "color" and not "colour" in HTML.  Would HTML be better if it supported "colour" too?  But then why stop there?  Why not support all languages.  Why not 色 and রঙ?

I don't mean that as a rhetorical straw man argument, either.  The current computing landscape is so dominated by an American way of thinking (and not just American, but a West Coast way of thinking) that it's entirely possible that there's a thought monoculture going on and all sorts of interesting solutions to problems are simply never created because we're so locked in to thinking of problems in one specific way.  Sapir-Whorf hypothesis and all that.

But I'm not going to solve the problem of cultural American imperialism.  I just don't have the time or nrg (;)).  So I'm going to apologize upfront for any cultural imperialism I bring with me to the table, and defend myself by simply saying that it's the way things are (in the world at large).  Things could be in Japanese.  Or British English.  Or Swahili.  But trying to do all at once is too much.  An arbitrary choice has to be made, so I made it.  And it's a pretty defensible choice because I can point to all the other American English dominated computer languages out there.  Which is itself indefensible cultural imperialism.  But there you go.

...

Now rant aside, you can make your own sysvars aliases in DB2 already, and if you haven't you should look in to it.  See def.  You can't make your own commands in DB2, but try playing with it and see if you can articulate what you don't like about it.  If it's that you have to copy+paste it in to every new bot, we can look at #include/Import for Sunweaver.  If it's that you don't want to have to write it the first time, I'll write you one to get started.  But I'm not you and I don't know how you think, so the probability that it's going to be something you like is vanishingly small.  If it's something else, let me know.

You should also try playing around with the new language, because while it's superficially similar there's enough differences to make things... different :).  There's the (old) command line interpreter stickied which you've already posted in so I'm sure you've found it.  I can also try and get Panda's IDE as a distributable and you can try writing DNA in that (no way to "execute" it at present, but it'll tell you about syntax errors).  If there's specific usability problems you have in Sunweaver I'll try to think them over and fix them.  I'm assuming at the least you're comfortable with the bool and int stack concepts from DB2?  And about reverse polish notation?

Offline Panda

  • Global Moderator
  • Bot Destroyer
  • *****
  • Posts: 476
  • Computer Science Undergraduate (nerd)
    • View Profile
Re: Command Shortcutting
« Reply #26 on: April 08, 2015, 06:05:49 PM »
So I'm going to apologize upfront for any cultural imperialism I bring with me to the table, and defend myself by simply saying that it's the way things are (in the world at large).

I don't think you need to apologise about this; I suppose you could express a desire for it to be different. It's the current standard that majority work towards. If we came to have an international community (further than American vs. British English) then the documentation could also become focused towards other languages. We lack both the need and motivation to do that since we're quite a niche community.

Offline spike43884

  • Bot Overlord
  • ****
  • Posts: 656
    • View Profile
Re: Command Shortcutting
« Reply #27 on: April 09, 2015, 10:08:19 AM »
Quote
I know it takes extra typing, but only one set of alternatives won't be that hard.
Quote
Now if your still really concerned about it taking longer to write, just send me a link to the current DB3 commands and just a quick link to the definitions of them and I'd personally write it.
These both require future maintenance and can increase the number of locations in the code that errors can appear. If you decide that once you've put them in that you're no longer going to maintain them, it's up to somebody else to do it. What difference is there for you by doing this compared to

Quote
I know it takes extra typing, but only one set of alternatives won't be that hard.
Quote
.attack
Well, rather than the original shoot, I want shot instead but Numsgil wants strike. Which ones do we include?

Quote
Try to put yourself in the shoes of 'imbecile' thats never touched DB before. I know for certain when I started, the first 4 weeks or so that when I first glanced at the language it was so weirdly done, with weird names for simple things that I just stuck to putting random bots in evolution sims
By adding more variable names, new DBers are going to be further confused. There can be two bots written in 2 different ways that does the exactly same thing (especially in terms of stack manipulation, etc.), it doesn't make it easier for them at all.

Your concerns are not irrelevant or invalid; the variable names can be very obscure at times and I guess this will be something considered in DB3. Since it's completely separate to DB2, no variable names are required to be carried over from DB2. In the end, the

Despite this, a design decision has been made and it's not going to change. One of the biggest problems with DB2, in my opinion, was the amalgamation of different design decisions without communication between the start and the end. The concepts of DRY are being used despite your disagreements and it's clear that a large proportion of this community (currently 3 against 1 in this thread) agrees with this decision.

I'm going to put two points that will hopefully end this argument: it really is Numsgil's decision and we can only offer our opinions and discussions towards features (since he has been the developer for how many years); the feature you have requested is within DB3 (somewhat) and you have to compromise somewhere.

Oh I don't mind some-what of a compromise but crucially numsigl hasn't expressed any sort of willingness to a compromise. Im going to primarily tackle the point about New DB'ers being confused... The current names are confusing to new DB'ers and every name will need a little bit of learning, yet using completely new and different names to DB2 only will confuse the classic DB2'rs so if you don't have alternatives you have to make a choice between possibly losing the few remaining DB2'ers as they might not want to learn it again, or keep it forever more complicated for new DB'ers. *Roughly* one set of alternatives fits both sets of people, presuming they've learnt one set of commands...they just need to see which command that responds to in their set, you could have a 4 column table showing all the commands. Column 1 shows the primary name for it, Column 2 just gives a line of code with that primary name just to show how it may be used, Column 3 shows the secondary name for it, and Column 4 just gives a line of code with that secondary name just to show how it may be used. Then they just quickly glance at the table, Oh yeah ".strike" responds to ".shoot"


Plus, im confused what your getting at with your point of "maintaining it". It requires, well not really much more maintenance than the traditional single set of commands...You just have the alternative set reference the primary set?

Now to tackle nums point of "we can't cover everyone" is correct, im agreeing there but heres a bit of business to you, some actual business logic and not the mock-up plans that businessmen make normally. We can cover our primary groups of people. You say about well it wouldn't cover people that speak japanese, yet I haven't seen a post in the forums in japanese, currently all posts I've seen in the forums are in english (one form or another) or russian (yes, a few russian posts here and there) so we can identify those are our primary 2 groups. Now we can also note that the wiki is in english, and has a tutorial in russian backing up this assumption. Ok, now we can wittle it down further that a lot more of the current resources are in english. Putting languages a side of a moment, we have groups of learning styles people prefer, plus how experienced they are in programming languages and which programming languages they're experienced in this will effect how things would be described to make sense to them. Now to start we can have one set of alternatives, for a key point, we'll then have a system which we can see works code-wise for referencing alternative names...Then we have to tackle a command set for the biggest groups of learning styles/most popular programming languages to show some similarity in the names to what they would use...We can group similar ones together to save work. We primarily need to target these sets to work for people who speak english (of one form or another) and who speak russian. Lets say because english is the most notable language used in DB so far that the primary commands, and the secondary set are for english users, then if at a later date a tertiary set is created we can target russian-speaking individuals.

As in business, or many other thing as business is related to a lot of things in its philosophy, if you can't cover everyone, cover the most important people. Lets give a (some-what unrelated) example which can follow this hypothesis:
Your running a prison thats slightly understaffed, you have 3 sectors in this prison, Sector C - Which houses people who have committed fraud or similar offenses. Sector B - Which houses juvenile crimials and Sector A - Which houses people who have committed violent crime. A mass breakout is underway and you can only be certain to cover 2 sectors, if you attempt to cover 3 its almost certain criminals from all of the sectors will escape. Which two sectors do you choose? Well, of course its going to be Sector's A and C. Why? Well, Sector B houses juveniles which haven't likely commited crimes as major as sector A, but then why not let Sector C free? Well, because they could disapeer, they're crimes are often behind computer screens or on the black market so they're harder to catch.

Prioritising groups of people! This idea everyone is equal is a good idea to follow in social aspects, but realistically for marketing, or communicating that needs to be thrown out the window. I do know about def, but its nicer with the sometimes limited space of commands to reserve that for extra value storage, plus as i've stated before, you need to know what the original command does to be able to use def to make an alternative! Now if your going to be lazy and not even consider an alternative of any form, then an extra folder would be good then you can store .txt files in there and then you can have your alternatives in there. Im confortable with reverse polish notation but when I was new to DB2 it was a hell-hole. You see it doesn't take that much effort to make 1 set of alternatives, and actually...One set of alternatives is realistically all you need. If you have one single set, you encompass a system to accept alternative languages and DB is nicely opensource. Now opensource games get mods, or opensource programs get little plugins to add extra compatibility or extra features... Once you've created one set of alternatives, theres a way to make alternatives in DB3 and thus, combining that with the fact DB is opensource if a person who speaks japanese natively, but also knows british they will have a way to make a japanese alternative, then they can invite they're friends who only speak japanese...And so on! The fact is, all you need is to compromise to one set of alternatives! Its just like how DB2's language is some-what different to what you want DB3's language to be, DB3 is an alternative to DB2, which is an alternative to DB.
Autism can allow so much joy, and at the same time sadness to be seen. Our world is weird, and full of contradiction everywhere, yet somehow at moments seems to come together, and make near perfect sense.

Offline Panda

  • Global Moderator
  • Bot Destroyer
  • *****
  • Posts: 476
  • Computer Science Undergraduate (nerd)
    • View Profile
Re: Command Shortcutting
« Reply #28 on: April 09, 2015, 01:14:16 PM »
Oh I don't mind some-what of a compromise but crucially numsigl hasn't expressed any sort of willingness to a compromise.
The feature already exists, just not in the way you want it. He has also given you additional options like #include which would remove all of your . The way that you want it implemented goes against the design.

The main problem with introducing one alternative is that we have to introduce more (since somebody else might feel strongly about a specific naming).

Maintenance would include, bugfixes, documentation, redesign etc.

Despite all of this, Numsgil, are .sx and .dx going to be retained for DB3? They are both obscure and it adds to the learning curve for newbies and, well, I can never remember the difference (but I haven't ever programmed bots for long enough). The only reason that I can see for keeping it would be in homage to the original creator or to keep some familiarity to older users. However, I don't know how fussed other users would be with keeping it.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: Command Shortcutting
« Reply #29 on: April 09, 2015, 01:37:43 PM »
Despite all of this, Numsgil, are .sx and .dx going to be retained for DB3? They are both obscure and it adds to the learning curve for newbies and, well, I can never remember the difference (but I haven't ever programmed bots for long enough). The only reason that I can see for keeping it would be in homage to the original creator or to keep some familiarity to older users. However, I don't know how fussed other users would be with keeping it.

I'm not married to DB2 sysvar names.  More to the point I think the way the bots will control will be so different as to render most of the sysvars in DB2 moot.  So for instance, for dx and sx, you probably don't control your torque directly like that.  Instead you induce a flow across various panels to produce the torque.  That is, if your shape was a square, you'd induce a rightward fluid flow along the top panel, a downwards flow across the right panel, and leftwards flow across the bottom panel, and an upward flow across the left panel, and the net result is (should be) a net torque and you'll turn.  This simulates things like cilia that real cells have.  Controlling that in DNA in a way that makes sense is an open problem.  But it points to how very different things should end up being in DB3.

Other different things, just to run through the list real quick: shots are basically gone, at least as the primary weapons.  Instead you'd try to either lyse (break open) the other cell and drink in its guts as they're released to the fluid around you or you'd engulf them inside yourself and try to break them down with digestive enzymes over time.  So all the shot commands are pretty moot.

To reproduce, you'd have to build up some panels to separate yourself in two and then split.  Which would take more than one cycle certainly.  Again, the exact control scheme is up in the air, but certainly a simple repro sysvar is insufficient.

Basic metabolism will include at the very least nrg like we have now plus some amino acid analog (maybe more than one, maybe just one, depending on how important I think having multiple possible limiting resources is) that is used to build up "organelles" like chloroplasts, the panels themselves, "motors" used to control the shape of the bot, etc. etc., plus something like sugars/fats for long term nrg storage (converting between nrg and fats is throttled by something like a mitochondria organelle and how much bandwidth it has for conversions).  The fdbody/strbody sysvars are primitive in comparison.

Even things like eyes, where I don't have exact plans but a few different possible approximate plans, it's going to be way more complex than the eye1-eye9 in DB2, so those sysvars don't really apply either.

However I would like to keep the sysvar names fairly short and compact, so in that way similar to what DB2 does.  I'm going to avoid long names like build_a_chloroplast in favor of something like mkchloro.  But at the very least there'll be some sensical naming scheme.  Like all sysvars that create things (panels, substances, etc.) are prefixed with "mk" for "make" maybe.  That sort of thing.  It gets hard because some things cells do don't really have a common word for them.  Like inducing a flow across a panel like I was talking about earlier using cilia.  You could maybe call it "rowing", but that's a pretty coarse comparison.  And even though a lot of the concepts map to cellular biology if I label everything with words like "lyse" and "phagocytosis" I'm sure I'm going to lose some significant portion of my audience.

So I'll need to spend some time and be clever with the terms and names.  When things get that far I'll make suggestions and try to get feedback on the forums.