Messages

Error: prepare_script_error: error -18 (no such function in script) trying to run 'room_RepExec' (Room 1)

This happens when you type in a function name on Room Events pane, but do not have (e.g. occasionally deleted or renamed) such function in the script.
You should make sure that the function is named properly (same way) in both Events list and script text.

An infant could match wits with you and still win!

Too bad you have no wits to match with.


->
- Am I supposed to be impressed?

- I fought headcrabs more fearsome than you!
- Stop poking me with that crowbar, dr. freeman.

[not to]

I want to add a small comment to this, since I've already saw two people making this mistake in their custom code (that might be same code, I did not accurately compared them yet).

If someone goes to try implementing custom resolutions, I'd strongly advise not to add it on top of existing resolution logic in AGS, e.g. as a "7th" resolution type (as Skygoblin did, for instance).
The first thing that should be done, IMO, is to remove the old logic with resolutions defined by IDs completely, and incorporate a new one, supplying a conversion between IDs loaded from old game data into actual resolution numbers (for backwards compatibility).
Even though the Editor may still allow to select between standard resolutions (instead of typing them manually) - they should not be enumerated and saved as "resolution id", but as actual resolution numbers (width x height x color).

Just saying...

Funny (or sad) thing about this argue about AGSScript is that unless someone will be inclined to actually work on improving it, all this is senseless blabbering (sorry for being rough).

And, keeping in mind the fact that the AGS code is open, anyone inclined may work on improving AGSScript on his/her own.

And, if the AGS will provide means to attach different script compilers/interpreters to the engine (this was discussed few times before), the user will be able to choose whatever language he likes / whatever is more fit for his skill/game.

That said, I keep wondering if monkey_05_06 tries to persuade someone to work on AGSScript, or not to cut it from the AGS (which, I think, won't happen for a long while regardless of other things).

0xC0000005 occurred in ACWIN.EXE at EIP - 0x4530827F; program pointer is -1893, ACI version 3.21.1115, gtags (1065,275)

I don't know how to interpret this information. Would anyone have any suggestions?

"Program pointer" is a value of "our_eip" variable.
Usually you may search for the number ("-1893" in this case) in the project and see the last known place where the program did work.

["already related to simulating mouse click at given coords."]

"already related to simulating mouse click at given coords." How is the fact that the simulated click is on a GUI/Button any different than this description? I'm not demanding that the name "ProcessClick" be used, but it follows the same logical nomenclature of the global method.

Is it? You did not mention parameters it should take. If they are x/y coords, it will follow the same "nomenclature", though I understood your idea so that it will simulate click on exactly the object it is called from, in which case it has different meaning.

We should also avoid adding any new methods in the global scope to AGScript...we already have enough confusion because of the pseudo-quasi-OO-style.

I do not think this is a valid approach. Since there are global functions already, we will eventually need to OO-ize them all. Which won't become more difficult task if we add few more.

What you're saying here essentially amounts to, "why do it the right way now, when we can just fix it later?" If a new function directly relates to an object (script object, not just an AGS Object), it absolutely should be made a member method, not a global function.

What I am saying is to stay consistent. Since we already have a lot of global functions, we should either make them object-oriented all at once (or at least all functions in a related group), or not being afraid of adding another one (especially if it is a variant of already existing global function).
If you are going to add a function that IS really a member function, then of course add it as a member function.
But my sentence about adding global function was related to hypothetical variant of ProcessClick, which I called ProcessClickOnGUI, which could work same way as ProcessClick work. If it is not something you want to add, then all this is irrelevant.

The July Is Coming.

15 days left .

Those who understand binary and those that don't.

That reminded me a semi-joke about remembering multiplies of 2 by heart:

1, 2, 4, 8,
10, 20, 40, 80,
100, 200, 400, 800,
......

.OnClick! this is how it should be called.

I am wrong about RunInteraction of course. The GUI does not distinct interactions (Walk, Look, etc). The may be RunEvent instead. Or SimulateClick, or any better name one may come with. My point was that ProcessClick name is already related to simulating mouse click at given coords.

Regarding simplicity, I think there's a chance it is very easy. Although I would keep fingers crossed, for AGS has a lot of traps inside...


E: Oh, and -

We should also avoid adding any new methods in the global scope to AGScript...we already have enough confusion because of the pseudo-quasi-OO-style.

I do not think this is a valid approach. Since there are global functions already, we will eventually need to OO-ize them all. Which won't become more difficult task if we add few more.
And if function does not refer to certain object, why should it be made one's member? (I guess ProcessClick may become a member of Screen class in the future)

I would question the choice of function. AGS has ProcessClick, which does not refer to particular object, but tests any entity at given point (practically - simulates mouse click). Also, RunInteraction, that is an object-related function and allows to trigger particular event.

I think that if we consider keeping consistency, there should be either ProcessClickOnGUI(x,y) or GUI/GUIControl.RunInteraction, or both.

Additionally, while you probably would never see a difference in actual performance rising out of it

This really depends on what code is put into condition. Testing a >= 4 few extra times is no big deal, but if person gets this habit, he eventually starts to call same function with same set of parameters dozens of times when checking various conditions, and that eventually gets you into trouble.

I don't think there's a way, you'll have to make a long switch iterating all possible buttons.

To make things easier for you, you may use GUI.GetAtScreenXY to get GUI and GUIControl.GetAtScreenXY to get gui control under mouse, instead of manually checking coordinate.
Then use their ID to choose proper function.

That is because AGS does not let the data package have more than 10k files inside .

We will need to modify the package format to make this work. I will post update in the Development forum if there are any news on this matter.

It is difficult to be completely sure, because I am getting different results on processor load every time I run, but I think this one is slightly faster:

http://www.mediafire.com/download/6pf7fta1ezax5wf/acwin_gfx_revised.exe

I will update in git soon.

I would remove the things it does not really rely on if I was adding this to AGS distributive, just to keep things clean.
In my opinion, since the concept of the template is to emulate certain game style, it should do only that (+ have a example room(s) maybe, like 9-verb/Verb Coin templates do if it really needs to demonstrate its features).

I still have certain concerns about Lua (I believe I mentioned that already): it implicitly creates new variable when finds a new name in script. This means every time you make a typo, or forget to rename a variable in one place, you will make a new variable instead. And since it is not a strongly typed language either, there's less chance (or perhaps none) compiler will tell you anything.
This really annoys me, for otherwise Lua seem to be very nice script language. Simply imagining having such typos in the depths of a large scale project makes me anticipate days of debugging in search for an elusive bug .

A serious bug found:

When compiling a game, the characters are enumerated according to their visual position in the project list, instead of their ID numbers. This breaks setting player character in the editor and, presumably, any script commands that use character ID. Using character script names work as intended.

It is currently not known if same behavior applies to other enumerated items, such as Views, Rooms, etc.

I've already detected this bug. For some reason this version of the editor enumerates characters using their position in the list, rather their explicit IDs when compiling the game.
Temporary solution would be to move character in the list so that its position correspond to its ID.

We are going to look into this and fix the problem.