I'm very interested in this new scripting feature and I would like to create a new mode, in which the companies have to make money only from one cargo type, and this cargo type is cycled each 1, 2 years (the cycle frequency would be a parameter). If it is possible to do this kind of goal, could you tell me where to start looking in the nogo documentation?

You could use this NewGRF (that you have to create) in conjunction with a GameScript (that you also have to create) that make use of GSCargo.GetCargoIncome to spawn news messages that inform players about the changes in economy.

On 1.2.0 beta4 32 bit Windows I can crash OpenTTD with the following script code:

Code:

GSNews.Create(GSNews.NT_ADVICE, "test", GSCompany.COMPANY_INVALID);

It doesn't matter where in the script I use it, just create an empty script and put it in Start() and it can be reproduced. Upon crash the following message is shown:

Code:

Assertion failed at line 103 of c:bamboo-agent-homexml-databuild-dirottd-rls-w32bitsrccore/pool_type.hpp: index < this->first_unused

I found it because I was curious what NT_ADVICE is. I haven't tried every single news type but I have played around with a few and it seems only NT_ADVICE has that problem. Can anyone confirm this? I want to be sure before I file an entry in the bug tracker this time

And of course: can anyone give me an advice what NT_ADVICE is? Is it supposed to be used for tutorials in the future and implementation is just not finished, hence the crash?

The standard advice news in OpenTTD give advice on the vehicles of a company. Thus I would expect that the API tries to read the last parameter as a vehicle index. Probably there is a error in some of pre condition checks to ensure the validity of that parameter.

That said, if you can make OpenTTD crash using a NoGo/AI-script or a NewGRF or other user content, that is a clearly a valid bug. Please upload a minimal NoGo script that reproduce this bug to the bug tracker.

It seems I can display question dialogs to all players including spectators, but only for people in a company I get an event when they click a button, so I can never find out which button a spectator has clicked. Filed as FS#5063.

Don't know whether you read my comment here: http://bugs.openttd.org/task/5063But I just noticed you don't only show the dialog box only on company level but also accept the answer on company level only. Before I thought I would get e.g. two responses with the same company ID if there are two players in a company, but in fact the dialog disappears for the other player in the company as soon as one has clicked a button in it.

So it's worse than I thought, the dialog boxes are even more useless. You <could> ask players for Yes/No decisions, but why would you when you don't get a reliable response anyway? It's like a simple reflex game, whoever clicks faster makes the decision for the company - a decision that his other 3 company members might not agree with, but well, bad luck for them. Thinking well before making a decision isn't wanted?

Sorry for being a bit cynical but I was happy about a new feature I now find to be broken by design. Also my vote system will still have to use the chat, there is no way to make something useful out of this random response machine. (idea was to do something like this)

What would be so bad about doing the dialog boxes on client level? You'd shift the work to handle the responses to the script author and also give him all the freedom. If he really wants to actively implement a "whoever responds faster is right" system he can still do it (I doubt anyone will), but you also leave the option open to do a voting system all players can participate in or to get reliable answers from players. Of course include spectators in that.

You might argue that it's not an easy task from a script (for example what if you ask a question that is indeed targeting the company as a whole and the two players in it disagree about it?) but forcing a bad solution over letting someone do a difficult solution is not the best choice in my opinion.

"broken by design", well, the Vehicle Preview window has been like this for years now It would be weird if this window would be different .. either both change, or not. (also, please be careful with quotes like "broken by design". That it doesn't match your view on the subject, doesn't make it broken. It just means you expected more out of it. Expectations can be a b**** )

Network-protocol-wise it is not possible (atm) to do anything "per client", as you operate a company (not a client). You communicate on behalf of your company. It is not: client N dropped rail. No, it is: company N dropped rail.

From my point of view, this feature does exactly what it should do. It asks a question to a COMPANY. Not a client. If the clients controlling the company cannot be nice enough to at least talk it over and pick something they all agree on .. well .. that is not really in the scope of OpenTTD

To finish it off, this feature is mainly intended for Tutorials, more than anything else. The rest is just an added bonus

So although I do understand your issues, it is not how this feature is intended to work. How it is intended to work is btw very well documented. That your assumptions were different .. I cannot really fix that

PS: of course we are open for patches to introduce new features.

[Edit]

Btw, the usage you want out of this feature, is not something that should be handled by NoGo. The screenshot you show for example, is something on an admin level. It should be handled by the adminport or what-ever. Not by NoGo. NoGo handles the game logic. Town growth, objectives, .... Basically, everything that happens on Company level, not on Client level. That is for the adminport to handle. I guess that is also where your view and mine collide. NoGo's features are implemented to work on a game-logic level, so basically on a Company level. You now want to abuse it (from my point of view) to do things outside that scope. It is not intended for that (and it is btw a slippery slope ).

That said, what would be a good addition to OpenTTD, is to have a scriptable adminport Or better yet, replace the console with Squirrel, and you are done too. All you then have to add is opening of GUIs via them, and you have exactly what you want.

