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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
121
General ENIGMA / Re: Does ENIGMA work with Game Maker .exe files and my 2 ENIGMA other questions
« on: August 13, 2015, 05:38:12 am »
I think I have been "Developer" for years now. I don't think it happened just now.
edit: Or maybe I was "Contributor".
edit: Or maybe I was "Contributor".
122
Developing ENIGMA / Re: Debuging the .dll
« on: August 13, 2015, 05:00:30 am »
In this topic I didn't mentioned debugging symbols in context of Java and I understand it was misleading to mention them in the previous topic. I was just referring to the fact that java.exe stops about 6 times while loading LGM. Look here: http://pastebin.com/GHegrqNA
This is running LGM WITHOUT ENIGMA. It is when I copied LGM outside in a totally different folder and run it. It of course runs fine and doesn't crash, but when I run it trough GDB it stopped 6 times. The first one was because of a breakpoint which means LGM still has some of them set in the version you uploaded (or maybe they are in Java.exe itself, but I doubt it), then the next 5 times it stopped with SIGSEGV. It didn't crash in a way that stopped the process as I could just type "c" and continue. Then these 6 stops later LGM was fully loaded and open. I could then use it and close it. Maybe this is normal for Java application, I am not sure. But it could show that LGM has some internal problems while loading too.
This topic is about the .dll though (parser). Because I just noted how I can debug problems in there too. If LGM crashes because of the .dll it will show up gdb and as the .dll does have debugging symbols I get a better error message. In java.exe case the backtrace is usually empty and I would need a debug version of java.exe to see them. But that wouldn't allow to pinpoint the problem down to LGM, because as you mentioned Java doesn't work that way. Usually LGM trows an exception with detailed path to problem, but it seems that LGM can also crash (like due to the plugin) without trowing anything.
This is running LGM WITHOUT ENIGMA. It is when I copied LGM outside in a totally different folder and run it. It of course runs fine and doesn't crash, but when I run it trough GDB it stopped 6 times. The first one was because of a breakpoint which means LGM still has some of them set in the version you uploaded (or maybe they are in Java.exe itself, but I doubt it), then the next 5 times it stopped with SIGSEGV. It didn't crash in a way that stopped the process as I could just type "c" and continue. Then these 6 stops later LGM was fully loaded and open. I could then use it and close it. Maybe this is normal for Java application, I am not sure. But it could show that LGM has some internal problems while loading too.
This topic is about the .dll though (parser). Because I just noted how I can debug problems in there too. If LGM crashes because of the .dll it will show up gdb and as the .dll does have debugging symbols I get a better error message. In java.exe case the backtrace is usually empty and I would need a debug version of java.exe to see them. But that wouldn't allow to pinpoint the problem down to LGM, because as you mentioned Java doesn't work that way. Usually LGM trows an exception with detailed path to problem, but it seems that LGM can also crash (like due to the plugin) without trowing anything.
123
Issues Help Desk / Re: [Fixed] Error on running/compiling game imported from GM:S
« on: August 13, 2015, 04:50:05 am »
Yeah, sorry, LGM/plugin is a mess. It basically called the compiler, yet, being in an invalid folder it failed. Instead of showing a good error message it just threw an exception. LGM/plugin does that A LOT. It trows exceptions like candies to children. That should be sorted out, but sadly I'm not the one who can do it.
"static" is keyword in C++ which EDL/GML (e.g. your code) is turned into. Sadly we cannot just automatically rename resources on compile (as that was one of the original methods proposed some time ago), because then in the code the resources must be replaced as well, but you cannot easily do it if the resource name is part of syntax. It is like naming a sprite "switch" and then replacing all "switch" statements in code with "spr_switch", it would just break everything.
Good practice (both in GM and ENIGMA) is to prefix resource names. Backgrounds start with bkg_, sprites with spr_, scripts with scr_, rooms with rm_ and so on. LGM (the IDE) even does that automatically when you create a new resource. It is meant as a reminder that you should do it or else there will be trouble.
There are also a few bugs with the parser that won't allow you to use valid code either, but that is usually something to do with variable access in scripts. But GML and EDL (what is used in ENIGMA) are not 100% compatible. They never were and probably never will be. On top of that GM and ENIGMA has diverged function wise, as GM implements something ENIGMA doesn't and ENIGMA implements a lot of function GM doesn't. As compatibility is no longer the main goal for a while now, I think we should somehow point this out on the website.
If your game is messed up because of an ENIGMA bug we would want to know that, but if it messed up because of the changes needed for compatibility with GM, then sadly you will just have to rewrite the parts that no longer function.
"static" is keyword in C++ which EDL/GML (e.g. your code) is turned into. Sadly we cannot just automatically rename resources on compile (as that was one of the original methods proposed some time ago), because then in the code the resources must be replaced as well, but you cannot easily do it if the resource name is part of syntax. It is like naming a sprite "switch" and then replacing all "switch" statements in code with "spr_switch", it would just break everything.
Good practice (both in GM and ENIGMA) is to prefix resource names. Backgrounds start with bkg_, sprites with spr_, scripts with scr_, rooms with rm_ and so on. LGM (the IDE) even does that automatically when you create a new resource. It is meant as a reminder that you should do it or else there will be trouble.
There are also a few bugs with the parser that won't allow you to use valid code either, but that is usually something to do with variable access in scripts. But GML and EDL (what is used in ENIGMA) are not 100% compatible. They never were and probably never will be. On top of that GM and ENIGMA has diverged function wise, as GM implements something ENIGMA doesn't and ENIGMA implements a lot of function GM doesn't. As compatibility is no longer the main goal for a while now, I think we should somehow point this out on the website.
If your game is messed up because of an ENIGMA bug we would want to know that, but if it messed up because of the changes needed for compatibility with GM, then sadly you will just have to rewrite the parts that no longer function.
124
Issues Help Desk / Re: No enigma tab
« on: August 13, 2015, 04:37:44 am »
So you can compile and run a simple "Hello World!"?
GM compatibility was never a "one-click" thing and it's possible in the future it might be even harder. But you should be able to easily rewrite the offending code. Also post here the errors and someone will probably be able to help.
GM compatibility was never a "one-click" thing and it's possible in the future it might be even harder. But you should be able to easily rewrite the offending code. Also post here the errors and someone will probably be able to help.
125
General ENIGMA / Re: Does ENIGMA work with Game Maker .exe files and my 2 ENIGMA other questions
« on: August 13, 2015, 04:33:04 am »
In compiled code it is usually not possible to get the original source back. You can just get assembler which is usually not that useful. It is possible to add debugging symbols to the exe (like when you press Debug in ENIGMA) which is actually your sourcecode. I think GM did it even for release mode some time ago, I reckon for better error messages. You cannot really show a detailed error if you don't include at least part of the source in game.
Resources of course can be extracted always. Both from GM and ENIGMA.
Resources of course can be extracted always. Both from GM and ENIGMA.
126
General ENIGMA / Re: Is Enigma safe to download, install etc.?
« on: August 13, 2015, 04:30:07 am »
Why wouldn't it be? Are you asking about viruses or about potential damage an install could do? The answer should be neither. Installation is non-destructive (as it doesn't actually "install" anything, it just extracts to a folder). And the installation is free from viruses or malware as far as I am aware.
127
Issues Help Desk / Re: JAVA Error
« on: August 11, 2015, 05:10:28 am »Quote
My Java stuff are actually in System32 instead of System32/SysWOW64That usually means that it is 64bit Java. SySWOW64 is Windows compatibility layer that allows 32bit applications work on 64bit windows. So everything inside that folder is usually 32bit, but outside of it is usually 64bit. You can check which Java you have by opening a terminal (cmd) and typing "java -version" (also post it here). I have "mixed mode" which means I have both 32bit and 64bit.
The error you are having though is slightly different from the one you linked in the troubleshooting page. The one in wiki talks about wrong version of Java. Your error talks about no Java at all. This is usually when 64bit Java is installed (which on modern PC's is the default option), while LGM and ENIGMA right now only works with 32bit Java. Another problem could be the version of Java. At least since version 1.8.0 Java doesn't actually install in system folders. They install in program files, like "C:\Program Files (x86)\Java\jre1.8.0_45\bin". If you have it in windows folder that means you have an old version.
What I suggest you do is download a new version of Java here: http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
When you install it then you should have the problem described in the wiki page, as that is sadly a known problem with new Java and old Java: http://stackoverflow.com/questions/9313353/error-when-checking-java-version-could-not-find-java-dll , http://stackoverflow.com/questions/19329047/could-not-find-java-se-runtime-environment-after-installing-java , http://stackoverflow.com/questions/6362037/java-error-opening-registry-key . But people usually don't need old Java and on new PC's with new installations this is not a problem.
128
General ENIGMA / Re: Does ENIGMA work with Game Maker .exe files and my 2 ENIGMA other questions
« on: August 11, 2015, 04:55:07 am »
I think TKG answered, but just to be clear:
If you mean GameMaker.exe as in the exe for GM program itself, then ENIGMA doesn't do anything at all with it and is in no way connected. If you mean a game .exe made by GM then TKG answered that (in short, we don't and can't do anything with that either).
If you mean GameMaker.exe as in the exe for GM program itself, then ENIGMA doesn't do anything at all with it and is in no way connected. If you mean a game .exe made by GM then TKG answered that (in short, we don't and can't do anything with that either).
129
General ENIGMA / Re: ENIGMA progress
« on: August 10, 2015, 04:57:38 am »Quote
I've seen it already and I don't think I care, it will take some time for it to take effect either way. I really would just rather use Linux which solved all of these problems a long time ago. I don't switch to Linux full time because I really do need things like Word which does happen to be more reliable than Google Doc's or Open/Libre Office. While I may be exaggerating the problems they are very real and I think you are undervaluing them. There are a large number of complaints about C++ but most of them Bjarne Stroustrup dismisses except for a standardized ABI. I don't mind coding in C++ at all and I did make a number of substantial improvements to ENIGMA's engine including starting that model class (though I've learned much more C++ since then) but this really turns me off from trying to build cross-platform applications or applications to be distributed in the language.Good read, but I agree with stroustup. Most of the "issues with C++" are either made up or just stems from not actually using C++. Like I work with a guy who doesn't like C++, because using STL relies you on "others people bugs", while himself writes everything in C with pointers and can hardly make code that doesn't explode. When I finally showed him how even a ranged for loop creates more optimized code than he could even write, he finally started looking more kindly on it.
http://www.stroustrup.com/slashdot_interview.html
Quote
The topic is pinned in "General ENIGMA" and I would appreciate it if someone else would build the ZIP occasionally. Josh could obviously give you FTP access to the server but I've just realized that we could just upload these to GitHub directly if Josh enables it on the repository. He does it this way for Calico (click "Releases"). I think we should upload the ENIGMA binary releases directly to GitHub since that is a standard/more common approach.I will do it when I get something stable. I'm playing with compiler too now so I can pack the newest one with 64bit's, but I have problems with LGM. Like it crashes when I have a different compiler in PATH. How can that even be? It works if the /bin I point to is the one coming with the installer now, but when I point to /bin from Dragons release it just crashes on startup. I don't even compile anything with it as the .dll already exists. This kind of weird LGM stuff is something I have to deal with, but as I don't code in Java it's hard for me to debug. Maybe you can at least give we LGM and plugin with symbols? Because now it trows like 5 SIGSEV's on startup when debugging with GDB, but it has no backtrace as there aren't any symbols I guess. Lookee here: http://enigma-dev.org/forums/index.php?topic=2561.new#new
edit: It looks like I tries to call something to do with the compiler on startup whether it is needed or not, because a third compiler I tried adding in PATH made LGM trow something about incompatible .dll even though IT WAS NOT even recompiled. This is a strange behavior indeed. The thing about LGM compiling the .dll actually has never worked for me in Windows. I have always needed to do it manually trough shell. So maybe either a setting to disable this? It would make startup faster as well.
Quote
That would be great as well because then users would at least be able to download a 32bit and 64bit version of ENIGMA and they wouldn't have to specifically install a 32 JDK/Java. You would have to recompile all of ENIGMA's plugins though and I also think you need to replace the jna.jar with the 64bit version. I hit too many errors and incompatibilities between MinGW64 and 32 and finally just gave up on packing it. It's sitting on my desktop and was the last thing I was trying to accomplish before I stopped contributing for this period of time. Largely because of my poor internet, if someone else were to begin packing the zip or just taking care of it instead of me by some standard/methodical approach as I did before it would make it easier for me to contribute to ENIGMA again in the future. I am actually mainly still interested in LateralGM's development so if I could maintain improvements and bugfixes to that and delegate the ENIGMA matters to someone else (regarding packaging LGM and everything) it would be a lot of work off my plate and free me up for more contributions to LGM.I will probably try creating both 32bit and 64bit installers. The difference only being the .jar's and .dll's. Both will come with 64bit compiler (which itself is 32bit exe) and both 32bit and 64bit "Additional's" so you can compile both from any installation of ENIGMA.
Quote
In my honest opinion I still like ENIGMA on Linux because it just uses the package manager, you install the necessary components one time and then ENIGMA just works. You can easily replace the lateralgm.jar and the entire ENIGMA framework just as it is expected.That is great and hopefully this is how Windows10 will allow you to work. I have already mentioned that Package Manager is the only thing I really miss about Linux.
Quote
Yes that is one thing that it needs but it is debatable whether the ENIGMA engine should provide such functionality as well, perhaps through a plugin because GM does have functions to add fonts at runtime that we never implemented and I believe Studio added TTF font support or w/e.I have looked at it and I think http://www.freetype.org/ is the way to go. I will at some point try implementing it if nobody else does.
130
Developing ENIGMA / Re: Debuging the .dll
« on: August 10, 2015, 04:39:53 am »
Another thing I noticed is that LGM has a lot of breakpoints left inside, so gdb keeps stopping at them. When we pack the "release" version of LGM we should remove them.
Also, LGM trows about 5 SIGSEGV's before it even loads. This could actually be it seeing on how many exceptions LGM actually shows (without crashing though). I thing LGM is also written in a very unsafe matter or at least null stuff is not checked. I know that LGM can crash if settings.ey is missing, if an extension misses something in a description, if LGM cannot find the compiler (that is probably the plugin though) and so on. All of those trown an exception when in reality that should be a warning at most.
Also, LGM trows about 5 SIGSEGV's before it even loads. This could actually be it seeing on how many exceptions LGM actually shows (without crashing though). I thing LGM is also written in a very unsafe matter or at least null stuff is not checked. I know that LGM can crash if settings.ey is missing, if an extension misses something in a description, if LGM cannot find the compiler (that is probably the plugin though) and so on. All of those trown an exception when in reality that should be a warning at most.
131
General ENIGMA / Re: ENIGMA progress
« on: August 09, 2015, 07:11:41 am »
TKG: Please, post offtopic in the offtopic forum only. And it cannot actually "die" if the only ones interested in the project is developers. It can die if the only ones interested in the project are the users from community. I agree that a lot of things need to change, like releases, the site, more bugfixes instead of features and so on. But that is not done by one person alone.
132
Issues Help Desk / Re: No enigma tab
« on: August 08, 2015, 03:02:48 pm »
How exatcly did you install ENIGMA? It seems you used the installer or something, but that is only for Windows.
Did you use these instructions: http://enigma-dev.org/docs/Wiki/Install:Linux ? And the .jar's should be from here: http://enigma-dev.org/docs/Wiki/Install:Extra_Packages . I don't think the mentioned install.py is updated enough.
Quote
I had same kind of problem in the beginning with lateralgm.jar, it was installed separately outside the enigma-dev and started working after moving it there. This being noticed I'm now curious about a separate folder ENIGMAsystem, where is a folder named additional. There's ENIGMAsystem in enigma-dev as well but does that need the mentioned "additional" folder? (I hope I explained enough clearly because this seems to be one of the most experienced computer stuff I've ever done.)"additional" folder is only for Windows and is only included in the windows installer. It holds all the libraries/dependencies ENIGMA needs. On Linux you must use the package managers to get them. There should only be one "ENIGMAsystem" folder and that should be in "enigma-dev" or more precisely the parent directory (the directory which has the .so and the lgm.jar).
Did you use these instructions: http://enigma-dev.org/docs/Wiki/Install:Linux ? And the .jar's should be from here: http://enigma-dev.org/docs/Wiki/Install:Extra_Packages . I don't think the mentioned install.py is updated enough.
133
Issues Help Desk / Re: No enigma tab
« on: August 08, 2015, 07:50:06 am »
And LGM doesn't trow an error about something missing?
enigma.jar must be in \plugins
jna.jar must be in \plugins\shared
compileEGMf.dll/.so must be in the same directory as LGM. On first run LGM tries to compile it, but for me on Windows that usually doesn't work. So I go to the folder via CMD and type "mingw32-make" or in your case "make". That should run the makefile there and compile the .so.
enigma.jar must be in \plugins
jna.jar must be in \plugins\shared
compileEGMf.dll/.so must be in the same directory as LGM. On first run LGM tries to compile it, but for me on Windows that usually doesn't work. So I go to the folder via CMD and type "mingw32-make" or in your case "make". That should run the makefile there and compile the .so.
134
Developing ENIGMA / Debuging the .dll
« on: August 07, 2015, 04:48:46 pm »
The crashes are killing me. Seeing as the problem is in the plugin (the .dll or the enigma.jar) I started trying to debug it. As the .dll is accessed from Java, then debugging it is non-trivial. What works for me is running LGM and then attaching gdb to the Java process. If it crashes after startup, then it could be as easy as looking up the PID in Task Manager and then typing:
After that the exceptions thrown by the .dll are also shown there complete with backtrace if the are debugging symbols. To have them you must compile the .dll with the -g flag, but that is done by default in the master anyway.
Some things I noticed:
The JDI code is EXTREMALY unsafe. I understand it was written up to 5 years ago so Josh wasn't experienced (heck, I didn't even write C++ back then) and there was no C++11 features which are useful, but still, the code is a minefield. A lot of unsafe pointers, memory management done trough new/delete, a lot of unbound sprintf's which is an overflow waiting to happen and much more.
Like one of the reasons the plugin crashed was when a value of a template is invalid and so the char array is null. Then it calls std::string(null) and explodes, as that is a segfault. This apparently happens in numerous places I'm trying to fix it, but as I don't know the code that well I'm not sure what I can and cannot touch. Pointers are passed around without knowing if they are freed or not. Like now a segfault happens in the destructor of ~definition_template which has THREE for loops inside with "delete". This is a great way to segfault. Trying to sanitize all that is going to be a pain. I hope someone can help.
Code: [Select]
gdb -p PID
Sadly, for me LGM started crashing on startup. This means I have very little time to attach the debugger before the exception. Thankfully PowerShell can return the pid from the name and that can be then piped as the argument. So it looks like this:Code: [Select]
gdb -p (get-process java |select -expand id)
This finds the PID for java and attaches to that. So it is possible for me to do it the 2 seconds while LGM loads.After that the exceptions thrown by the .dll are also shown there complete with backtrace if the are debugging symbols. To have them you must compile the .dll with the -g flag, but that is done by default in the master anyway.
Some things I noticed:
The JDI code is EXTREMALY unsafe. I understand it was written up to 5 years ago so Josh wasn't experienced (heck, I didn't even write C++ back then) and there was no C++11 features which are useful, but still, the code is a minefield. A lot of unsafe pointers, memory management done trough new/delete, a lot of unbound sprintf's which is an overflow waiting to happen and much more.
Like one of the reasons the plugin crashed was when a value of a template is invalid and so the char array is null. Then it calls std::string(null) and explodes, as that is a segfault. This apparently happens in numerous places I'm trying to fix it, but as I don't know the code that well I'm not sure what I can and cannot touch. Pointers are passed around without knowing if they are freed or not. Like now a segfault happens in the destructor of ~definition_template which has THREE for loops inside with "delete". This is a great way to segfault. Trying to sanitize all that is going to be a pain. I hope someone can help.
135
General ENIGMA / Re: ENIGMA progress
« on: August 07, 2015, 07:51:34 am »Quote
I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.Technically a lot of DLL's should work too, but they haven't really been tested. I think the FMOD audio extension relies on a DLL originally made for GM and it worked. This hasn't been tested much though.
Quote
As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA.I think long ago ENIGMA really did start as "Open Source GM". It wasn't meant to have more or better features, just the possibility to add them. So for a time GM compatibility was pursued quite zealously, even adding GM5 compatibility (trough an extension though).
Quote
That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!Yeah, it should be a lot more stable these days, but there are still problems with regressions. We don't have integration testing, so it is often possible for things to break.
Quote
Yeah Windows is a large part of ENIGMA's problems. The OS has no package manager like any sane Linux distribution and every Linux distro comes with a C++ compiler generally. On Linux ENIGMA just utilizes the package manager to install OpenGL and other libraries but on Windows we have to ship the whole freaking MinGW compiler, plus all of its binaries that ENIGMA does not even use, plus all of the libraries ENIGMA uses but MinGW does not. That much really is a Windows problem and also a C++ problem because C++ has no standard ABI. This means you generally can't build C++ programs with one compiler and then link C++ code from another compiler. Such as writing Visual C++ dll's that are linked from a MinGW compiler. This means when you write a class in C++ the vtable or virtual table which holds all the pointers to the classes methods can be layed out in memory differently between each compiler, because C++ does not standardize how the implementation should work. The C++ standard only defines what the implementation of any standard function does not how it does it. This can even lead to problems linking C++ binaries to other C++ binaries that were produced with different versions of the same compiler.This isn't as big of a problem you put it to be. First, Windows 10 finally has a built-in package manager, so looking forward to that. Second, there really isn't that big of an issue of providing mingw in an installer together with "Additional". I think the current method works quite good.
Quote
This is also why I do not update the ENIGMA zip anymore because it's 100mb's and takes me an hour to upload which is a complete waste of time. We were going to make the server do this automatically but nobody has the time or interest to set that up.I'm willing to do that. I think you even posted some tutorial or something how you did it, so if you could link it then I will start doing it. Internet isn't a problem where I live and 100mb's is really not an issue speed wise. Only need to find a good place to host - I think hosting on Dropbox isn't the best way. Maybe we have a way to host on ENIGMA's website? I don't know how much space we have though, Josh should know.
Quote
But ENIGMA does not even have a 64 bit version on Windows because of the OS's above mentioned problems and the complete rubbish that is MinGW64 on Windows. It's a total nightmare to go and build this thing and that's why nobody wants to do it.I can compile ENIGMA (the plugin) on 64bit, but of course the LGM stuff needs to be changed too in that case.
Quote
That aside if you take LateralGM and use it by itself without the ENIGMA plugin you rarely have problems but it is about as slow as GM8.1 with loading projects because both it and GM8.1 use managed languages (Delphi.NET and Java). This is also what a command line interface would solve because LateralGM and the Java Runtime would not have to link to ENIGMA at all and would not have to give a crap what architecture or compiler it was built for it would just pass command line arguments to it and be done. It's not even that these problems can't be worked around without a CLI it's just that nobody has the time or interest to do them and it's a lot of work to really do it correctly.Yeah, finish the CLI would be a good start. I think the only big thing missing there is rasterization of fonts? All the other things are either done or should be easy.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »