Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Panda

Pages: 1 [2] 3 4 ... 31
16
Darwinbots3 / Re: Command Shortcutting
« 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.

17
Darwinbots3 / Re: Command Shortcutting
« 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.

18
Darwinbots3 / Re: Command Shortcutting
« 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.

19
Darwinbots3 / Re: Viruses (Re: Programming task (DNA editor))
« on: April 07, 2015, 06:13:07 PM »
I don't understand how all of the DB3 processes are going to work.

Is there a location where all of the decisions made so far are/the options that there is? I suppose this sort of resource would be really difficult to keep up to date (if it was a wiki page) so I'm just going to read through everything in the forums.

20
Darwinbots3 / Re: Viruses (Re: Programming task (DNA editor))
« on: April 07, 2015, 05:31:59 PM »
I like the idea of bots "voting" on stores.

Some sort of majority rule sounds good at first, but it gets in to situations where each DNA strand tries to red queen race the others to have the majority.  Meaning lots and lots of duplicated DNA running.  That's not something that I want to encourage for performance reasons.  So I think the voting structure needs to be something you can't ballot stuff.  Taking the max is the best I've come up with so far.

What do you mean by taking the max? The maximum value to be stored?

21
Darwinbots3 / Re: Viruses (Re: Programming task (DNA editor))
« on: April 07, 2015, 02:12:00 PM »
I like the idea of bots "voting" on stores.

What sort of protection could bots have against viruses, other than a more "artificial" protection?

22
Darwinbots3 / Re: Command Shortcutting
« 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?

23
Darwinbots3 / Re: Viruses (Re: Programming task (DNA editor))
« on: April 07, 2015, 01:55:00 PM »
I think viruses were overpowered. Just compiled a quick list with their problems:
  • genes injected (no or little incubation time)
  • artificial protection
  • changes original bots execution
  • little ability for bots to modify or "view" own code (e.g. no checksum for individual genes to identify )

24
Darwinbots3 / Re: Command Shortcutting
« 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.

25
Darwinbots3 / Re: Viruses (Re: Programming task (DNA editor))
« on: April 06, 2015, 07:31:46 AM »
The DarwinBots2 "virus" wasn't particularly virus like; it was simply a way to transfer a gene using a shot, which inserted the gene into another robot.

The cost of a "virus" (if DB3 using the same idea as in DB2) will probably a community decision, depending on how powerful the concept is.

26
Darwinbots3 / Re: Command Shortcutting
« on: April 04, 2015, 10:48:02 AM »
Heres a simpler way to put it, if you want to do DRY then without using any sort of translator or tool to translate/interpret it for you tell me what this says in english:
01001101 01111001 00100000 01100100 01100101 01100001 01110010 00100000 01100110 01110010 01101001 01100101 01101110 01100100 00101100 00100000 01111001 01101111 01110101 01110010 00100000 01110000 01101000 01101001 01101100 01101111 01110011 01101111 01110000 01101000 01111001 00100000 01101001 01110011 00100000 01110100 01100101 01110010 01110010 01101001 01100010 01101100 01100101 00100000 01110111 01110010 01101111 01101110 01100111 00101110 00100000 01001110 01101111 01110111 00100000 01110011 01110100 01101111 01110000 00100000 01100010 01100101 01101001 01101110 01100111 00100000 01110011 01110100 01110101 01100010 01100010 01101111 01110010 01101110 00100000 01100001 01101110 01100100 00100000 01110011 01110101 01110010 01110010 01100101 01101110 01100100 01100101 01110010 00100000 01110100 01101111 00100000 01110100 01101000 01100101 00100000 01100101 01110110 01101001 01100100 01100101 01101110 01100011 01100101 00100000 01110000 01110010 01100101 01110011 01100101 01101110 01110100 01100101 01100100 00100000 01100010 01100101 01100110 01101111 01110010 01100101 00100000 01111001 01101111 01110101 00101110

I'm pretty sure for DRY, you would be expected to use a sort of translator/tool for that to say something in English (but nobody would write it like that in the first place using DRY) - there is reason for software and libraries having documentation, partly for everybody to agree on a standard. I agree with Numsgil here, a single standard would be better than, probably, obfuscating code (if everybody would just write things in different ways).

In any case, it would not take that long for you to learn the new commands, even if you do make mistakes on the way. Hopefully, the IDE will help you will them.

27
Darwinbots3 / Re: Programming task (DNA editor)
« on: April 03, 2015, 04:07:34 PM »
I'm sure I will get around to them! It'll be in a couple of months before I'll have the free time to do it.

After that I hope to get on with something else for DB3, if there's anything I can do, but I can't promise anything.

28
Suggestions / Re: Did anyone else want chloroplasts?
« on: September 29, 2014, 01:17:44 PM »
The plan was originally that all of those would occur and the area limiting part wasn't going to be implemented but that was Bots decision to include. If you have a look at http://forum.darwinbots.com/index.php/topic,3487.0.html. I implemented that at one point; however, I had problems releasing it. I think this is the sort of thing you're talking about more, aren't you?

29
Suggestions / Re: Did anyone else want chloroplasts?
« on: September 28, 2014, 06:04:10 PM »
Panda, if they do that and it's still better for bots to just sit and feed on veggies, then they don't do that enough. Jack up the penalties until running around and feeding on veggies becomes a competitive strategy.
Which bit are you talking about?

30
Suggestions / Re: Did anyone else want chloroplasts?
« on: September 28, 2014, 08:40:45 AM »
Shvarz's they pretty much do that now.

EDIT: I think the way that Botsareus has explained it has made it complicated. He added an "area limiter" as well so there's only a certain amount of energy available in a simulation. Other than that, the features you are talking about (and are all implemented) were the ones that were suggested last year, or the year before, in the first place.

Pages: 1 [2] 3 4 ... 31