[main]

Well after the upgrade I would like to bring this topic up.

It seems there is not a direct goal set or aim for the project at the moment. People are just randomly implementing bits & pieces wherever, which does progress things yes but I think you'll find if things are more directed progress happens much quicker and is much more noticeable. When you have a set goal it also greatly increases the motivation for doing tasks that are less appealing and people as such put off, by just doing bits & pieces these will never get done because there is no direct reason to and they will always be put to last but if it is necessary to do them in order to reach a goal then they will more likely be done.

Previously you had a goal set to get a stable first release out which seemed like a good goal but then it got drifted away from. So I ask exactly is the main aim at the moment which you want for the project?

• A stable release?
  
• GM compatibility?
  
• To annoy YYG's or prove them or the gmc wrong about something?
  
• A bigger user base?
  
• More developers?
  
• More games created?
  
• Or something else?
  

After you work that out you can set individual goals and actually work in parts directly towards achieving this. Doing a wish-wash of things and bits & pieces is not the best way to make things happen.

ps. yes this topic is largely directed towards you josh :p and it may go against how you naturally work but if you have a clear aim I think other people are more likely to help work around that also. I am interested to hear what other people are looking to get out of the project though.

Thank god, it was getting very bad before and would have likely pushed away new people visiting the site. We should really thank you and ism extra though since you're paying for it :]

Hopefully it should hold together now, right?

OK but will these things be done automatically? Because some users may not work all their code to be automatically changed and want to view what the changes will be and accept them before they are made. This is how most programs handle corrections like this.

Also is just adding an option for 'Fix compatibility' the best that can be done? Because likely some people will not know about it and then when compiling shit will still go wrong. I think there should preferably be some sort of message given to users when either compiling from GM files or loading them, of course if it was just on loading people can still copy/paste incompatible gml into their games or add incompatible gml themselves without realising so there should preferably also be some sort of check in the script editor alongside it.

There has been a lot of discussion on this but I have not seen an actual topic in place to get a full spec for it. A compatibility resolver should ideally check for any possibility incompatibilities in a file that may have been inherited from a GM file then offer the user a convenient way to resolve them, so the ease of transition from GM files to ENIGMA is quick and simple.

The questions then that need to be answered are:

• When should the resolver will be run?

• What things should the resolver check for?

• How will the resolver check for them?

• How will the resolver solve these issues and how should the user interface for it work?

I'm starting to see that trackers are probably better to use.  But what I am thinking is that they should not be used for suggestions only bug reports. Suggestions seem a lot better posted on the wiki and also the forum if they need discussion.

There are still currently issues with the trackers though. LGM and ENIGMA's tracker being separate is not good, not as many people know about LGM's tracker and it isn't frequented, there is also the issue with log-ins. And bugspray still has many needed features missing, also note that things like TGMG's reports on his docs should all be posted on bugspray but they've just been left there.

Actually I'm starting to have second thoughts about the wiki hmm. Because there will be an issue when developers need to respond and get more info from a report, users will not easily be able to see that the report has been responded to.

Just be aware that I usually try to address Mantis bugs first unless they're really trivial things that I agree with.

Well with this proposal people won't be posting on the Mantis, they will be posting on the wiki. Then you can then keep the mantis categorised how you like.

I'll see what some other people think, then think about how to wiki could be set-up.

Maybe we should have a two stage system. It seems to me that for a general user it would be easier and better to use the wiki system in order to report bugs, I feel a lot of users will not know how to fill in a tracker report as desired by a developer and this may actually also deter them from doing so.

Then like you said the reports on the wiki can be used by scooped up by developers then if desired posted on their own tracker which they are familiar with,  like to use, can fill in properly and to give themselves more details on the bug. The main problem that may arise from this is the loss of information from one report system to the other so I developer would ideally keep the wiki reports up-to-date if they are themselves using a separate tracker. Although tracker references could also be posted on the wiki (or even reports could be made into urls which go to the corresponding tracker report).

EDIT: I see you posted while I was, I will respond to your post in a minute.

