Messages

[MinimalWebServer.zip]

MinimalWebServer.zip

I made something in WinForms just to test if it works, here is a zip that contains a file named MinimalWebServer.exe, if you run it, it will set the name of the directory it is in, in a text box, and clicking the button will make it serve the files in that directory be served to the Web Browser. (If you just replace the text in the input box with any other directory in your pc it will serve the other things instead).

The idea here is you place the MinimalWebServer.exe in the Web folder that has your game built for web and just double click the exe file.

Then you load a web browser and just type the url as http://localhost:8000, and it should just be the index.html of whatever is in the directory. If no index.html is in the directory you will get a 404 error.

I sent the source files along, the Visual Studio solution and all. It's written using WinForms and the same C# and .NET used by the Editor currently. The idea is to try and kinda figure out the basics of how the UX of this should work before attempting something in the editor itself.

This is just something written in very few minutes, so there is no stop of the server, if you close the window it will terminate the server. Only one window can be opened at the same time or it will cause problems.

Hey @Vincent, what do you mean with the error message you sent? I tried the game here and it works.

The game can only work if it's served by a server, if you are simply trying to double click the html to run in the browser it won't work. For local testing you need to run from a server, you can do so using "python -m http.server" in the folder of the game from the command line if you have python installed. It should work fine when served from itch io.

I really would like to make this work somehow in the Editor so one could run it from the Editor and open in whatever browser for testing, but I could never come up with a UX design for how it could work to test it locally.

Also itch doesn't accept rar files, just use a zip file and it should work. (also rar should just never be used, it's a terrible format, just install 7-zip, it's free and open source)

Afaik it should be working. The AGS.js file is the same for all builds, AGS has always a runtime and the game files - mainly the .ags file. Is your game available somewhere?

Nope, sprites is implemented very differently. The changes are in the project explorer, where now you can drag things and move them between things there.

I guess this idea is something to sit on for a little to come up with a good design that works, since these decisions tend to stick for a little while. I don't think what we have now is bad necessarily, so I would look to fixing other things (higher priority things, for me) and let more people comment and improve this idea for some time.

Are you suggesting something for now to the future, or like, resurrecting the gazillion lines of API that were deleted from the land before time in ags4?

What we do currently in the API ignores the compiler, it's solved before, in the preprocessor. One would need to properly imagine how this idea proposed would work with some annotation. I don't have a good idea for this - the compiler doesn't know about the APIs at all today, and the script header for the engine script API has nothing special vs any other script header.

I think in the hypothetical world where script compiler supports this you still get this same error message, you could only get the deprecation warning if you build with a Script API setting that allows using an older API.

Like

Code: ags

 #ifdef SCRIPT_COMPAT_v350
/// Returns which walkable area is at the specified position on screen.
[[Deprecated: see WalkableArea.GetAtRoomXY]]
import int  GetWalkableAreaAt(int screenX, int screenY);
#endif // SCRIPT_COMPAT_v350

Will only be available if the compatibility is defined, so you would lower the compatibility, which I think is done by default when you upgrade the editor in a previous project - actually, it just doesn't go up.

The new compiler feature. Though I guess this should mostly be a minor issue, since it will affect projects if we rename some parameter but not binary releases. But my idea of the check would be mostly so that people understand that they may have to adjust their code if they use it in an interaction with external code - be the script API of the engine or a module.

@Crimson Wizard , this reminds me, should the named parameters in ags4 be behind some flag? Other thing, there are parameters that aren't named at all in the script API, usually enums, we may need to name then.

I doubt this is as profound. CJ started this thing in 1997 and was very young and used C so I guess things are trying to be C-like, it's DOS era. At some point people appear more interested, Java appears, OoP starts to be a thing people care about, CJ starts using some version of C++ in ags along of C code. It appears a graphical ide is interesting, a C# IDE gets written, and inspired by OoP and C#, starts some work putting OoP in the script API. More people are interested in AGS, there's a lot of expectations and development ceases to be fun. Global users are interested and they use American English in written convey. AGS is open sourced, CJ leaves the scene, people try to continue the work in the way it felt like it was headed, more British gets dropped from the API slowly. Novelty around open source of AGS dies soon, until it's very few people (mostly CW) pushing the engine forward. Meanwhile AGS keeps all this backwards compatibility - you can still boot your 20 year old project and load in the current Editor. AGS also keeps binary compatibility between runtime and old games - you can still run a 20 year old game in the current engine. Things that aren't a priority aren't replaced in the API - it's a lot of work to do so and keep backwards compatibility. That's pretty much how I read this, in the previous era the parameters in functions were a_word and then after C# gets used they slowly became aWord, and so on. I've been here since more recent years so I didn't lived in the previous era, I just read through the history to figure out things for the engine...

Monty's Birthday Bash

https://brianheagney.itch.io/montys-birthday-bash

Got this one by randomly searching for ags and I haven't seen it in the DB and don't think the author is here in the forums either.

This one appears to be old (2016?) but appeared in my radar now

https://leafthief.itch.io/behind-the-wallpaper

I actually participated in this Ludum Dare I think, but used JS at the time.

A conversion operator would be a hidden additional operator afaict from the discussion. I don't like this approach at all. And I don't think we should add opcodes without thinking too, that loop is a critical part that affects everything.

If you just write the new message this doesn't happen, like only when replying?

ints secretly cast to float and vice versa can cause hard to figure it out bugs. I would prefer if they aren't silently casted ever. I would also argue that I prefer to never pay for things I don't use, a lot of things I have to do a lot of times per frame and AGS Script isn't super fast, so I prefer to not add things that could slow it down - more API calls.

Overall it's possible to just write int math when dealing with int, and avoiding hitting the engine when possible - if you aren't going to do a lot on the native side in the engine you will pay more in the call than you would if you just wrote in AGS Script.

Maths is only floats, so in theory they would have to be floats.

Here

Code: ags

import float AbsF(float a);
import float MaxF(float a, float b);
import float MinF(float a, float b);
import float ClampF(float v, float min, float max);

Code: ags

float AbsF(float a)
{
  if(a<0.0) return -a;
  return a;
}

float MaxF(float a, float b)
{
  if (a > b)
    return a;
  return b;
}

float MinF(float a, float b)
{
  if (a < b)
    return a;
  return b;
}

float ClampF(float v, float min, float max)
{
  return MinF(max, MaxF(v, min));
}

The Engine Script API is an API to the engine, where Script code can implement things. For small things I don't think it's worth it to go through the Engine Script API - haven't actually timed but my guess is that the in script implementation will be faster.

I think if there's a need there could be an API for that like Point* GetRelativePosition(int x, int y). Does GUI.ProcessClick(int x, int y) uses screen or GUI relative coordinates? (I don't remember)

About base class, other approach is to put all of these properties in an object like DrawableProperties or something else - coming up with a good name in this approach is hard - and then deprecate the options and instead use this common object to hold it along.

(minor improve over 0.5.4 in a specific error message from list releases that can happen if github api blocks the query for some reason)

New AGS Toolbox 0.5.5 now can use the /maketemplate command from the editor.

When using the export template command, use the -f or --force-editor flag to make it use the export template command from the editor instead of the self built mechanism in agstoolbox.

Code: bash

atbx export template -f ../../dkrey/ags_tumbleweed/ tumbleweed.agt ../

Will export the tumbleweed template as tumbleweed.agt on the ../ dir.

This will only work if the game project is using either Editor version 3.6.2.1 or above or if it's an ags4 project, version 4.0.0.9 or above. Additionally, the necessary editor version must also be installed - either from using the installer or as an agstoolbox managed editor.