Moderator: OpenTTD Developers
NoGo is, like NoAI, a framework on which you can build script, called GameScripts. Where NoAI is specific build for AIs, NoGo is build to control the general flow of the game.
Although this framework is still very much a WIP, a small indication of what you can do:
- Control town growth
- Set custom texts in the Town GUI to indicate when growth should happen
- Custom news message
- Control the viewport of the player (singleplayer only)
- Change game settings
- Communicate freely with the AdminPort (bi-directional)
- Create your own subsidies
- Build stuff on behalf of a company. For example, you can build (or remove!) pieces of rail for a company. The money it costs (or is gained) is subtracted from the companies wallet.
- All (!) the functions an AI can do too. Most of them more powerful (see all companies, ...)
As you might understand, GameScripts are very powerful. Their main aim is to make Multiplayer servers fun, by setting conditions, goals, achievements and quests. Reward your best player with a subsidy, or make your own disaster by regular stopping random trains because the drivers are on strike. The sky is the limit, and you are in control!
Today I officially announce the project. It started out as a proof-of-concept, and it has proven itself. So it is time for you guys to give it a spin, and return with feedback.
How to get it:
Several locations that might be of importance to you:
Current Version: 1.5
HG prepatched: http://hg.openttd.org/developers/truebrain/nogo.hg/ (multiple heads, take the latest)
HG patchqueue: http://devs.openttd.org/~truebrain/nogo/
Documentation: http://devs.openttd.org/~truebrain/nogo ... tated.html
How to play:
Xaroth is kindly hosting several NoGo servers for you to try it out. They are advertised, and you can join them after downloading the latest binary. It might happen he has not updated to latest version yet, but this is mostly done within 12h.
If you want to play it in singleplayer, navigate to your OpenTTD directory. Next to the 'ai' directory there should be 'game' (or create it). In there, make a directory 'test', and put there these two files:
http://devs.openttd.org/~truebrain/nogo/main.nut.txt (save under the name 'main.nut')
http://devs.openttd.org/~truebrain/nogo/info.nut.txt (save under the name 'info.nut')
Start the game. Go to AI Configuration, double click the top entry and select TestTest. Start a new game. And there you go.
How to write my own script:
NoGo works very much like NoAI. In many many many many many ways. The only real difference, is that the AI prefix is changed for a GS prefix in the NoGo framework. So instead of AITown, you use GSTown. The NoGo framework shares many functions with the NoAI framework, and I am sure we will enable many others in the future. Their parameters and return values are often identical. This hopefully makes it very easy to write in either one.
You place your scripts in the 'game' directory, instead of the 'ai' directory. The rest is, including the format of info.nut, identical.
To understand what is currently possible, it is best to just learn by example. Open up the above mentioned main.nut.txt, and flip through it. Installation of your GameScript is identical to that described above. Don't forget to select one before starting a new game!
What is next?
My personal list of things planned is rather large. It is of course unsure if any of them will be implemented, but to give you an idea where I want this framework to go, things that will be possible in the future:
- Allow 'storage' for town cargo, so you don't have to use tricks to supply the town sufficiently every month
- Per-company GUI with goals, quests, challenges, achievements, ...
- Global GUI with goals, quests, challenges, achievements, ...
I am sure I am forgetting many many things, but you get the idea.
At the moment I am very busy stabilizing the framework, finishing the GUI, and cleaning up the code. Many bugs have already been fixed in the last few days (when developers test, bugs get solved so much faster ), so the current binary should be rather stable.
I would like to thank all the people on this forum (and beyond) for their great ideas (Korenn, you are full of great ideas!), patches, servers (luukland.net for example. You guys put the fun in multiplayer) and more. Together you gave me the idea for this implementation, and I hope it will be a platform for you all to continue working your awesomeness on!
Xaroth, tnx for all the feedback, testing, hosting, etc etc
Developers, thank you very much for your patches, suggestions, proof-reading and what-not. It went so much faster with your feedback
To the rest: any feedback, suggestions, comments, questions, ideas, praise, ... please do post them here.
It looks like I'm going to have to figure out this scripting -- "squirrel", was it?
*Inspects AI-script documentation*
It also proves what kind of first post gets more attention... Now I'm going to test NoGo againSupercheese wrote:Now, that's the kind of first post that properly shows off the excellent work that has clearly been done.
- takes a while to load on large maps
- is based on the original script by TrueBrain
- the cargo requirements of towns does additionally depend on the size of nearby towns - the larger the nearby towns are, the more cargo a town wants
- (2.7 KiB) Downloaded 177 times
- Towns (note, not cities) are claimable.. the claiming process takes a while (up to a minute), resulting in a sign being placed under the town name to identify as such.
- Requirements are harder than the original script, towns only slightly, but cities around 33% higher than before... thus enticing people to stick to towns for growing only.
- Claimed towns have 25% less requirements than normal towns, to make it somewhat easier in the long run for claimed towns, allowing them to surpass 100k citizens.
- Cities are identified so you can pick non-cities easier when zoomed out.
One possible way for me to solve it would be to "compile" two editions of SuperLib, one for each framework where I replace "AI" with "Goal" or "GOAL" depending on context. I could also change my code base to use the meta-names "Api" and "API" to refer to the framework name. Doing that would be a fairly automatic task and not a big issue.
I also realize that not all parts of SuperLib would apply to NoGo, so I might not get away from creating a compiler/pre-processor that uses my common code base and create one AI edition and another Goal edition, but if OpenTTD would use the same prefix, at least it would reduce the amount of time I need to put into making a pre-processor - actually, it might be possible to even use the exact same code base and throw an error at run-time when functions not "available" in a framework is called.
I, myself don't mind if the common prefix is AI or eg. "Api" even if the later means changing a lot of code, it will still be possible to automate and just be a one-time investment. That said, I do very well understand that renaming all AI APIs would break all 20+ AIs that we have and is therefore not an option, unless we accept to have very large compat-files.
It appears that NoGo scripts are not given the TownFounded event which is documented for AIs.
New version of my silly NoGo-script that works with Found Town:
(It uses a bit lazy coding so when a new town is added, the entire town list is rebuilt unless OpenTTD provides an event with the actual town id of the new town)
- (3.01 KiB) Downloaded 131 times
The issue about a prefix is one well talked about between developers. It is tricky. There are several functions, even classes, that are only available for either AI or Goal. And that might work confusing. I am not absolutely set that the current way is also the way to go, although it is most clean. It basically leans on the fact that there cannot be a library that works for AIs and Goals alike, as they both serve a different goal. It is said to be unlikely that you can develop AIs in the same way as Goal scripts, and they both will have their own set of documentation. Having one prefix for both would be more confusing. That said, this is still work in development, nothing set in stone. We will take your remarks regarding it with us next time I bring up prefixes
(PS: NoGo doesn't support libraries, and at the moment it is also not planned to add them. Any kind of library should be prepacked with the Goal script itself).
But if a NoGo script later want to inspect orders or work with other things, I see that more parts would be useful.
Would love to help out on this project if I can! Anything to get this into the mainline codebase as quick as possible!!!
PS. Can you tell I LOVE this patch!
I am sorry, but it is not.Transportman wrote:If I understand the changelog for r23310 correctly, it is now (partially) in trunk.
I did commit some updates for the TownGUI (it now shows a bit more information about what is going on), and also prepared it for a solution like NoGo (although it can also be used by anything else). And I added the long overdue ability for AIs to see if a town needs food or water (they couldn't so far).
As a nice side effect it did make my patch-queue a lot shorter, but there is no NoGo code yet in trunk.
http://devs.openttd.org/~truebrain/nogo ... tated.html
Naming has changed. GoalScripts are now GameScripts, to represent more what this is. This means that all references to 'goal' are replaced by 'game', and you need to move your Goal (now Game) script to the 'game' folder.
Naming inside the script has also been changed. GoalNNN now is GSNNN, where GS stands for GameScript. This is done because writing GS 100 times is easier than writing Goal 100 times. It also matches better with AI, 2 letters, capital, clear, obvious, to the point.
Some other additions:
- Events now work (well, did yesterday already, but now I tell you about it). Not all events are added yet, check documentation about which event classes (not enums) are available.
- At mapgeneration, the GS is now also called. This is important: you can run for at most 2500 ticks (which is a very long time), but as soon as you execute 'this.Sleep(1)', your script aborts till the game starts up. It would be very wise to include this sleep, else map generation will take unneeded long. During those 2500 ticks you can do everything you like, including DoCommands. They are executed instantly (without the delay you normally experience), which should allow every GS to do the wildest things on map generation, and have the map ready to play as soon as that is all done.
I hope you all like these improvements. And for those who wonder, this project is still called NoGo
Questions, comments, feedback: let me know!
So now there's a "game" folder that doesn't contain the game itself... I understand the change, but this is confusing at best.TrueBrain wrote:the 'game' folder
Apart from that I think this is going to prove an awesome feature! Great job!
I don't think it is that confusing; at best people might thing the executable has to go there, and even then the game works But this is still WIP .. will have to see how I like this. At least it feels better than Goal so farFooBar wrote:So now there's a "game" folder that doesn't contain the game itself... I understand the change, but this is confusing at best.TrueBrain wrote:the 'game' folder
Apart from that I think this is going to prove an awesome feature! Great job!
I totally fail to see the relation between NG and AI We have NoGo and NoAI framework ... NG and NA I can see ...Valentijn wrote:I think its a very cool feature, keep up the goodwork.
If you want consistency in the naming, you could thank about using NG.
Just like AI.
Users browsing this forum: No registered users and 3 guests