OK I think this is where my above suggestion would come in. I think all bugs could be categorised on single pages under headers, then bugs could be externally referenced to trackers if wanted. Reports can be removed on the wiki when they have been resolved so it should hopefully not become over populated.

I personally feel you are actually in a minority here Ism. Josh doesn't seem to care about the tracker (and this has been shown in the past will it often becoming out of date) I think he would be able to just happily use the wiki reports which others can help maintain. I feel users like TGMG or me are more drawn to the wiki style as we can mass report at once. And for new members or the common irc user that can be too lazy or do not know exactly how to make a proper report the wiki will be more appealing as well. Although I am also drawn to the organization of a tracker but these may actually be best run separately and solely by developers anyway so they can be kept properly documented.

I'm personally leaning towards the wiki instead of a separate tracker and hopefully mock up some standardized way of handling reports.

I see many benefits of using it:

• It's very easily accessible, people are naturally logged in (this is currently a large issue I find with the LGM tracker)
  
• It's quick and easy for someone to jot a bug down, especially useful when wishing to report multiple bugs at once!
  
• It's location can be easily known by users
  
• The wiki itself is naturally frequented so people will more regularly see updates
  
• All reports can be edited by all users (it's currently a major is with ENIGMA's tracker, that you can't even edit your own reports)
  
• There is flexibility in the organization you can use. People can group together different areas of suggestions easily and this can easily be reorganized by other people also
  
  The main thing to work out would be what sort of organization to use. If and how reports should be separated into different pages, what categorization should be used, how things will be marked so developers know what problems they should deal with.

Just wanted to open a discussion about trackers because I question if the current set-up really the best we can come up with?

Currently things are being posted in multiple places: the enigma tracker, lgm tracker, wiki, docs, forum, irc. This clearly isn't the best way to keep things organised. Any sort of bug tracking system should preferably be all in one place, easily accessible to users, convenient and easy to use, easy for developers to see which problems relate to them and easy to filter so people know what problems exist in which areas.

So I'm opening the floor to suggestions and to see if we can come to some sort of consensus of what should be used.

What exactly didn't work? It's just a simple insertion in two places.

I can't remember, I was going to go back to it at the end but I forgot so I just left it for josh to add when he moved everything into .cpp (however I see now that he didn't add it or actually change anything that was talked about in the irc).

GM allows you to ds_map_add() twice with the same key, but you can only ever access the first one you added so it seems more like a bug than anything useful. There's really no reason keep that behavior.

You can't reference it directly but if you delete a key then you are able to reference the one next which had the same key.

"My car's engine is broken but it was annoying to fix so I didn't bother. The wheels still turn, right?"

This is a very minor inconsistency with a behaviour that shouldn't be relied on anyway and is also unlikely to cause any detrimental inconsistency with anybody's game, fixing it will cost on efficiency I deemed it not worth doing.

Yes that would work.

You should free the arrays you allocate in the grid class- C++ isn't garbage collected and heap-allocated memory doesn't get freed when it goes out of scope. Just "delete[] grid_array;" in the destructor and when you resize it.

I tried that when I was writing it and it didn't work, so I just left it for Josh to sort.

I'm not entirely sure why you would choose multimap over map or unordered_map for ds_map. It just seems to add complexity in this case.

To mimic GM's behaviour, it allows you to set two keys the same.

You shouldn't erase and re-insert for ds_*_replace()- it's redundant and in the case of vector (where it has to copy the other elements over and then back) very slow.

What do you use instead?

For ds_map_find_next() you could just get an iterator to the key and increment it instead of doing a linear search through the map.

Doesn't work with multimap in the case where two keys have been set the same.

GM's behavior with regard to priority queues is the point of priority queues. There's no problem with adding multiple things that have the same priority- in that case it should simply act as the queue that its name implies and return the first one inserted.

That behaviour was annoying to replicate so I didn't bother. I don't think it makes too much difference.

Yeah I will grab those Rusky if you still have them.

[venture]

Slam drago check the wiki for more info. Also advisory to go venture onto the irc.