Thursday 17 October 2013

Thursday Thunder

Where Did The Day Go

Fear not, my title was not reference to weather effects, simply the noise Thursday made as it thundered past me.  I set off with the best of intentions to add some sliders so I did not have to waste to tinkering with various color values to get the perfect night time color balance.  In the end I wrote the complete slider-menu module, which is now capable of producing multiple control panels across several pages, employing such gadgets as sliders and glass tube readouts, plus the cool feature of being able to drag them around the screen to suit your own custom edit layout.


Here is a shot of the current 'slider' panel system. I need the smaller fonts to be redone and perhaps give the panel edges a modern blue tint twist if there is time, and perhaps blue/grey sliders to match the Reloaded theme, but they are fully functional.


In the above shot I was attempting to create the night time color factors by drawing in some dark blue fog, set the ambiance to blue and the surface specular to blue.  I also added a yellow dynamic light for fun. I am still not 100% satisfied my shaders are where they need to be though for effective night time color play, but it's a small thing to tweak and I wanted the slider panels working to make the remaining process a little more pleasurable.

It's 3AM In The Morning

Literally so, and I WAS gong to add a few editor features for Ricky baby but time beat me.  The good news is that I can delete the 'ambient night effects' email which has been in my inbox for over a week, and I can soldier on with editor and IDE functionality work come Friday.

Proofing The Website

Also had the pleasure of reading through the new Reloaded website this evening, which Rick and friends have been slaving over for weeks. It's really come together nicely and uses the newest and latest web technologies to give the whole site experience a modern and relevant feel to it.  The real meat of the site however will come over the next few months when we start adding some seriously nice content and news feeds to it. Our plan is to make the site a hub of information, so that each time you visit you will get the latest and greatest state of play from the land of Reloaded.

Signing Off

I know I did not make it much past sliders, but the panel system is pretty versatile now, allowing me to conjure up as many panels as I want, putting any values of readouts inside them, and spreading them across multiple TAB view pages.  The ability to arrange the layout to suit your needs, and eventually have the editor save those preferences for all time will make it a very useful addition to your game making toolbox.

A Community Question - LUA or FPI

An interesting comment was posted as to whether the FPI language would be improved, and from previous feature requests the idea of using LUA as a substitute was aired.  My question in yesterdays blog, and continues here. Do we throw away the FPI language (and subsequently all scripts ever created for it) in favor the language LUA which is a more mature language offering faster processing, but means we have to start our script mountain from scratch.  I have no problem continuing to support and grow FPI, but just like we did with the 'segment system', before we launch into another five years of glorious FPI scripting, should we be thinking bigger?  I've only had the briefest exposure to LUA (I stopped learning new languages as it tends to push out old ones I still use) but by all accounts it has a range of debugging tools available for it, and there is a good chance I can compile and run the LUA script internally instead of through DBP code.  The upshot is that you can not only have it running 'significantly' faster than current entity logic processes, but it can be made to run on multi-core systems for even greater speeds with thousands of entities. You must also consider adding LUA is a substantial piece of work, so saying yes will also mean scripting capability will be delayed, or that the feature will delay other needed components such as the 'Room Blob' system.  Something to think about though!

