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 - Josh @ Dreamland

Announcements / Re: New LGM Backend Map/List
« on: November 24, 2011, 11:11:55 AM »
/kick Fede-lasse

General ENIGMA / Re: FFI F'Up
« on: November 22, 2011, 06:31:42 PM »
I guess I could tell the makefile how to build it from scratch. I'll deal with that when I get home.

Announcements / Re: New LGM Backend Map/List
« on: November 22, 2011, 02:17:37 PM »
So uh, when do I get my Definitions resource, IsmAvatar?

General ENIGMA / Re: FFI F'Up
« on: November 22, 2011, 02:15:43 PM »
Three people have that problem, three people don't. I don't know what's causing it. FFI is relatively light weight; there's not much point to making it an extension. I suppose we can once that system is implemented for subsystems.

Announcements / Re: New LGM Backend Map/List
« on: November 21, 2011, 08:43:34 AM »
Glad to hear you have that done, Ism.

Depends how you make the array.

string array[10000]; // Yes
var array; array[10000] = 0; // No

General ENIGMA / Re: Makefile is fucked
« on: November 09, 2011, 11:18:04 PM »
There wouldn't be that many results for his name.

General ENIGMA / Re: Makefile is fucked
« on: November 08, 2011, 08:59:47 PM »
Ism's bug memory is roughly zero.

General ENIGMA / Re: What's the status of this project?
« on: November 08, 2011, 09:35:42 AM »
Actually, 39DLL would go in ENIGMAsystem/SHELL/Network_Systems, along with Ism's EnigmaSockets thing. We haven't added it because it's not... satisfactory. An MPlay port will also go in there.

So yes, 3D was "implemented" by Zach and does not work at all. Particles haven't been started. Surfaces should work; HaRRi's tested them on Windows, but not since my update, and I've not tested them at all. Pathfinding is done. You can't create paths in the editor yet, but you can generate them using GM's pathfinding functions.

A list of all available functions can be found in LGM under Enigma->Keywords.
A large, semi-maintained list of things that need done:
A list of things we're not doing:

If you're on Mac, you should see an android option under the compilers in Enigma Settings.

Proposals / Re: EDL V.Next
« on: November 08, 2011, 09:19:52 AM »
Good question.

Also, which part is Stockholm Syndrome? I just see it as business strategy; any more I'm just trying to assemble an engine, and GML is along for the ride.

Proposals / Re: EDL V.Next
« on: November 08, 2011, 09:06:04 AM »
EDL allows flopping between real and string, as in GML. It also allows flopping between ds_stack and ds_list, etc, because all of them are represented by integers. If this ever ceased to be the case...

If I really wanted, I could implement a highly unsafe integer conversion for all C++ containers and user structures, but that'd end up being pointless. Even with the ability to integerize complicated data structures on a whim, calling a generic method like erase() or length() or size() on one of them would be impossible to syntax check without some sort of type tracing that would involve going out of scope. Way out of scope. Like, the entire game, every time I need to make sure that call applies.

GM's typing is only dynamic because it doesn't offer a way of storing anything locally. Dynamic typing between all native classes has never been a plan in ENIGMA--Its availability in JavaScript is a side effect that will ultimately not be supported except in native scripts.

Perhaps in the future I will look into standardizing containers for EDL and at that point will look into making sure they all have those methods available to prevent compile errors. Still, the efficiency of the operation would bother me. I'm basically content to keep segregating functions like ds_blah from blah<blahblah> until users develop the ability to type things manually.

Proposals / Re: EDL V.Next
« on: November 07, 2011, 09:49:23 PM »
Nah, I'm just insane.

...Okay, maybe the volumes of school shit I have to deal with are getting to me.

Anyway, I'll probably end up adding those things to ENIGMA in hell, but until then, I'm going to pass on them. I might allow the C++ auto keyword, but I don't want to ambiguate var--in GML, and in JavaScript, var can change types dynamically. I don't want people to think they can flop from map to list on a whim.

Anyway, the compiler can currently identify C++ terms just fine. The issue is in type resolution with those. My C parser's argument type tracking isn't there, and its template resolution is abysmal.

Proposals / Re: EDL V.Next
« on: November 07, 2011, 05:31:12 PM »
I keep giving this another lookover, but every time I see it, I just think, "Fuck everything about this."

I mean, calling class::something() on a typeless variable? Fuck that. People want compile-time "too many arguments to..." errors. I can't offer that if people can flop entire class types whenever the fuck they want, without any kind of predetermination.

foreign()? __cpp_pod__? ENIGMA_EXPORT? What the shit are these? How about, instead of dropping breadcrumb trails for the compiler, we just say what the fuck we want as we want it? Like with strong types, and by just giving access to scripting in the native language.

Announcements / Re: We can't decide
« on: November 07, 2011, 05:09:36 PM »
I suppose. I'd still say we're in a pretty gunky predicament, especially with the need to support old GM formats and new, never-load formats.

Issues Help Desk / Re: svnkit error
« on: November 06, 2011, 12:26:57 AM »
But it is recognizing the MinGW installation, yes?

This thread's on the old side; what is the version number of the zip you used? A while back, there was an error-prone copy uploaded. It's possible you've accidentally happened upon it (The zip had an old version of ENIGMA.exe but a new version of the GCC template).

Issues Help Desk / Re: svnkit error
« on: November 05, 2011, 11:15:56 PM »
You are getting the same Java exception? Is this with a fresh ENIGMA install as well, or just re-running the same ENIGMA.exe? If you're just running it again, you may need to delete the config file it attempted to generate under Compilers/Windows/gcc.ey.