Hmm, maybe we should write a function in enigma to help with this.

Code Select Expand

file_in_game_directory(string filename)

It's not something I can write just myself through as I can't test cross-platform.

http://pastebin.com/1UF5v1sU
http://pastebin.com/EGS8VgnY
http://pastebin.com/S2neAq4S

Is this then on your todo list forthevin? Just so I know.

Sounds fine it me, I might have gone for enigma_local but it doesn't really matter what it's called :F

[using]

In response to a suggestion that Josh has been throwing around for a while I would like to start a topic about this so it can be further discussed. I for one would like to see it happen.

These are some previous quotes from the Christmas plan topic about it:

Also, who among you is interested in the idea of encapsulating EDL types and functions in their own namespace? It would make it easier to deal with noise from library implementations, but it would require putting lots of shit into that namespace and using lots of shit from STDC.

In other words, we'd no longer have problems with time or list being illegal variable names unless the user specifically said, [snip=EDL]using std::list;[/snip] or [snip=EDL]using namespace std;[/snip], which I intend to unify between all viable backends (meaning, in JavaScript as well).

The new parser is much, much more adept at making these distinctions, so I can probably get it to allow using types and shit as variable names (especially in compatibility mode), but this would be a fix-all.

Encapsulation of EDL types and functions would be nice, especially if it solves the problems with "time" and "list" being used as variable names. How easy would it be to set up the system such that EDL types and functions can reside in both the global namespace and the EDL namespace? If it is easy, I would like the system to be set up that way, since that should enable easy step-wise migration.

Simple as placing "using namespace <name here>;" in the global scope. Just like you would any other namespace. I'll set ENIGMA up to read from :: or ::edlwhatever based on a macro. After everything's migrated, or we think everything's migrated, you'll just flip that flag and try compiling.

Yes, Intellisense sucks. Just warn on errors when a form is closed, that way any syntax errors are always going to be brought to the users attention.

Try working_directory + "\file"

Yeah I don't think it needs a completely different logo, the ENIGMA logo is fine as it is and actually represents the product; you could just stick a wx in it.

Can you tell us what the particle error was?

Josh has added his goals to the wiki. And I have also scoured the ENIGMA source for odds and ends that need to be done and added those to the wiki also.
http://enigma-dev.org/docs/Wiki/ENIGMA:Todo

Preferably this wiki list should be maintained by individuals when they complete a task or add todo points in the ENIGMA source.

All the extension are nicely placed together. I think maybe the Extensions folder should be moved though from US to the SHELL root?

What are you up to next then forthevin? There won't be many GM functions left soon. Of course there's some stuff to do after Josh finishes his shit, but he's usually on the toilet quite a while so God know when that will go down.

I'm sure Ism is going to be happy to read this thread

What do you mean my code was hard to, whatever the hell you said, if you ask me I am a pretty optimal, clean, efficient programmer. If you look at any of my source code everything will always follow a logical coherent path, usually some of my source files can be tricky.

The problem was with the use of some 8.1 only functions, which were wrapped in with the project - it looked like too much effort getting it to work on 8.0 which is what I use.

By the way the main method of communicating here is on the IRC channel, this forum doesn't actually have that much activity as of now since most things take place there.

I say go with function double(), then allow function() as well which will default to variant return type.

I recognize you from the GMC, and actually looked at that Mario engine a few days ago - I don't have GM8.1 though and the source looked a bit convoluted so I couldn't be bothered getting it to work. If you check the EDC (http://enigma-dev.org/edc/games.php?action=list) you can see that I've actually got the Kingspace engines working in ENIGMA.

As far as GM compatibility is concerned, it exists in ENIGMA now so there's not really much point in removing it. And I wouldn't overlook it's benefits, if ENIGMA never had GM compatibility I doubt the project would even be running still - and certainly a lot of people (myself included) would never have come here. In any case it doesn't require much effort to maintain and a lot of the missing GM features are desired in ENIGMA anyway.

So what the **** are you guys thinking over here?

The thing that you probably don't realize is that there aren't really that many developers here and the main developer, Josh, is constantly busy with school and work. YYG's have a team of paid developers and a lot of money to spend, they're bound to make progress in areas where ENIGMA is not. Like the TheExDeus said it's about getting the right developers, if you want a feature in ENIGMA you can always try writing it yourself if you have the ability to do so - if ENIGMA had as large a user-base as GM has the project would be massively featureful.