101 comments:

  1. You're the coder Lee and what you say makes sense. If LUA code is faster than FPI then I vote for LUA. Reloaded is touted as the next gen FPSC, so go for the gold. Any great program is always a work in progress. The history of FPSC proves it as does Windows 1.0.

    ReplyDelete
  2. Tbh with LUA - reloaded would instantly level up,
    thats just the case.

    However am sure there are plenty that would be against this move but this should be really a decission TGC - has to make "alone"
    after all its not just about improving a Product, its about a new Product
    so yes from my pov - just go with LUA
    its one of those none visual features that will attract more serious Developers
    to Reloaded!

    Regarding the Visuals Settings panel, i miss the shaders :/
    i hope there will be one for postFx Shaders aswell.

    As always nice progress and @ Rick and Co.
    nice looking/ informative website!

    ReplyDelete
  3. I think by going with Lua you would be lessening the learning curve for many who already have at least some Lua scripting experience, and those who do need to learn it from scratch for use with FPSC will receive the benefit of being able to carry their knowledge with them across many other general toolsets that also use Lua. (Disclaimer: I've never used FPI scripting language nor Lua for anything so I do not know the ease or difficulty of using one over the other).

    ReplyDelete
  4. As long as it's not as difficult as C ,C++, C-script, or any variant of those I'm for it. I have tried other engines before I settled with FPSC and was turned off because of their hard for me to grasp programming languages. I found FPI scripting to be very welcoming and easy to use yet powerful enough to do what I needed. I have yet to find a situation where FPI is not able to come through for me, but I feel this may change in Reloaded.

    Long story short: I have no problem with it.

    ReplyDelete
  5. YES! Lua! Awesomeness! Finally, when our scripts don't work, we don't have to worry about the scripting language itself being the culprit! AND it's a REAL scripting language! I mean, FPI was amazing and all, but I actually found it really complicated to learn and, even more so, read. It was really hard to see if you had written your code wrongly.

    So, Lua FTW! Hoorah for a brilliant suggestion, Lee!

    And also, wooooow. That screenshot is.....AAAA. Amazing. Really seeing those normal maps now :D

    Finally: Quick test to prove you're rendering at the correct resolution and make me shut up about it: Place a barrel (or other round object) in the level, move the camera in front of the top of the barrel, tilt your head on its side and see if the barrel looks squashed. If you don't tilt your head you won't be able to notice the squishyness. For increased confidence on my part, post the screenshot on here.

    ReplyDelete
  6. I say LUA. Reloaded is not about the past, it's about the future. It will significantly raise its potential.

    I see "60 fps" keep getting mentioned.. I hope the FPS isn't capped at 60?

    ReplyDelete
    Replies
    1. Why? What difference does it make as long as it's fast enough to be smooth, which it is at 60fps?

      Delete
    2. Isn't 60 FPS standard for monitors?

      Delete
    3. For most monitors, yep. For some it's 75, but it makes no difference unless you're using VSync, in which case when you run the game on a 75Hz monitor the game will run at 75fps.

      Delete
  7. This is great! I can not believe you made it this far. Finally Lee, we will soon grasp what we wanted years ago: a next-gem engine. So yeah, hope to see more improvement later on.

    ReplyDelete
  8. As I expressed in the other post, I am all for LUA, most especially if it broadens our capabilities with the software in a way that FPI could never do.

    (Perhaps some possibilities later down the line to make it accessible to non-programmers: visual scripting?)

    I can't help thinking that coding in FPI was like coding in pure binary. So many triggers and ons and offs and just frustratingly unconventional syntax.

    I think though, if LUA is implemented then the scripting abilities should be added to the editor as a whole script editing subsection to draw creativity into a single program. I think it could be very intuitive to say, right click an object in our game world and be presented with an "add script" option, then be launched into a new tab for reloaded that gives us a nice editor for our scripting.

    About the rest of the blog:

    Well, the night time image is...not the prettiest and most polished example so I wont comment on it.

    Fog settings though, will we be seeing one or two more options? The ability to change the fog fall off density? It's not vital but it could be really nice for making it specific to purpose.

    I think also those visual settings should not be red green blue sliders. If possible, they should be colour wheel selection interfaces that you find in most good engines and image manipulation programs. Sliding red green and blue is nothing short of tedious.

    Really impressed that we are seeing these little features trickle in now. Great work.

    ReplyDelete
    Replies
    1. ""add script" option, then be launched into a new tab for reloaded that gives us a nice editor for our scripting"

      Seconded! That's a brilliant idea! Although, what you would want is two options, "Add Script..." and "Link Script..." so you could have multiple entities using the same script. Also, once a script was added or linked to the entity, the two options would be replaced with "Edit Script..." and "Remove Script...". Very easy and intuitive.

      I would have said sliding rgb sliders was easy and fun, and far more precise than a colour wheel.

      Delete
    2. Perhaps colour wheel was a wrong word.

      This is what I meant: http://image.acasystems.com/color-picker/screenshot-color-picker-2.png

      There is no way the RGB sliders can give the ease of choosing the right colour that the interface in that image could.

      And indeed, the link script would be expected too.

      Delete
    3. The bottom half of that image would be sufficient. All I would want is a way of editing the RGB values separately. So yeah that would be good.

      Delete
  9. At the risk of ruffling any feathers... why not use both? The FPI scripting is one of the easiest scripting- it follows along the same principles of BASIC programming (going back to the days of basic with the Commodore 64 and other systems we began programming with). There is great potential already with the FPI scripting language- there are some redundant commands currently that could be condensed or removed, but it is neither useless or in need of replacing. You could replace with LUA, but that will be a big undertaking (as you pointed out already). Pairing the two is doable.

    Look at it from this perspective. There are many different people from all walks of life that use this software (FPSC classic) and will be switching to Reloaded. Not everyone are hobbyists- some of us do this for a living and have done very well with the tools already. While there is a large repository of various scripts and examples of FPI scripting, the problem is the documentation for said scripts. You need to "spell it out" for some, making it as simple as possible so that the idea and basics are understood. Now introduce LUA. While we not only work with LUA but have it integrated into our FPSC classic source, you will again need to look at providing good clear precise documentation. Otherwise you will have a huge gap between those that may know it and those that do not. I'm not against LUA, but I am concerned how much time will be taken to help pass the knowledge so that others can learn and benefit from it. Or how many are "willing" to spend time teaching those that cannot learn or understand using LUA so that everyone can benefit.

    And while we are on the topic, what about the media and artists? For example, artists like Cosmic Prophet and a few others that enjoy providing media to your customers, either in "free" form or in an official model pack. He (Cosmic) is no scripter (I know this because he is family and we speak all the time). So how would it benefit him if you drop FPI in favor of LUA? If you are asking your users, did you consider asking your vendors their input or thoughts (since not all of them access the blog)?

    If you ask and make a decision based on just the regular users of the software (regular being those that just tinker around), then you end up with a gap in the community. If you also ask the same question to your vendors and those that contribute to your company and user base (such as your vendors or maybe those of us that have actually sold many games already), then you can get all the information to make an informative decision. By pairing the two (FPI and LUA), you benefit in the long run and so do the users/vendors. Those that can script in LUA have a bonus, and those that only know FPI do not get lost or left behind. Or you could prep for the eventual "swapping out" of FPI in favor for LUA.

    ReplyDelete
    Replies
    1. Do you realise how enormously difficult it would be to get two scripting languages working together in the same program??! And that's not to mention maintaining both languages! And anyway, Lee said in a comment on Wednesday's post that he would not do both :)

      Delete
    2. It will depend on the time frame and the goal/objective/vision. We have LUA in our FPSC source. As I rewrote my source and stripped out the redundant code, we integrated LUA so we have both FPI and LUA. It actually runs quite fine on our source with very little issues. The only issue we had was our inventory system, which turned out to be a syntax error on my part (missed a ";" in a line of code).

      I'm not arguing against it, I work with multiple engines and have sold quite a vast amount of finished products. We did very well with FPSC and the FPI scripting- I recon since I know LUA well we will do good in Reloaded. I merely was pointing out there is another perspective besides creator position (Lee), users/developers (like myself, you and others), and artists that create media for said engine (like rolfy, Cosmic, etc). Some people already feel intimidated by FPI scripting, and now will feel more so if they have to learn something else. Now that is not to say they could not learn it- it will take them time, and they can ask the community for help and the community will need to be patient enough to teach.

      I realize in TGC's case maintaining both may not be viable and that is fine. It is viable for us because I do not have to worry about whether or not it will work for the masses. They only have to run my game whereas TGC has to ensure it works not just in the editor portion but in a built development as well. Since I know either work in my finished developments (we have one that just sold using both with no issues), it benefits me. Switch to LUA, keep FPI, drop FPI makes no difference to me. I work with the tools I purchase and if something is not quite right, I ask about it or I fix it.

      Delete
    3. Fair enough. Since I started programming only 3 years ago, I can still remember exactly what it was like trying to learn to program, but I never had to learn FPI, so I have no idea which would be easier to learn from a beginner's (artist's, non-programmer's) perspective. From my perspective, LUA is far easier than FPI.

      Delete
  10. I'm in favour of LUA. The pro's outweigh the Con's and I'm fairly sure it will create a community wide effort to port FPI coding to LUA!

    ReplyDelete
  11. I say LUA.
    But what I want to comment is that idea of having both.

    I don't see a point in having to mentain 2 scripting languages in Reloaded, as this would be a lot of work in order to get a feature in both languages, test it in both etc.
    I'm a programmer myself and I know very well how much time it needs to do something for 2 languages (and do it perfectly).

    So I think drop FPI (even if some people might not like it --> no coder is no excuse to stick with FPI, as they will also not be able to script in it and new scripts will come pretty soon from the community) and get LUA running.

    ReplyDelete
  12. Having never worked with LUA I can't comment. Maybe someone could post an example of what a LUA script would look like compared to an FPI script?

    ReplyDelete
    Replies
    1. Interesting that everyone says yes to LUA without really knowing what it is. As for myself its going to take me a year or more to fully understand it, I feel.

      Here's your link Ched:

      http://lua.gts-stolberg.de/en/Basis.php

      Whereas FPI is straight forward since it uses terms that are in FPSC such as entity, lights,weapons,water and etc.

      Delete
  13. Please, LUA!
    It feels kind of odd using on old system (even if it was a rather good one) with the new fresh Reloaded. As LUA is a common official language there would also be better support for it. And if it´s also faster than FPI I realy dont see any point keeping an old lanuage. I have no experience of LUA but what I´ve heard it´s an easy language to learn. So I vote LUA any day :)
    FPI feels like a dead end today.

    BTW: I think you (Lee) is a very bold man, as you keep doing these great postings with great shots - can you also deliver? ;)

    Just 13 days left until beta-release - I´m having trouble keeping my pants on!

    ReplyDelete
  14. I'd support a change to LUA, however, I think it's important to consider the truly huge amount of media this will disable, including all of the official model packs.

    ReplyDelete
  15. For those that have never seen LUA, here's an example of an FPI script directly ported to LUA. I haven't optimised it all; there should be much better ways of doing exactly what I have here. Also, I renamed some of the commands slightly as to how they should be named.

    --

    Here's the original FPI script (autodoor.fpi):

    :state=0,anywithin=75:state=1,setframe=0,sound=$0
    :state=1:incframe=0
    :state=1,frameatend=0:state=2,coloff
    :state=2,anyfurther=100:state=3,sound=$1,colon
    :state=3:decframe=0
    :state=3,frameatstart=0:state=0,setframe=0

    --

    And here's the new LUA script:

    if(state==0 and anyWithin(75)==1) then
    setFrame(0);
    playSound(getEntitySound(0));
    state=1;
    end;

    if(state==1) then
    if(frameAtEnd()==1) then
    setCollision(0);
    state=2;
    end;
    incFrame();
    end;

    if(state==2 and anyFurther(100)==1) then
    playSound(getEntitySound(1));
    setCollision(1);
    state=3;
    end;

    if(state==3) then
    if(frameAtStart()==1) then
    setFrame(0);
    state=0;
    end;
    decFrame();
    end;

    --

    Bear in mind it could be written a lot better but I just directly ported it.

    ReplyDelete
    Replies
    1. Oh. I did have indenting in there but the comment has removed them for me.

      Delete
    2. An appreciated example but I hope no one is going to be rooting for that kind of porting.

      The main thing is, I can't understand the FPI script, but the LUA script provides some readability (though the states make it so darn messy.) Perhaps it would be better to try and remake that script in LUA and post it, completely reimagined because I am pretty sure the result will be a clean, readable script compared to those darn messy states in both FPI and LUA examples.

      Delete
    3. It's not exactly LUA. This is how LUA actually looks like:

      if abc == 2 then
      doSomething()
      end

      As you can see, LUA does not have semicolons nor brackets in conditions/loops. You're pretty close to what LUA is, though.

      Delete
    4. Oh, ok. I copied the syntax from one of my own LUA-in-DBPro tests using the free LUA plugin, and I had semicolons and brackets when there was an 'and'.

      I'll re-write the example in clear, neat real LUA this time so we can see what scripts _should_ look like.

      Delete
  16. Ok I've created a forum post so you can compare the two languages more easily, including seeing the indenting for the LUA script:

    http://forum.thegamecreators.com/?m=forum_view&t=208278&b=50

    ReplyDelete
  17. Love the sliders;
    and dont mind waiting for LUA, even though i struggle with it anyway, i think in the long run, and much more viable and attractive scripting option

    ReplyDelete
  18. Your nighttime screenshot could be improved by implementing some of the image correction filters I've been rabbiting on about.

    For instance, simple filters such as brightness/contrast, saturation, a colour filter, and exposure filter can turn your night shot into this:
    https://www.dropbox.com/s/uw1tskn6uon2o2r/fpscrnight.jpg

    The values aren't perfect, but I'm sure there's someone who has more time than I to work on them. All I did was:

    Contrast +55%
    Saturation -30% (I actually completely desaturated the blues to remove the blue ambient light - it looked better)
    Exposure + 0.30
    And then added a photo filter of RGB 0,76,255 @ 30% density.

    The point is tweaking those values can vastly change the feel of the level, make it warmer or colder, older or newer, with probably no performance impact.

    ReplyDelete
  19. I know this is the third time I'm posting this, but I'll do it anyway.
    The reasons to stick with FPI:
    1) It's easy to use yet quite powerful.
    2) There are a lot of FPI scripts out there.
    3) It's a scriptinglanguage that Lee came up with, and therefore he have the control of it (can tweak it and add new commands ect.

    Disadvantages (FPI):
    Can't really come up with something, not because there are no disadvantages, but because I'm lacking the knowledge of LUA (did that even make sense?)

    Sorry for posting the same opinions three times.

    And once again sorry for my bad English grammar. It isn't my native language.

    - Mads.

    ReplyDelete
    Replies
    1. EDIT: Because I'm lacking the knowledge of FPI

      Delete
  20. Concerning the worries of current modelpacks, models when switching to LUA etc, all sellers are obligated to make their products compatible with newer versions of the FPSC-engine. At least that is what the agreement says.

    ReplyDelete
    Replies
    1. That's exactly the problem. Not all the developers will be ready to make that required switch to replace dozens of scripts with new ones they may not even know how to write in. I'm assuming that no developer of a FPSCx9 intended model pack is required to make any changes so that they work in FPSC-Reloaded. I think they/we are only required to make changes to them for future versions of FPSCx9. Since it is to my understand FPSC-Reloaded is a new product rather than a newer version of FPSC.

      There is a great deal of benefits to using LUA but i think it more relies on those that would be fluent with it. The general user is just going to get lost for the first couple months with it. Unless of course they have a general sense of programming background. Expect the forums to blow up with scripting questions. Sure there are lots of support materials out there for LUA, but however you won't find anything on how to integrate the code with your FPSC-Reloaded elements.

      FPI is easy to use, powerful but has just been lacking support and updates over the last little while. The best thing to happen to it was the inclusion of darkAI.

      Delete
  21. Although I like FPI scripting... it is just very limiting at times. So I do support the move to a new programming language. How long would it take to include something like that so we could start testing out our own scripts? I'd assume sometime next year?

    ReplyDelete
  22. Having LUA scripting instead of FPI would be a great idea, but i will not dealy any more the ROOM-BLOB system because whitout it FPSC:R is some sort of "half finished" work capable only to make Modern Warfare clone games (and less beacause Modern Warfare HAVE buildings, bunkers, tunnels and internal building stuffs, not only terrain!)
    if i have to choose from LUA and ROOM-BLOB i surely choose room-blob! if i have to choose from LUA and FPI , after the room-blob system ready then i will chose LUA,LUA,LUA!

    ReplyDelete
  23. Just remember, everyone, that because of the simple nature of FPI, it would actually be super-easy to write a converter to convert FPI scripts to LUA scripts. Obviously they wouldn't be as efficient as hand-written LUA scripts, but they would still be faster simply because LUA is much faster, plus it would remove the need for developers to re-write every single script by hand.

    ReplyDelete
    Replies
    1. A converter...that's genius. I know Lee didn't want to have two scripts, but this could truly solve the issue of past scripts.

      Delete
  24. It occurs to me that because it would be necessary to compile a list of every single FPI command in order to create a converter, the same list _could_ be used to allow users to write in FPI as well as LUA by converting the FPI scripts to LUA at runtime. This would hard to maintain, I know, but it's just a thought.

    ReplyDelete
  25. Lee

    Please move the Reloaded scripting language to LUA.

    "The upshot is that you can not only have it running 'significantly' faster than current entity logic processes, but it can be made to run on multi-core systems for even greater speeds with thousands of entities"

    I would have thought everyone will be in favour of this as FPI logic was viewed as one of the main performance drains in FPSC classic and we need as much performance gains as possible to support all the new features in Reloaded.

    LUA, LUA, LUA !!

    ReplyDelete
  26. Hope it has like custom destruction like Havok engine. You know, you can create the object then customize how it breaks apart.

    ReplyDelete
  27. Sliders :

    Anything that helps users, the more the better is good so thanks for that.

    Scripting :

    I have no problem with LUA personally.

    It is somewhat more complex in and of itself as it is.

    Speed, I take it that in theory it may be faster no argument there though if that's the case in Reloaded as opposed to any other software is yet to be proven. When you have real users game levels made with Reloaded - large, complex, full of various AI content and AI interactions and activity all going on at once in a scene pushing Reloaded to the limit we will have to wait and see. But then that's also the case for .fpi too so none of that is proven as it is in Classic. Its just not a reality yet. So we take the theory to be correct and hope it will be so, either way.

    Reloaded does not have to use a more widely used language for scripting just because other engines use it. Reloaded itself is not programmed in a such a common language so for that argument to hold up it would need to be have been developed from scratch using other. Anyway preparatory languages or not does not matter. Best end result is what matters.

    We live in fast paced complex world. Cental heating, broadband, banking, internet. Most of the time we have no idea and don't want to know how it all works. If it does not its infuriating isn't it?

    I have customers and they work delivered it fast and now. They don't want it to take very long as they cant wait and they want it at low cost so time is of the essence but inefficient technology and humans get in the way..................

    ReplyDelete
  28. Human Interfaces and software Eh! Some software interfaces are good and some are very bad.Who designs and tests these things? "Windows was my Idea Indeed" its not easy. Helpful is good.

    You can potentially have your cake and eat it here but it depends on interface and software design a great deal : I work with a lot of different software and languages.

    Some software programs languages including game software are easily accessible and helpful and well integrated internally with their Interface/Editor. As well has having an excellent default set of usable scripts they also have an excellent integrated script editor, complete with examples, help, commands list, debug, syntax highlighting "and" error highlighting "and" auto complete/fill/suggest and explanation of commands and syntax from a pop up/drop down/ dialogue window or list. When editing inside your software integrated "Script" editor choose a command or function and it drops it right into your script. Good init!

    All very helpful to achieving the end goal when you are an indie developer where you have often to be a master of many things and do everything yourself, which lets face it is a monster job.

    Why is Reloaded being designed and promoted as a product which easy to use? Well largely perhaps because as with almost all software that's what the customer wants and needs in the world in which we live. All software as well as most other product manufacturers are continually striving to achieve this and gain a bigger share of the market in a competitive world. Better design, cost saving, easier to use, time saving and faster.

    Thus well designed and integrated and giving the users what helps them and makes their life easier and as many of them as possible is a recipe for success. The more the software is designed to appeal to a wider audience and can make use of the tools the more users will actually use the software. At the end of the day that means better and more actual games and not less made with Reloaded which is good for eventually that will dictate the level of its success. Sooner or later that will become apparent

    Given then that any Scripting language adds real benefits by potentially making better games easier and faster for the mainstream users then its does not matter which one it is in the long term.

    In the short term that may mean some existing users loose out that have heavily invested in FPSC game making to date being dependent upon .fpi amongst other things with perhaps no easy way to port to Reloaded. I am not sure that anything could be done to help them and backwards compatibility is obviously an issue there.

    Certainly if AI drain can be reduced significantly and game performance can be improved then I would think there is no question of which Scripting language should be incorporated.

    Reloaded and its users are going to need all the help they can get in the performance stakes without question as it will be critical so if performance can be helped along by changing the scripting language and avoid any major disadvantages then go for it.

    :-)

    ReplyDelete
  29. Ragdolls is fundamental for this type of games. It must integrated not hard to do and script.

    ReplyDelete
  30. I agree, best solution would be to ditch FPI in favour of LUA. It is popular, faster, has loads of resources and will possibly attract more serious game designers to the scene. Why look back, FPI is from the last decade it's about time to move on. Like someone said majority of scripts can be easily converted over to LUA. Take your time to work on this and eventually it will be fruitful in many ways.

    ReplyDelete
  31. Is there anyone here familiar with LUA, enough to write scripts for Reloaded? I need a teacher to help with some basic orientation. The tricky part will be connecting the DBP data structures and variables to the internal memory of the LUA engine, everything else should be relatively straight forward. It does seem like a resounding vote for LUA. Does anyone know of 'the best 'visual editor' for LUA, that is, the most renowned IDE in use today? The syntax highlighting and debugging features will teach one a lot!

    ReplyDelete
    Replies
    1. It's sounds like you have made a decision :)

      Delete
    2. LuaEdit is the one they reccomend for use with tekkit projects, it's been pretty good when I've used it.

      http://sourceforge.net/projects/luaedit/

      Delete
    3. Most LUA users don't use any IDE actually. They stick to a text editor of choice ( Sublime / Notepad++ / emacs / vim ).
      I'll add that when I was integrating LUA into one of my projects, I found this quick setup guide the most helpful and up to date (integrating into C++)
      http://elysianshadows.com/phpBB3/viewtopic.php?f=6&p=55901
      Althrough, it won't satisfy all your needs. (like binding C++ functions)

      This would be a good lookup for any syntax-related issues:
      http://www.lua.org/pil/contents.html

      Delete
    4. Hi Lee

      I think you are the only person on this forum qualified to decide how LUA should be integrated into Reloaded.

      I saw that LUA has been integrated into Leadwerks engine so you may get some value from reading this PDF

      http://www.leadwerks.com/files/Tutorials/Lua/Getting_Started_With_Lua.pdf

      It sounds like everyone is in favour of moving to LUA which is great news.

      Delete
    5. Hello Lee, are you sure that delaying to an undefinited future vital functions like room-blobs, water system, ability to build buildings, rooms, bunkers with working doors and elevators is a good idea? It would be really good to have LUA scripts, in the future.. what kind of games variety could be made with a terrain editor and some of pre-built entities? I think all games will be all clones :(

      Delete
    6. If Reloaded needs to be delayed by a month to implement LUA that is the right thing to do. We should not rush into a release and need to ensure Reloaded is designed for the long term. If LUA can be done as a new module after the v1.0 release that would also be fine. The key thing here is that LUA is clearly the right direction for the Reloaded scripting system.

      Delete
    7. Really. Well that is your opinion.

      Delete
    8. I highly doubt it will be just a month, Nomad.

      Delete
    9. LUA is not that difficult to implement. I would be surprised if it took longer than a month.

      Delete
  32. Maybe you Lee, can create something very similar, or you can ask the developer(s) of LuaEdit if you are allowed to use their software in the engine, cause i really want a scripteditor INSIDE THE ENGINE :)

    - Mads.

    ReplyDelete
  33. Bad Idea, KEEP FPI. I would dump FPS CREATOR RELOADED if I had to learn another language. I have difficulty learning them, if it did come to pass, I would like to see lots of pre-coded Ai to just paste into FPS Creator Loaded.

    I LIKE EASY....

    ReplyDelete
    Replies
    1. You mean you like LAZY

      Lets not confuse the 2 things here ok. The learning curve for LUA is only fractionally more difficult than FPI and you can wait until people have converted some scripts for you to learn from.

      Not everything in life is supposed to be easy and you have to be prepared to put some effort in to get something out of it. If you want EASY then only use the predefined scripts that come out of the Reloaded box.

      Sorry to sound harsh but I seriously doubt you have even tried to write a single line of LUA yet to be making statements about how easy or difficult it is.

      Delete
    2. This comment has been removed by the author.

      Delete
    3. Also, you needlessly convince yourselves that you have trouble learning new languages. Thing is - did you even try learning new ones, or dropped the idea halfway, because you became too depressed of how tough it was?
      LUA is an easy language, and I guarantee you that you will be able to omit "advanced" stuff like tables / object-oriented stuff that it brings. I bet you'll be able to get away with simple conditional statements (if), for & while loops, functions and variables. It cannot be that hard to learn those, and when you get there, you can slowly walk your path towards tables and so forth - to ease your lives up.

      There's just no point in keeping FPI in place - it's design is too limited by itself for what Reloaded is trying to bring.

      All in all, don't be angry or anything if there's no FPI support and you are not able to learn LUA. I'm sure somebody will write a FPI to LUA translator. (Just like coffeescript to javascript)

      @EDIT
      I removed the upper post so I could place this one - corrected.

      Delete
    4. You guys are way too confident with the ease of use with LUA.

      David G's points is pretty valid as "easy to learn scripting language" was one of the selling points for FPSC originally. So many people that use the product were attracted by that line in particularly.

      I do support the move to LUA but its going to be a bit time-consuming to learn. I won't be able to jump ahead and produce something that works right away as I used to be able to do for my custom models and assets. Going to take lots of research, tutorials and practice with trial and error per line and an understanding of a new syntax.

      All in all I do support the majority vote towards LUA I just really hope people actually have looked into LUA to know what they are actually asking for.

      Delete
    5. I know I keep repeating myself, but bear in mind I'll be writing an FPI to LUA converter, so you can definitely have both languages available:

      http://fpscreloaded.blogspot.com/2013/10/thursday-thunder.html?showComment=1382138115722#c8044244123432204994

      Delete
  34. And it'd be great just to be able to go:
    if plrwithin==50 and inventoryslots==0 and keypressed==33 then
    print("Press F to pick up");
    sleep(3);
    fade(2);
    end

    That's approximate to a script, and I am and always was rubbish at scripting.

    ReplyDelete
    Replies
    1. This comment has been removed by the author.

      Delete
    2. Why did you remove your comment?

      Delete
    3. Wrong reply section was not at you.

      Delete
  35. And also, LUA was the language used by Crysis, Far Cry, L.A. Noire and Saints Row 2. Not games you'd call shabbily scripted.

    ReplyDelete
  36. I vote binary hell why not complicate it more. I do suggest then if this is the way that 2000 script are done for the less adept at scripts and plenty on here will volunteer like all who voted for it. You know who you are :)

    ReplyDelete
  37. Also lee the voters are like the scooby doo background whilst they run.
    Same scenery over and over. So be alert to that. Plus it may put off hundreds of people who are not the script savvy types but artists. Your being bombarded by we want complicated. Is this another udk unity as I did not sigm up for that you are taking away a magic element and draw to reloaded its simplicity unless you get hu dreds of script and how to and in detail or it will be a huge turn off I for one am against it unless simplified. I may post this 60 times like the others have. Stop this madness its not nomad reloaded. ;) just a punn nomad not malicious or anything x

    ReplyDelete
    Replies
    1. Do you really think FPI is simple? Because I don't. It's unconventional and very archaic.

      However, I think that an implentation of visual coding with LUA might help out those people who are not that good at raw programming. (For an example of what I mean, look up Kismet) and really allow FPSCreator Reloaded to launch off.

      Your argument about it being another UDK/Unity is a little silly. Of course it's not either. Reloaded still has its ability to make games without writing code which neither can really boast. But those games will always be limited, they always have, because code is required for a game to work. The basic scripts, as with FPSCreator will still be provided. Nothing will be changed in that aspect I expect.

      I think you should also consider that LUA offers compatibility. People who are somewhat familiar with programming languages will be able to slip into Reloaded comfortably. (Hell, DBPRO users should be quite comfortable considering the languages being similar in their syntax. Furthermore, those new to it and using LUA as their first language get an easy start point and can take that knowledge with them into other languages.

      We are not losing anything here. We are gaining.

      Delete
    2. Its nice that the majority of Model Pack designers were able to easily make scripts for their models themselves. But now that may no longer be the case. Whose going to be the lead LUA programmer for TGC assets?

      Delete
    3. Yes, it is going to spanner the works for modellers and old time users of FPI but I believe it will not last long. The simplicity will still be there. As far as I am concerned, it will be even simpler. States are a bit weird. Having to make the program specifically jump to lines is just not needed and it's not a skill that can be deployed elsewhere. Whereas learning to use LUA will be beneficial to budding programmers as they can apply their knowledge quite easily. If you are going to learn how to program, then at least choose an industry language. ;)

      Delete
  38. No offence taken. I just want Reloaded to be as good as possible.

    I'm not called Nomad for nothing. Ever since I joined the forums I've been shot down for saying FPSC is the best game engine in the world. You only need to look at my forum signature to see that. Anyway turns out I was right :)

    ReplyDelete
    Replies
    1. It is one of the best engines to use. We have had great challenges and managed to make some good money off our developments in v1. Even my wife enjoys it. Now our 15 year old daughter is designing artwork for loading screens and such. Being a "family business", FPSC has helped to get everyone in our family to participate. It was easy for me to get the family to work in FPSC than UDK or other engines, which is why we support the product and direct our contacts to TGC site.

      Delete
    2. As good as possible indeed. Something that's been bugging me with comments of late is that people seem to think the software needs to be aimed at one area. Easy, first person game creation. They seem to think that because the team is very small, it should never aim to compete with other engines, and we should not expect features and graphic qualities of AAA games.

      Why can't we have everything? I do not believe that we cannot, for one moment. Why cant we offer the easy creation, and the less easy at the same time? Why can't we have AAA graphics and features enough to make any kind of game? Why does it have to be first person only?

      I understand we might not get everything, and definitely wont get everything right away but it is the ability to aim for these goals that will push the software to its limit. Aim higher than you can go and you might just reach somewhere close.

      There is a gap in the market for game creation and Reloaded has a chance to fill it. An indie affordable, non-watered down version (Come on unity £2000 for dynamic shadows? Bite me.) three dimensional game creator that can make games with little to no scripting and still offer vast features for not using code, or alternatively/additionally, offer incredibly easy coding (visual scripting anyone?).

      Imagine this. Without writing a single line of code, you can make a generic First Person Game. Using visual coding, you can make a third person game in an easy, visual, understandable way. Then using raw scripting you can make pretty much any game you want. (An additional second sub-level - the ability to make your own visual scripting nodes so you can offer ease for other people and yourself if you are advanced enough.)

      That's three levels there that I believe reloaded could, and should reach and then right there you have the perfect game creator. A game creator for everyone, where the target audience is not the bottleneck.

      Delete
    3. Even if it wasn't integrated into the editor, I would be happy to have a go at inventing an FPI IDE myself that compiles down to LUA when you save or whatever. Also, once I had the compiler/converter working, I would also have a go at writing a visual scripting system.

      Given the relative simplicity of FPI and the associated commands, it should be fairly simple to create a visual editor.

      No promises, though.

      Delete
  39. Little funny to read how somones complains about eventually be forced to learn LUA. What´s the big deal? Have you stopped learning stuff? How are you going to learn the new Reloaded engine then? Just wondering :)

    ReplyDelete
    Replies
    1. Why are you being so hostile, science man?

      Delete
    2. I'm not being hostile maybe coming across wrong. But I do want to at least debate such a big decision. And I take all sides and views on board. So not intended and if offended not my aim. But I also think that it needs all angles covered and I am defending they who have difficulty in languages. And I am trying to ensure that they get a chance too. That's all :)

      Delete
    3. Oh, fair enough. I understand you're probably horrified that all of a sudden your nice, already-know-how-to-use-it FPI is disappearing in one big woosh. Suddenly everyone wants it gone and no one will listen to those opposed to removing it. I know the feeling.

      It's not all bad, though. Refer to my comment: http://fpscreloaded.blogspot.com/2013/10/thursday-thunder.html?showComment=1382138115722#c8044244123432204994

      Delete
    4. The key word here is development. The ones who are able to adapt will survive.
      If some have problem with learing, who should the whole project suffer?
      I think that´s just bad argumentation actually.
      I thought people were into this for learing stuff, maybe I got it all wrong :)

      Delete
  40. Ok, here's a far better-ported example of LUA compared to FPI.

    FPI script (autodoor):

    :state=0,anywithin=75:state=1,setframe=0,sound=$0
    :state=1:incframe=0
    :state=1,frameatend=0:state=2,coloff
    :state=2,anyfurther=100:state=3,sound=$1,colon
    :state=3:decframe=0
    :state=3,frameatstart=0:state=0,setframe=0

    --

    LUA script:

    if anyWithin(75)==1 then --any entities within 75 units
    if frameAtStart(0)==1 then playSound(getEntitySound(0)) --the sound is only played once per door-opening
    if frameAtEnd(0)==0 then incFrame(0) --increase the frame number of animation 0
    if frameAtEnd(0)==1 and getCollisionState()==1 then setCollisionState(0) --if collision is on, turn it off
    end

    if anyFurther(100)==1 then --no entities within 100 units
    if frameAtEnd(0)==1 then playSound(getEntitySound(1)) --the sound is only played once per door-closing
    if frameAtStart(0)==0 then decFrame(0) --decrease the frame number of anim 0 by 1
    if frameAtStart(0)==1 and getCollisionState()==0 then setCollisionState(1) --if collision is off, turn it on
    end

    --

    Once again, refer to my forum post for more readable code with indenting, plus advantages/disadvantages of LUAvsFPI:

    http://forum.thegamecreators.com/?m=forum_view&t=208278&b=50&p=0

    ReplyDelete
    Replies
    1. Now that is the best post on the blog. Nice helpful and it would solve a lot of problems. If possible. Appreciate the gesture x

      Delete
    2. Wrong post this was to your offer of conversion prog.

      Delete
    3. lol check where you're replying next time ;) :D

      Thanks :)

      Delete
  41. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Ok, I've pretty much decided that I am going to write an FPI to LUA converter some time in the future. Like, as soon as we know how Lee is implementing LUA. So you will be able to write in FPI and it will be converted automatically to LUA.

      No set-in-stone promises, though, because there's a small chance Lee's use of LUA may make it difficult to write a converter, but it's a very small chance.

      Delete
    2. i have to agree with nidalnijm, FPI have problem but is for sure the easiest language i know, i learned it instantly.. lua would be a great improvment but sincerely i think we are losing the focus from one of the principal keywords of FPSC:Reloaded : EASY
      are we sure that migrating from FPI to LUA we can continue to continue to define FPSC:R an EASY to create games tool?
      personally, if i think about it, the best decision is to mantain (& improve) the FPI script language, AND add the LUA script with a downloadable (buyable?) addon.

      Delete
    3. That would be by far the most difficult way of achieving both languages possible. You must realise it is a very big job maintaining just one scripting language let alone two.

      Delete
  42. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Yes, but it would probably gain a lot of people as well.
      I´m sure with this new product the Reloaded will gain a ot of NEW developers.
      It´s a natural development. If the TGC guys want the Reloaded be a bigger well known product, with a greater community, this is the right way to go.

      I my self has never even looked at LUA before, just read a little about it in the last couple of days. But I like to learn and develop myself. If you´re into the game business I think that is a must.

      Delete
  43. Learning LUA will not be as difficult as people think. In many ways it actually makes more sense and is easier to understand than FPI.

    ReplyDelete
  44. I prefer Lee and TGC make the decision to utilize LUA but the squeaking wheel gets the grease. The simple solution is to have all the reloaded backers vote, yay or nay. Majority rules. I have to learn one or the other and Lee is the coder.

    ReplyDelete