But, to close this up, it is not the job of NoGo. NoGo controls the game logic. Not the clients.

_________________The only thing necessary for the triumph of evil is for good men to do nothing.

I wasn't saying that it was an accident or something, I know that there is a "system" and intentions behind it that say it should work exactly like that. I just don't like it. Never liked it for the vehicle preview dialog either, so yes, change that too along the way

But well, it sounds like it would require rewrite of some bigger portions of code, so I understand it's not a simple change. I wasn't expecting you to reply with "yes it's a bug I'm gonna fix that tomorrow" anyway But maybe for the future someone wants to do a patch, just wanted to state my point of view about it for now and that I don't see much use in it as it is. But you're right, for the tutorial case it's probably sufficient.

Anyway, I don't want to complain only, here's some positive feedback too:Playing around with those new features I've tested those scripts back and forth with 1.2.0 RC1. My software (written in C#) uses the admin port to control the OpenTTD server. Now for 1.2.0 I've additionally written a GameScript that acts as agent within OpenTTD to give my software access to more aspects of OpenTTD. The script listens to events (like buttons clicked in dialogs) and forwards them over the admin port. Also it listens for messages for commands coming from the admin port, e.g. commands to retrieve certain information (which are then sent back) from within the game or execute commands.

Playing around with the dialogs I had a setup where a player would write !voterestart and a vote to restart the current game was started. My software then sends a command to the GameScript via the admin port along with all 5 parameters needed for GSGoal.Question(). The script then calls this function, making the dialog appear for all players (screenshot in my former post was from that test).Now the script handles the dialog click events and sends a message back over the admin port for all of them. My software then has the remaining logics to check whether the vote succeeded or not.

So I've done a full loop through the admin port over the GS to OpenTTD and from an OpenTTD event back to the GS and over the admin port back to my software. I am well aware that all of this was far away from what the GameScripts were meant to be used for - but I think this makes it a good test. Except for the case where two players were in one company it worked great, on both a Windows and a Linux server. So good work there, even in such a bit complex setup it all was running fine!

In response to your edit: I don't think our views collide. I totally get your point and expected you to reply just like that (except that I didn't know how much effort would be needed to do the change). But as you know this is the first time I get access to such features from my external application. It's the only interface I got to do this.Of course I don't like the fact that my setup had to become as complicated as described before. I will be the first to use such a scriptable admin interface or whatever better solution might be offered. For now I am just trying to get as much as I can from what I have. And believe me, I am really thankful for what is there already. And I will shamelessly abuse and misuse it for my matters and squeeze even the last bit out of it, harharharharhar

I tried this out, but I spent all of four hours trying to figure out why my script wasn't appearing. In the end, I copied an info-nut from another script and changed the contents to the ones from my original info.nut.To the eye, they appeared identical sans formatting (spaces, tabs, empty lines, comments). I even did a comparison with a text editor, and it could not find anything. (E.g. copying line-for-line using find function, etc.) What's going on here?

Do returns matter to the compiler? Formatting? Tabs? Is commenting style diffrent from the one in the squirrel documentation?... So I experimented, added random formatting. Script still worked. I would like openTTD to actually post an error message if compilation of info.nut fails in some way, because this is weird.Edit:Well, whatever the case was, it's fixed.

Last edited by Aphid on Thu Mar 29, 2012 11:07 am, edited 3 times in total.

It may be the file encoding. Saving unicode with BOM may break your file.If the old file is indeed in unicode with BOM, and the copied file in either ANSI or unicode without BOM (you may check that yourself), then I hazard a guess that this indeed has been the cause.

So now for the actual hard question: Suppose I want to use a NoGo script to create (build or prospect) a primary industry at the start of the game. (Or, say, a bunch of them). How would I go about doing that, considering it requires an existing company, and I cannot create dummy company rich enough to prospect with current game difficulty settings? How do I give the dummy more money?

Where CPY is some bool from another process that determines we want to prospect industries, X holds the amount of industries we want total, j_old the amount the map generated itself, and j is the main counter. 'i' cycles through the available prospectable industry types. Note that while inefficient, this code accomodates NewGRFs, even if they do something weird like change the prospectability of an industry if more/less/equal than some variable Y exist.

After roughly 5 years of lurking through this forum, i registered today to say: Thanks for creating this For me it's one of the best additions to OTTD for uhm... years

I decided to look into the API after i stumbled across the "Neighbors are important" Script, as my pals all agreed that growing cities was far to easy. The description of the script and the way Goals work were confusing to us, so i took a look at the code and edited the script to fit our needs (If Zuu reads this... now that i have registered: thanks for the script! prepare to get a list of suggestions soon too).

As for Thinkbrain: I hope you're still motivated to extend the API and here is my short list of suggestions.

Script Setting CategoriesWhen modding/scripting I like to offer users a wide variety of options so it's comfortable and understandable for them to adjust the game to their liking. I really like how the AddSetting and AddLabel functions work right now, but i'd love to be able to sort my Settings into Categories (and possible Subcategories) similar to the ext.GameOptions to keep things in order

Town Growth with unreached CargoGoalMaybe implement a way to have Towns grow even without CargoGoals having been reached. Possibly an optional third value to pass to GSTown::SetGrowthRate( TownID town_id, uint16 days_between_town_growth, uint16 days_between_town_growth_without_cargo ) or something alike

As of now i either have to set all town cargo goals to 0 and therefor disabling them or "show" them and growing stops instantly. If i want a town to grow really slow, while having goals that are unfullfilled, i am out of options.

Town Growth Rate NONE-SettingCurrently if a script wants to stop a town from growing it can either set the growrate to something like 100 years or set an unreachable Goal. I would like an option to simply set the TownGrowth to nothing as it will be less confusing for the users. Alternatively a town which grows less often then X is considered not growing, but i'd prefer setting GrowRate to 0, null, -1 or something similar.

Industry AdjustmentsSimilar to the city adjustments it would be wonderful if GSIndustry had functions to adjust the overall production of the industries. This would open lots of possibilities for economy scripting like recessions, rewards, "missions", etc. As a bonus GRFs like FIRS could get a lot spicier

After roughly 5 years of lurking through this forum, i registered today to say: Thanks for creating this For me it's one of the best additions to OTTD for uhm... years

Then I can't welcome you as user here. But lets say welcome as new poster

Fanatik wrote:

I decided to look into the API after i stumbled across the "Neighbors are important" Script, as my pals all agreed that growing cities was far to easy. The description of the script and the way Goals work were confusing to us, so i took a look at the code and edited the script to fit our needs (If Zuu reads this... now that i have registered: thanks for the script! prepare to get a list of suggestions soon too).

I look forward to your suggestions. If you want to submit patches for it that is also welcome. As long as the code is somewhat good and I agree with your ideas, I do in general don't see anything that is against including it.

Fanatik wrote:

As for Thinkbrain: I hope you're still motivated to extend the API and here is my short list of suggestions.

You probably meant TrueBrain. Also note that he is not the only one working on the AI/NoGo API although he has made fundamental key contributions. I don't know if we would have had neither NoAI nor NoGo without him.

Fanatik wrote:

Script Setting CategoriesWhen modding/scripting I like to offer users a wide variety of options so it's comfortable and understandable for them to adjust the game to their liking. I really like how the AddSetting and AddLabel functions work right now, but i'd love to be able to sort my Settings into Categories (and possible Subcategories) similar to the ext.GameOptions to keep things in order

For now, what you can do is to hide some settings from all but fellow NoGo/AI devlopers by setting the developer flag on the setting. You could pre/post-fix your settings with a category. That said, I don't disagree with your suggestion. *someone* just have to implement it

Fanatik wrote:

Town Growth with unreached CargoGoalMaybe implement a way to have Towns grow even without CargoGoals having been reached. Possibly an optional third value to pass toGSTown::SetGrowthRate( TownID town_id, uint16 days_between_town_growth, uint16 days_between_town_growth_without_cargo )or something alike

You can grow towns directly using GSTown::ExpandTown(). Then you gain full control over the circumstances when the town will grow. Only problem is that you need to spend ticks on monitoring your conditions and call ExpandTown when you want to. Thus you might run into performance issues if the conditions takes long time to check. This is true especially on large maps with high town density. Using this method you also lose the standard town GUI feedback for players and have to resort to placing status-signs in each town or spamming players with news messages. (or you could lend ideas from the AI Tutorial and make a virtual keyboard using signs that let the user "type" the name of a town that he wants information about)

Fanatik wrote:

Industry AdjustmentsSimilar to the city adjustments it would be wonderful if GSIndustry had functions to adjust the overall production of the industries. This would open lots of possibilities for economy scripting like recessions, rewards, "missions", etc. As a bonus GRFs like FIRS could get a lot spicier

Unfortunately this is currently not working well with NewGRFs. It basically boils down to that NewGRFs have control over these matters and there is no protocol in place that lets NewGRFs give up this control to OpenTTD.

Fanatik wrote:

Boolean Settings ButtonsWould love to have Red/Green Boolean Buttons for added settings. It's mostly eyecandy and usercomfort, but would be a nice addition nonetheless.

This is possible. It's just that Neighbours are important doesn't have any boolean settings. Take a look at CluelessPlus for example (or any AI or NoGo that uses boolean settings). The way of doing it for NoGo is exactly the same.

Industry AdjustmentsSimilar to the city adjustments it would be wonderful if GSIndustry had functions to adjust the overall production of the industries. This would open lots of possibilities for economy scripting like recessions, rewards, "missions", etc. As a bonus GRFs like FIRS could get a lot spicier

Unfortunately this is currently not working well with NewGRFs. It basically boils down to that NewGRFs have control over these matters and there is no protocol in place that lets NewGRFs give up this control to OpenTTD.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum